Reported by dhtup in #firefox. Steps. 1, Get Firefox 3.5.4 build3 build for tr, eg http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.5.4-candidates/build3/linux-i686/tr/firefox-3.5.4.tar.bz2 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.5.4-candidates/build3/win32/tr/Firefox%20Setup%203.5.4.exe (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>".
The revision tagged for Firefox 3.5.4 is http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/tr/rev/32fa723323f2 This revision http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/tr/rev/fdb83f4b08fc 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.
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 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.
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:18.104.22.168) 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.
Status: NEW → RESOLVED
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.
Resolution: WORKSFORME → FIXED
blocking1.9.1: --- → .4+
status1.9.1: --- → .4-fixed
You need to log in before you can comment on or make changes to this bug.