Localized build Nightly68 does not start - browser.xul XML parse error
Categories
(Firefox :: Untriaged, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox66 | --- | unaffected |
firefox67 | --- | unaffected |
firefox68 | blocking | fixed |
People
(Reporter: r01opd9cujmm, Unassigned)
References
(Regression)
Details
(Keywords: dogfood, regression)
Since the update to Firefox Nightly 2019-05-03-21-56-39 (ja locale), Firefox does not start because of an XML parse error in chrome://browser/content/browser.xul
, line 31 column 1:
%browserDTD;
^
Comment 1•6 years ago
|
||
This looks like a more detailed report of same problem: Bug 1548999
Comment 2•6 years ago
|
||
he, ja locale build Nightly on Windows10 are also affected
Updated•6 years ago
|
Updated•6 years ago
|
Comment 4•6 years ago
|
||
Very likely related to bug 1548973.
Comment 5•6 years ago
|
||
I disabled Nightly updates entirely for this bug, while work on figuring out what and why is ongoing.
sending a n-i to liz from relman for this action.
Is this 64-bit Windows only, or does it happen on other platforms?
(It looks like Linux and Mac localized nightlies happened clearly before the cert expiration, 64-bit Windows nightlies were clearly after, and 32-bit Windows looks like mostly but maybe not completely before.)
Comment 7•6 years ago
|
||
Passing that n-i to julien both because I'm getting pretty tired and because he's 68 owner
Comment 8•6 years ago
|
||
Does this happen for our regular l10n repacks, or in cases where an extra langpack has been installed?
Comment 9•6 years ago
•
|
||
The latest Greek macOS Nightly from https://www.mozilla.org/en-US/firefox/nightly/all/ is broken. I see a brief flash of a browser window with an XML parsing error before it closes without any console output.
Callek pointed out https://hg.mozilla.org/mozilla-central/rev/03166449953fbcaaf6c66d2c3b358319781a0e52 as a possible cause. Is that plausible/likely?
(This may interfere with pushing fixes for the addons situation to nightly users, which makes it pretty urgent, since nightlies are disabled and we may need to reenable them urgently.)
Comment 11•6 years ago
|
||
(In reply to David Baron :dbaron: 🏴 ⌚UTC-7 from comment #10)
Callek pointed out https://hg.mozilla.org/mozilla-central/rev/03166449953fbcaaf6c66d2c3b358319781a0e52 as a possible cause. Is that plausible/likely?
(This may interfere with pushing fixes for the addons situation to nightly users, which makes it pretty urgent, since nightlies are disabled and we may need to reenable them urgently.)
kmag confirmed that this is the culprit. I'll ask the sheriffs for a backout.
Comment 12•6 years ago
|
||
To repeat my comment from bug 1539759, the browser.dtd for the ja locale has entities with embedded markup, which are rejected by the new DTD parser restrictions:
browser/chrome/ja/locale/browser/browser.dtd:<!ENTITY panicButton.view.deleteCookies "最近の <html:strong>Cookies</html:strong> を削除します">
es-MX is also broken, and has similar entities in browser.dtd:
<!ENTITY panicButton.view.deleteCookies "Se borran los <html:strong>Cookies</html:strong> recientes">
<!ENTITY panicButton.view.deleteHistory "Se borran el <html:strong>Historial</html:strong> reciente">
<!ENTITY panicButton.view.deleteTabsAndWindows "Se cierran las <html:strong>Pestañas</html:strong> y <html:strong>Ventanas</html:strong>">
...
<!ENTITY addonPostInstallMessage.label "Administra tus complementos haciendo clic <image class='addon-addon-icon'/> en el <image class='addon-toolbar-icon'/> menú.">
Comment hidden (off-topic) |
Comment 15•6 years ago
•
|
||
For reference, I've run a quick check when I got CCed to the bug (after it landed the first time), and fixed a few potential issues (about 5 locales).
The check I've run was looking for HTML tags where en-US had none, but all the examples here have them in English as well.
https://transvision.mozfr.org/string/?entity=browser/chrome/browser/browser.dtd:addonPostInstallMessage.label&repo=gecko_strings
It was all but clear that this would affect only locales, and not en-US, which seems to be the case here.
(In reply to Builderb from comment #14)
The US localized build is working
Sorry, that's not a work-around.
Comment 18•6 years ago
|
||
(In reply to Francesco Lodolo [:flod] from comment #15)
For reference, I've run a quick check when I got CCed to the bug (after it landed the first time), and fixed a few potential issues (about 5 locales).
The check I've run was looking for HTML tags where en-US had none, but all the examples here have them in English as well.
https://transvision.mozfr.org/string/?entity=browser/chrome/browser/browser.dtd:addonPostInstallMessage.label&repo=gecko_stringsIt was all but clear that this would affect only locales, and not en-US, which seems to be the case here.
No, it isn't, that entity no longer exists on Nightly for en-US, after bug 1523757 (fixed nearly 3 weeks ago). I dunno where transvision gets that data, but it's wrong.
This only affects locales where entities that have already been removed from en-US still exist. It seems https://hg.mozilla.org/mozilla-central/rev/03166449953fbcaaf6c66d2c3b358319781a0e52 was backed out so I don't think more needs to be done on the m-c side here.
Comment 19•6 years ago
|
||
(In reply to :Gijs (he/him) from comment #18)
No, it isn't, that entity no longer exists on Nightly for en-US, after bug 1523757 (fixed nearly 3 weeks ago). I dunno where transvision gets that data, but it's wrong.
It's not. All shipping versions of Firefox come out of a single repository with a superset of strings covering nightly, beta, release.
At this point, we should continue the conversation in bug 1539759.
Updated•6 years ago
|
Comment 23•6 years ago
|
||
Fixed by backout. Updates on the nightly channel are now re-enabled.
Updated•6 years ago
|
Comment 24•5 years ago
|
||
Please specify a root cause for this bug. See :tmaity for more information.
Updated•3 years ago
|
Description
•