XML parse error in netError.dtd for Firefox 3.5.4 candidate builds



9 years ago
9 years ago


(Reporter: nthomas, Assigned: erkan)




Firefox Tracking Flags

(blocking1.9.1 .4+, status1.9.1 .4-fixed)




9 years ago
Reported by dhtup in #firefox.

1, Get Firefox 3.5.4 build3 build for tr, eg 
(I haven't tried the mac but the problem appears to not be platform specific)
2, Visit bogus site like http://ww.sadfdsafdsafsd.com/

Get yellow XML error page
XML ayrıştırma hatası: uyumsuz biçim imi. Beklenen: </ul>.
Konum: jar:file:///C:/Program%20Files/Mozilla%20Firefox%203.5%20tr/chrome/toolkit.jar!/content/global/netError.xhtml
Satır: 319, Sütun: 34:        <div id="ed_dnsNotFound">&dnsNotFound.longDesc;</div>

dhtup says this translates as "XML parse error: invalid character. Expected </ul>".

Comment 1

9 years ago
The revision tagged for Firefox 3.5.4 is 

This revision
says it fixes an XML problem in netError.dtd, presumably line 1.7 & 1.8.

Axel, what should we do about this for 3.5.4 ?

Comment 2

9 years ago
Confirmed 3.6b1 build1 is not affected.
Summary: XML parse error in netError.dtd → XML parse error in netError.dtd for Firefox 3.5.4 candidate builds
I cross-checked revision fdb83f4b08fc, if we can take that, that'd be good. I am aware of the amount of respins we already had, of course. Bad month.

Not exactly sure what our options are here.
Background information for test failures:
This would require real xml parsing as part of tests, not just entity reference checks, or runtime testing.
This slipped in because I have my 1.9.1 data in a version of my sign-off tool that doesn't escape markup changes. That bug is fixed, but the new version hasn't yet been stable enough to invest in migrating the 1.9.1 data over, which is gonna be tough anyway.
(In reply to comment #3)

> Not exactly sure what our options are here.
This would require a respin, which we could do. 

We *might* be able to take some shortcuts with symlinks to avoid redoing everything. This might reduce schedule/testing impact but we're still figuring out possible consequences. 

If you feel this is serious enough to require a respin, please update this bug, and ask ss/beltzner to declare respin.
Hardware: x86 → All

Comment 6

9 years ago
To record the decision - coop is respinning Turkish build3 and the existing files will be overwritten.
Has anyone had a chance to try the new Turkish build3 so we can (hopefully) mark this as fixed?

Comment 8

9 years ago
> Has anyone had a chance to try the new Turkish build3 so we can (hopefully)
mark this as fixed?

I'll do.

BTW, I tested the fix mentioned above for 1.9.1, 1.9.2 and mozilla-central builds (built myself).
Rail, if you could test http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.5.4-candidates/build3/win32/tr/ or one of its siblings, that'd be great. Just to be really really sure.

Comment 10

9 years ago
win32 and linux-i686 builds from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.5.4-candidates/build3 have been tested. The XML parse error has gone.
Looks fine for me too. No XML error anymore with Mozilla/5.0 (Windows; U; Windows NT 5.1; tr; rv: Gecko/20091016 Firefox/3.5.4 (.NET CLR 3.5.30729) ID:20091016092926

Marking as WFM because there is no other bug filed which has been fixed this issue.
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
Ok, as talked with Axel on IRC it has been fixed by http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/tr/rev/fdb83f4b08fc. Let's mark it as fixed.
blocking1.9.1: --- → .4+
status1.9.1: --- → .4-fixed
Keywords: verified1.9.1
You need to log in before you can comment on or make changes to this bug.