Closed Bug 522989 Opened 14 years ago Closed 14 years ago

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


(Mozilla Localizations :: tr / Turkish, defect)

Not set


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

Tracking Status
blocking1.9.1 --- .4+
status1.9.1 --- .4-fixed


(Reporter: nthomas, Assigned: erkan)


(Keywords: verified1.9.1)

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

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>".
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 ?
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
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?
> 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 or one of its siblings, that'd be great. Just to be really really sure.
win32 and linux-i686 builds from 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.
Closed: 14 years ago
Resolution: --- → WORKSFORME
Ok, as talked with Axel on IRC it has been fixed by Let's mark it as fixed.
blocking1.9.1: --- → .4+
You need to log in before you can comment on or make changes to this bug.