- From: Vlad Alexander <vlad.alexander@xhtml.com>
- Date: Tue, 6 May 2008 05:26:07 -0400
> Does the NPAPI define a way to submit form data? Yes, please see: https://bugzilla.mozilla.org/show_bug.cgi?id=188938 IE, FF and Opera support plug-ins to submit data in a form. And XStandard plug-in supports this. For example: <object type="application/x-xstandard" name="editor1" width="100%" height="300"> <param name="Value" value="Hello World" /> </object> IE, FF and Opera will send "editor1=Hello World" to the server in an HTTP POST. The alternative is to this feature is an ugly hack which I hope will not be necessary one day. Please see: http://xstandard.com/en/documentation/xstandard-dev-guide/web-integration/step2/ > Auto-installing unprotected binary code on an enduser machine seems > unbelievably unwise. But it's not silent install. The user is prompted to approve the operation. So from security point of view, it's no different than asking a user to install via installer. > I take it you don't like the idea of HTML+JS being the alternative > solution [alternative to codebase attribute]? Sorry, not sure how HTML+JavaScript can be an alternative to the codebase attribute. There is a need for a cross-browser technique to install plug-ins. Until such a technique is specified, the codebase attribute should not be removed. Regards, -Vlad -------- Original Message -------- From: Ian Hickson Date: 2008-05-06 2:08 AM > On Sat, 7 May 2005, Christian Biesinger wrote: >> OK, another <object> fallback question: Consider an object that has no >> attributes that would allow selecting a plugin/content handler. For >> simplicity, consider an object without any attributes, say: >> >> <object>Foo</object> >> >> What should be displayed? Should the user agent just fall back to the >> contents of the object? (Presumably "empty string" as fallback content >> does not affect the answer to this question either :-) ) > > The spec now defines this. > > > On Wed, 25 Jan 2006, Hallvord Reiar Michaelsen Steen wrote: >> On encountering an OBJECT, the UA must check type and/or classid. >> >> If the type attribute identifies a file type the UA handles >> internally, check if the OBJECT has a data attribute. Render contents >> of this attribute if found, proceed to fallback contents if not. >> >> If type/classid identifies a known plugin, the UA must initialise the >> plugin passing on information about the attributes and the name/value >> pairs of any PARAM descendants that are not children of nested OBJECT >> tags. >> >> If type/classid does not identify a known plugin, and there is a data >> attribute, do a HEAD request on the resource identified by the data >> attribute. If the server sends a content-type that identifies a known >> plugin, initialise plugin. >> >> If there is no data attribute, the resource can not load or the >> content-type of the resource is unknown, proceed to render fallback >> contents. > > The above is somewhat what the spec says, though it is more closely > aligned with what browsers (Mozilla in particular in this case) seem to > do. > > >> Issues: if there is a known content-type and a data: attribute, >> should the UA check if the content-type sent from server also >> identifies the plugin? In other words, do we want to say that the >> type attribute on the OBJECT tag is only a hint and that the actual >> HTTP content-type header is the one that counts? > > Right now the spec uses the Content-Type header if it is present. > > >> I'm not sure if "only a hint" should be speced. It sounds quite risky to >> meddle with the logic for embedding contents - could break many sites, >> particularly if we are supposed to start relying on the famously >> malconfigured HTTP content-type responses. > > What should it be instead? > > >> Since there are use cases for plugins that do not load data at all, the >> UA should initialise the plugin even without data attribute if the type >> is known. That sort of negates the point about type being a hint because >> we can't initialise one plugin, look at the content-type of files that >> plugin decides to request and say "whops, we started the wrong plugin, >> let's do this again". If the spec goes the "hint" route, it really needs >> to make that apply only to OBJECTs with a data attribute, and to >> minimise problems with malconfigured servers it should only take place >> if the UA doesn't know the specified type attribute IMO. > > Right now if type="" is present but data="" isn't then the respective > plugin is fired, otherwise the plugin to fire is taken from the > Content-Type header. > > >> Another issue is of course if and how one should map classid to plugins. > > Indeed. I don't know how to do that. I suppose it is UA-specific. > > > On Tue, 31 Jan 2006, Shadow2531 wrote: >> The current methods of "The server Content-Type rules all" and "If >> there's no data attribute, then fail" are not working out. There are >> cases where a data attribute is not needed and there are cases where a >> type attribute should be the priority. The type attribute is really used >> as "Here's what plug-in/handler I want to use". > > For the no-data="" case, the spec now handles it. > > >> There also needs to be some specifics for the classid attribute. If the >> classid contains an unsupported naming scheme, should the UA really have >> to just fail or should it go on and try to use the type and data >> attributes? > > It appears it should fail. Do browsers do otherwise? > > >> How should data uris be handled? Is it just up to the plug-in to handle >> the passed data uri or is the UA allowed to create a file from the data >> URI and pass the file path to the plug-in/hander (if it can do it >> safely)? > > Isn't this up to the plugin API? > > >> What should happen when a UA encounters a codebase attribute that has a >> path to a cab file instead of a base URI? Should the UA always use the >> codebase to resolve URIs even if it has junk in it? > > Right now codebase="" is just ignored by the spec. What should it do? > > >> First, the UA should check for a classid attribute. >> >> If present and the the UA has a handler associated with the specified >> naming scheme, then the UA should pass all arguments to the handler in a >> manner that is specific to the handler. > > That's what the spec says, indeed. > > >> If the classid attribute is not present or the naming scheme is not >> supported or the handler returns an error code, then the UA must check >> for the presence of a type attribute. > > If classid="" isn't supported, it just shows fallback. > > >> If it exists, the UA must check to see if it has a handler associated >> with the Content-Type specified in the type attribute. >> >> If the Content-Type is associated with a handler, the UA must pass all >> arguments to the handler. > > The resource is actually downloaded by the UA in this case, as far as I > can tell. Is that wrong? > > >> If that fails and there is a data attribute, check the Content-Type >> sent by the server for the file and determine if there's a handler >> associated with the type. > > The spec honours the Content-Type header over all else if it is present > and classid="" isn't. > > >> If there is a handler associated with the type, pass all arguments to >> the handler. >> >> If there is not, the UA *should* compare the file extension to a list >> of known Content-Types associated with that extension. >> >> If a handler is found, pass all arguments to the handler. > > I do not want to add any extension-sniffing to the spec, it is too > dangerous, highly unreliable, and as far as I can tell isn't necessary. > > >> ( URIs to files should be passed to the handler and the handler should >> download the files as necessary. The Ua should not download the file on >> its own. Only the handler should make that request to the UA.) > > Really? > > >> Once the handler gets the arguments, it *must* detmermine whether it has >> the necessary and valid arguments to initialize. If it does not, it >> should return a failure code. If it does, it should try to initialize >> and if successful, return a success code; otherwise, return a failure >> code. The handler should return a failure code in every situation where >> there's no need to initialize in the first place. > > This is out of our scope. > > >> The UA must check for this return code to determine whether to display >> fallback content. > > It's not clear to me how to tell if a plugin failed. > > > On Wed, 1 Nov 2006, Christoph P?per wrote: >> I think it would be helpful to /explicitly/ allow content types (alias >> media types) in |type| of |object| to omit the subtype, e.g.: >> >> <object type="video" data="foo.mpv"/> >> <object type="audio" data="foo.mpa"/> >> <object type="image" data="foo.png"/> ~= <img src="foo.png"> >> <object type="application" data="foo.swf"/> ~= <embed src="foo.swf"/> >> <object type="text" data="foo.txt"/> ~= <iframe src="foo.txt"/> >> >> Maybe this is all the support for this element type that should be >> required from conforming implementations. Furthermore |width| and >> |height| should be required for freely scalable formats, but OTOH not >> apply to 'audio' types (i.e. always equal zero), and exclude the space >> required for an optional inline GUI. >> >> I never understood, by the way, why videos and Flash-like content >> shouldn't work within |img|. (Parameters can be specified in URIs.) >> >> I could also envision an HTML5 where |alt| was optional for (or even >> removed from) |img|, which in return was only allowed to be used for >> optional, decorative images (and perhaps likewise |embed|). Every >> illustration conveying meaning was then to be embedded using |object| >> (including descriptive content, but nesting |object|s would be >> discouraged, although allowed) or more sophisticated methods. This >> wouldn't keep many correctly authored existing pages conformant, though. > > I don't really see how to handle this feedback. We can't really make the > changes that would change how <object> works today. > > > On Tue, 7 Nov 2006, Lachlan Hunt wrote: >> Should the data attribute be required for <object>? There is at least >> one plugin that doesn't need it. XStandard embeds itself without using >> it, like this: >> >> <object type="application/x-xstandard" id="editor1" width="100%" height="400"> >> <param name="Value" value="Hello World!" /> >> </object> >> >> I'm not sure whether that's a correct use of the object element or not, >> and I do think it would make more sense for XStandard to replace a >> textarea, but there must be implementation issues with that or >> something. >> >> http://xstandard.com/page.asp?p=A4372B00-8D7F-4166-977C-64E5C4E3708E&ss=C2B75B64-1544-429D-ACDA-07D17E35FB56 > > It's allowed. > > > On Tue, 7 Nov 2006, Shadow2531 wrote: >> Reason 1: >> <object classid="java:MyJavaClass"></object> is used for Java. ( >> Although I'd love to have <object type="application/java" >> data="file.class"></object> work, but ...) > > This is not allowed. Java should use the standard mechanism, as you point > out. > > >> Reason 2: >> You might want to load a plugin like this: <object >> type="application/x-mplayer2"></object> and later use scripting to >> tell the plugin to get the resource. If the data attribute is >> required, you'd be forced to load a resource that you didn't want to. > > Indeed. > > >> Reason 3: >> The tcl plugin <http://www.tcl.tk/software/plugin/> suports inline >> scripts via a script param and things like the following need to work >> without the data attribute. >> >> <object type="application/x-tcl"> >> <param name="script" value="script content"> >> </object> > > Indeed. > > > On Sat, 23 Dec 2006, Rohan Prabhu wrote: >> I've been writing a spec called 'XObject' for the past week.. and i'm >> going on a 2-day vacation from tomorrow.. just got the idea of sharing >> this with you. I wrapped it up in a small site-like thingy in the short >> time i had.. so the site is not really good... but the content is there >> as much as i have worked on. It is still a work in progress. Do read the >> foreword there, I've already warned about some factual inaccuracies... >> :) >> >> Here is the link to it: http://xobject.tritiumx.com > > It's not clear to me what this spec (which btw is now no longer available) > was supposed to address. > > > On Sat, 7 Apr 2007, Henri Sivonen wrote: >> HTML5 should probably make the Java applet embedding patterns documented by >> Sun conforming or at least make the <applet> case conforming as it is the >> cross-browser syntax: >> http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/using_tags.html > > Java needs to get over itself and stop being such a drama queen and just > use the standard embedding methods that everyone else uses. > > > On Sat, 7 Apr 2007, Michael A. Puls II wrote: >> Currently, the only way to embed an applet that's allowed by the spec >> is: >> >> <object type="application/x-java-applet"> >> <param name="code" value="MyJavaClass"> >> <object> >> >> (That works fine for Opera and FF at least.) > > Indeed. > > >> There's also <embed type="application/x-java-applet" >> code="MyJavaClass">, which is currently not allowed because src is >> required. > > Indeed. > > >> There's also <object classid="java:MyJavaClass> (which is used as a >> non-deprecated example at >> <http://www.w3.org/TR/html4/struct/objects.html#h-13.4>). This is >> currently not allowed because there's no classid allowed, which has to >> be present to be compatible with IE. > > Right. > > >> And, then, there's of course APPLET, which needs to be defined (no >> rush), including how fallback content works when java support isn't >> present and the alt attribute is present. (As in, does alt get used over >> fallback content or the other way around or somewhere in between.) > > There's a note in the spec about this. > > >> I also think it might be necessary to clarify (or at least hint to) >> what mime type should trigger java. application/x-java-vm and >> application/x-java-applet etc. are provided by the Sun Java plug-ins, >> but not all browsers use those plug-ins. (application/java is used in >> W3C examples.) > > The spec has an example with x-java-applet now. > > >> On a side, if codebase is allowed on the object element, it will have 3 >> different uses. >> >> 1. base URI for resolving (kind of like <base href="">) >> 2. URI to a .cab file (for activeX stuff) >> 3. For java, it's specifically a URI to the directory the .class file >> is in unless you're using current IE in which case, it's #2 and a >> codebase param is used instead. > > o_O > > I'd rather just not support it and make it non-conforming... Do any > browsers actually support case 1? Case 2 seems incompatible with case 1. > > >> In the case of #3 (for browsers besides current IE), where both a >> codebase attribute and a codebase param are present, one of them would >> have to override the other. It might be necessary to define which one >> and how etc. (Going to something specific like this might be out of >> scope for plug-ins etc. in general, but Java handling might be an >> exception.) >> >> With all the different OBJECT situations for Java, APPLET will be a huge >> relief. > > How about just not supporting Java? > > > On Mon, 22 Oct 2007, Vlad Alexander (xhtml.com) wrote: >> I noticed that the latest HTML 5 draft states that the "name" and >> "codebase" attributes are not allowed on the "object" element. >> >> 1. Plug-ins, such as XStandard, use the "name" attribute for submitting >> content to the server without the need for JavaScript. This makes for an >> accessible solution. XStandard has been doing this for 4 years in some >> browsers. IE, Firefox and Opera support this feature. This attribute >> serves a vital role for plug-ins. > > name="" is now supported, though not for this purpose. > > >> 2. The "codebase" attribute is the only way to auto-install or update >> plug-ins in IE. This is an important feature that should not be removed >> without providing an alternative solution. > > I take it you don't like the idea of HTML+JS being the alternative > solution? > > Auto-installing unprotected binary code on an enduser machine seems > unbelievably unwise. > > >> 3. The HTML 5 draft states that the "embed" element is used for plug-in >> content. The "object" element is a better mechanism for loading plug-ins >> and is supported by all browsers. The HTML 5 spec should state the >> "embed" or "object" elements can be used for loading plug-ins. > > I'm not sure which bit you're referring to here. > > > On Thu, 25 Oct 2007, Michael A. Puls II wrote: >> Yes, I agree. The name attribute has to be supported (at least when the >> object is inside <form>. (All the form stuff hasn't been dealt with yet >> though.) > > It's not clear to me how this is supposed to work. Does the NPAPI define a > way to submit form data? > > >>> 2. The "codebase" attribute is the only way to auto-install or update >>> plug-ins in IE. This is an important feature that should not be >>> removed without providing an alternative solution. >> If we do define it, it's going to be fun because what it's for depends >> on how it's used. >> >> It can be a URI to fetch a new version (for IE). >> It could be the directory that java class files are in (in browsers >> besides IE when using the Sun java plugin). >> It could be a base URI used for resolving relative URIs (in browsers >> besides IE for possibly native stuff and some plugins). >> >> For the last 2, there would need to be rules to follow to determine >> whether it's an IE upgrade URI or a base URI so browsers besides IE >> don't use it as a base path if it's not really a base path. But, >> there's not much need to use a codebase attribute in FF, Opera and >> Safari (not even for java). > > I have no idea what to do here. > > > On Tue, 1 Jan 2008, Jeff Walden wrote: >> http://biesi.damowmow.com/object/011.html >> >> Firefox 2 shows FAIL. >> Firefox 3 currently shows PASS. >> WebKit nightly shows a broken image icon. >> Opera 9.25 shows PASS. > > WebKit now shows PASS, so this seems like a non-issue. (Spec agrees.) > > >> http://www.whatwg.org/specs/web-apps/current-work/multipage/section-embedded0.html#the-object >> >> For the moment ignoring that WebKit's using @type instead of the >> server-sent type of the <object> producing the PASS/FAIL/icon (contrary >> to current HTML5 and HTTP RFC 2616), it seems that WebKit isn't >> displaying fallback content when the primary content contains "errors" >> -- malformed images, in this case -- where recent Firefox and Opera are. >> >> The spec doesn't currently address falling back for malformed content, >> i.e. malformed images, invalid XML (maybe?), content a plugin handler >> declines to handle (?, dunno whether this is expressible in NPAPI or >> ActiveX or whether that question's too implementation-dependent), etc. >> I tend to think it should since a broken-image icon's not particularly >> useful, but I don't care strongly one way or the other. > > Fixed for everything but XML. >
Received on Tuesday, 6 May 2008 02:26:07 UTC