Closed Bug 1548990 Opened 5 years ago Closed 5 years ago

Localized build Nightly68 does not start - browser.xul XML parse error

Categories

(Firefox :: Untriaged, defect)

68 Branch
defect
Not set
blocker

Tracking

()

RESOLVED FIXED
Firefox 68
Root Cause ?
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;
^

This looks like a more detailed report of same problem: Bug 1548999

he, ja locale build Nightly on Windows10 are also affected

Severity: normal → critical
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true
Keywords: regression
OS: Linux → All
Severity: critical → blocker
Summary: Firefox does not start - browser.xul XML parse error → Localized build Nightly68 does not start - browser.xul XML parse error

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.

Flags: needinfo?(lhenry)

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

Passing that n-i to julien both because I'm getting pretty tired and because he's 68 owner

Flags: needinfo?(lhenry) → needinfo?(jcristau)

Does this happen for our regular l10n repacks, or in cases where an extra langpack has been installed?

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

Flags: needinfo?(peterv)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(gandalf)
Summary: Localized build Nightly68 does not start - browser.xul XML parse error → [nightly updates disabled] Localized build Nightly68 does not start - browser.xul XML parse error

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

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

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.

Flags: needinfo?(gandalf)

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

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

Flags: needinfo?(peterv)
Flags: needinfo?(gijskruitbosch+bugs)

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

Fixed by backout. Updates on the nightly channel are now re-enabled.

https://hg.mozilla.org/mozilla-central/rev/24a6a4f933a8

Flags: needinfo?(jcristau)
Summary: [nightly updates disabled] Localized build Nightly68 does not start - browser.xul XML parse error → Localized build Nightly68 does not start - browser.xul XML parse error
Target Milestone: --- → Firefox 68
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED

Please specify a root cause for this bug. See :tmaity for more information.

Root Cause: --- → ?
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.