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

Status: RESOLVED FIXED

(Mozilla Localizations :: tr / Turkish, defect)

Description

[Nick Thomas [:nthomas] (UTC+12)]

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>".

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

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 ?

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

Confirmed 3.6b1 build1 is not affected.

Comment 3

[Axel Hecht [:Pike]]

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.

Comment 4

[Axel Hecht [:Pike]]

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.

Comment 5

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(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.

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

To record the decision - coop is respinning Turkish build3 and the existing files will be overwritten.

Comment 7

[Chris Cooper [:coop] (he/him)]

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

Comment 8

[Rail Aliiev [:rail]]

> 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).

Comment 9

[Axel Hecht [:Pike]]

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

[Rail Aliiev [:rail]]

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.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Looks fine for me too. No XML error anymore with Mozilla/5.0 (Windows; U; Windows NT 5.1; tr; rv:1.9.1.4) 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.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.