If a file has the extension .xml (instead of .xul), the label of the menu
element won't display. The menu items pop up correctly and have the label
displayed as well.
Error: this.childNodes[i].getAttribute is not a function
Source File: chrome://global/content/bindings/toolbar.xml#toolbox.init()
This happens both if the file is a valid xul file but with the extension xml,
and if the file is a valid xhtml file, with the xul namespace defined, and
served as xml.
Gonna attach the testcase.
this is some kind of namespace issue, it seems. I got an assertion when going
to Erich's page.
Created attachment 50414 [details]
Served with xul mime type: works
Created attachment 50416 [details]
xhtml file served as text/xml: doesn't work
Adding URL to which hwaara refers.
Created attachment 50417 [details]
xhtml served as application/xml: doesn't work
Created attachment 50418 [details]
xhtml served as xhtml: doesn't work
Created attachment 50419 [details]
xul served as xml: doesn't work
Ok, so it looks like this bug appears whenever the document is not served as xul
file (mime type application/vnd.mozilla.xul+xml)
Created attachment 50420 [details]
Minimal testcase. Serving as text/xml, but any other non-xul mime type should repro this too
click on the toolbar-grippy, you get this new js error:
Error: toolbox.collapseToolbar is not a function
You are going to have problems if you try to load a XUL file with a wrong mime
type. Most people know that if they serve their HTML documents as text/plain, it
won't work. This is the same thing. We shouldn't crash or leak memory or do
anything terminally bad if served a wrong mime type, of course, but XUL-specific
things just not working is different. Use the correct mime type.
Someone may argue that XUL is just XML, and another namespace, and therefore it
should work. Our implementation does not think so: the mime type triggers
completely different code for XUL. XUL also has an officially declared mime
type, so I would really like you to use it.
In my opinion this is wontfix, or perhaps future.
This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration -----
Because this bug is really old and no one is responding resolving WFM.
Anne, with all my respects, but WFM is not the right resolution. Wontfix would
be the more appropriate resolution, as per comment 12.
resolving wontfix as per comment 12.
Erich, when I try to load a XUL file with a 'text/xml' or 'application/xml' MIME
type it works fine. I think people from mozilla.org switched minds since 2001 ;-).
(In reply to comment #19)
> Erich, when I try to load a XUL file with a 'text/xml' or 'application/xml' MIME
> type it works fine. I think people from mozilla.org switched minds since 2001
Anne, how did you do that? Maybe my testcases are broken then? If you look at
the attached testcases above, all drop-down menus indeed work, but the menu-bar
has no text, except of course if it is served as a xul document. So is <xul:menu
id="file-menu" label="File"> the cause of all this trouble? Is there a new way
to label a menu item?
Never mind. I was just seeing the style sheets being applied and I thought no
functionality was lost as well.
> Someone may argue that XUL is just XML, and another namespace, and therefore it
> should work. Our implementation does not think so: the mime type triggers
> completely different code for XUL.
That's not a valid reason for wontfix, and wontfixing is supposed to be done by module owners. This is not to say that fixing this bug was ever a priority, but it may still be a valid bug.
I'm reopening this bug to make it easier to find and turning it into a meta bug.
removing URL of testcase hosted on my site because it's no longer there. The attached testcases should be enough, I guess.