Mozilla currently misuses the CODEBASE attribute of OBJECT. From HTML 4.01, 13.3: codebase = uri [CT] This attribute specifies the base path used to resolve relative URIs specified by the classid, data, and archive attributes. When absent, its default value is the base URI of the current document. Refer to discussion in bug 162899.

Peter K. Sheerin writes in bug 162899: If anyone's thinking of using archive instead of codebase, I don't think that's the right attribute either. According to the spec, classid specifies "the location of an object's implementation", and is a single URI. Archive is a URI-list, which from the wording seems like it's meant to point to additional information the plugin might need (perhaps for preloading boilerplate content, or additional modules?). If a change were made I'd submit that classid be the URI for the XPI, and codebase be used to either specify the base URI for that xpi, or be a URI that points to a web page that allows the user to manually choose and install a plugin. In fact, a browser could use this URI if it were unable to automatically install the XPI (or whatever resource classid specified), providing a good fallback case for browsers that don't support XPI or for platforms that don't have any plug-ins available. That's probably not workable, and I don't think it's consistent with conforming applications of OBJECT. It is not workable because the PLID will need to go in CLASSID. The PLID is analogous to the CLSID of an ActiveX control, or a Java class identifier, both of which also use the CLASSID attribute. CLASSID is the sanest place to put the PLID. As a point of reference, note these correct uses of the OBJECT element with Java: http://www.student.oulu.fi/~sairwas/object-test/java/ Furthermore, consider that many of OBJECT's attributes are derived from APPLET <http://java.sun.com/products/jdk/1.1/docs/guide/misc/applet.html>. The point of OBJECT was to have an element like APPLET, but more general. An applet in a JAR archive would refer to the JAR with OBJECT's ARCHIVE attribute. And as I believe the XPI file plays an analogous role for plug-ins, ARCHIVE is the right place to refer to it.

I just wanted to jump in here for a minute, and i will post more later. But, in XHTML2.0 which is currently under draft review, the classid and codetype attributes are obsoleted, the codebase attribute is replaced by the xml:base attribute. You will see the updated XHTML2.0 on Monday or Tuesday. In that updated draft you will see the new object element module.

Interesting, but I think this bug should be about OBJECT/CODEBASE in HTML 4.

Not necessarily, we need to ensure that the decisions we make today appropriately map to the current recommendation (XHTML1.0) and are inline with specs that will soon be the recommendation. HTML4.x is similar to XHTML1.0. The base reference issue is the same across all three specs. It should only be used to reference a location, not a file. The current XHTML2.0 spec is very clear on that point.

By definition, URLs reference locations, not files. The concept of a "file" is particular to implementation details on the server side.

reassign

so I'm confused, what needs to be done here? Braden, can you attach a testcase showing the failure?

Note that CODEBASE serves as a base reference for CLASSID, DATA, and ARCHIVE.

Comment on attachment 109695 [details] Test case this WFM in 7.01

Peter: Does it still work if you remove your locally installed Flash plug-in?

Braden, the ARCHIVE attribute is NOT used for pointing to XPIs. You MUST use a PARAM with PLUGINURL in order to get the default plugin to show up on OBJECT tags. See this attached testcase. If you do not have this tag, we follow the spec by rendering the contents, in this case, whitespace. See bug 180411 about changing this in quriks mode. If you take a look at a network trace, you'll see we correctly resolve CODEBASE for your DATA url and open it to get the mime type.

> Braden, the ARCHIVE attribute is NOT used for pointing to XPIs. Yes, that's bug 186085. Note that if PLUGINURL persists, it would be sensible to apply CODEBASE to its value as well.

marking WFM, again. As the last testcase shows, we generally do correctly support CODEBASE on OBJECT. If there is an individual case that fails, open a specific bug on it.

marking WFM, again. As the last testcase shows, we generally do correctly support CODEBASE on OBJECT. If there is an individual case that fails, open a specific bug on it.

When <object> is an image or document, codebase="" is not used to resolve data="". That is already open as bug #40680.