Open
Bug 404866
Opened 17 years ago
Updated 2 years ago
XML parsing error when element is inside xul script
Categories
(Core :: XML, defect)
Tracking
()
REOPENED
People
(Reporter: martijn.martijn, Unassigned)
References
Details
(Keywords: regression, testcase)
Attachments
(1 file)
114 bytes,
application/vnd.mozilla.xul+xml
|
Details |
See testcase, I get an XML parsing error in current trunk build. This regressed between 2007-11-18 and 2007-11-19: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-11-18+04&maxdate=2007-11-19+06&cvsroot=%2Fcvsroot Regression from bug 401613, I think.
Comment 1•17 years ago
|
||
So this is a case were we're actually starting to report real errors that we ignored before. The error is coming from nsXULContentSink::HandleStartElement: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/content/xul/document/src/nsXULContentSink.cpp&rev=1.188&mark=551-556#545 Do we want to return to the old behaviour? We could just make nsXULContentSink return NS_OK in this case since it's not really an error, we'll just ignore the script's child elements. Or we could make the eInDocumentElement block handle eInScript too, though that's a change in behaviour since we'll start adding the child elements' text content to the script. Thoughts?
Comment 2•17 years ago
|
||
It's almost tempting to treat this as a parsing error... If we don't, we should keep compat and drop those elements, I guess. At least for 1.9.
Reporter | ||
Comment 3•17 years ago
|
||
I think I'm also seeing this with https://bugzilla.mozilla.org/attachment.cgi?id=286882 (testcase from bug 401946). There, it's a case of <script type="undefined" src="#mmmmmmmmmmmmmmmmmmmmmm"/>.
Ideally I think we should build a proper DOM in this case, just like the XML content sink will do. However it's too late in the game to fix that, since that'll mean fixes to the fastload serialize/unserialize code, and likely to other places (overlay code?). So I think we should simply document this bug in devmo, and leave as-is. It is IMHO a bug since we're not building a proper DOM, but it's not one that I think needs to be fixed for firefox 3. Martijn, have you seen this happening with any real-world extensions or pages? Or just in 'artificial' testcases?
Reporter | ||
Comment 5•17 years ago
|
||
This is with 'artificial' testcases.
This problem is also in Linux version Mozilla/5.0 (X11; Linux i686; rv:2.0b9pre) Gecko/20101217 Firefox/4.0b9pre SeaMonkey/2.1b2pre, when I try the XUL test suite. Currently I'm working on Xubuntu 9.10. For example, when I tried test popups, I receive this error message: XML Parsing Error: Location: http://www-archive.mozilla.org/projects/xul/tests/popups.xul Line Number 28, Column 84: onload="testElt(document.getElementById('below_left'));" orient="vertical">
Reporter | ||
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Updated•7 years ago
|
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•