From Bugzilla Helper: User-Agent: Mozilla/4.7 [en] (X11; U; Linux 2.2.13 i686) BuildID: 2000041811 if you use a german special character in an element id like <text id="öl" value="oel"/> ^(ö) caused problems. No Page is sisplayed and somtimes mozilla crashed. Reproducible: Always Steps to Reproduce: 1. craete an element with an id 2. use a german special character in the id like ö 3. load the page Actual Results: Page not displayed, somtimes mozilla crashed Expected Results: Error Message because ö (ö) is not alowed as an id
Not sure about this one: attempting to view the attachment with the 2000-05-15-08-M16 nightly binary on WinNT results in a content area freeze, but I'm not sure how XUL code, which is what the attachment is according to NN 4.7, is supposed to be displayed as a webpage. Trying the equivalent with a minimal HTML page, that page displayed fine, although the illegal ID ought to be exercised... <HTML><HEAD> <TITLE>Bugzilla bug 39399 HTML testcase</TITLE> </HEAD> <BODY> <H1 id="lö">Bugzilla bug 39399 HTML testcase</H1> some text </BODY></HTML> Quoting from chapter 6, Basic HTML data types, in the HTML 4 spec, http://www.w3.org/TR/REC-html40/types.html -- > ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by > any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), > colons (":"), and periods ("."). So "ö" is not so much ö as just an illegal character -- the charset doesn't much matter. XUL can't be any less restrictive, can it? Passing to XP Toolkit/Widgets:XUL rather than HTML Element component because <text> is not an HTML element.
Attachment makes todays win98 build lock, sorta. Mouse is completly responsive...toolbar/etc DO work fine, but can't scroll the page or use any objects on the actuall pages until you restart.
Confirming. For XUL (according to XML 1.0), the character 'ö' (0xF6) is legal in the value of the ID attribute [http://www.w3.org/TR/REC-xml#NT-Name, http://www.w3.org/TR/REC-xml#NT-Letter]. The testcase attached above results in a load failure of the XUL document (although the console reports success, the content area has no document). The following change to navigator.xul (i.e., change the ID of the search button to include 0xF6) will result in a startup crash of mozilla on win95 2000051608, and a hang/infinite loop for a current linux debug build % diff navigator.xul~ navigator.xul 269c269 < <button class="button-toolbar-3" id="search-button" value="&searchButton.label;" --- > <button class="button-toolbar-3" id="search-buttonö" value="&searchButton.label;" Passing to nisheeth, cc: hyatt.
Setting milestone to M18 and marking nsbeta3...
nsbeta3+, severity critical (can crash).
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, but do not clear the nsbeta3- nomination.
Comment on attachment 8723 [details] test case for this bug Changing MIME type of testcase, so it's displayable in Mozilla.
Created attachment 78196 [details] Testcase Here is a XUL testcase that proves that this works now. The testcase even demonstrates that changing the value of a label, by using it's non-ASCII id works! So good news for i18n people developing XUL apps using IDs with non-ASCII chars.
This was tested on Mozilla 0.9.9, using Linux, btw. Resolving as WORKSFORME.