1582187 - XML Parsing Error: undefined entity in Firefox 70 with language pack

Status: RESOLVED DUPLICATE of bug 1566084

(Firefox :: Untriaged, defect)

Description

[James [:FormularSumo]]

Attachment: Firefox not starting when clicked

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3907.0 Safari/537.36 Edg/79.0.278.0

Steps to reproduce:

Started up firerox by clicking firefox.exe

Actual results:

Firefox didn't start, white window in top left temporarily popped up then disappeared.

Expected results:

Firefox starts

Comment 1

[[:philipp]]

hi james, it might be the same issue (& solution) as discussed at https://old.reddit.com/r/firefox/comments/d5wq0z/firefox_crashes_on_browser_startup_and_flashes/f0ogadh/

Comment 3

[Francesco Lodolo [:flod]]

This is unfortunately a downside of how language packs work on unstable versions like Beta or DevEdition. The solution is to temporarily remove or disable the language pack in safe-mode, then reinstall the language pack in its latest version.

Comment 5

[ajf]

Maybe the way language packs work should be changed to have a failsafe rather than making the browser unusable?

Comment 6

[Francesco Lodolo [:flod]]

(In reply to ajf from comment #5)

Maybe the way language packs work should be changed to have a failsafe rather than making the browser unusable?

That is not a small task, and there's already work happening to get rid of the underlying cause (DTD strings)
https://arewefluentyet.com/

Removing DTDs would make YSOD impossible, removing it from the startup path would make unrecoverable errors like this one impossible.

I'm not exactly sure how to treat this bug, in the sense that it won't be fixed, and there are only workarounds to get back to a usable browser.

Comment 8

[Myron]

There is something I've noticed that may be related to removing and re-installing a language pack. Could be related or unrelated to this.

I've not yet pinned it down, but since I've got beta 7 working following advice to remove and then re-install a language pack I'm getting times where Firefox just freezes and I have to forcefully terminate FireFox. (Windows error reporting also ended up taking some time to upload it's report to Microsoft as I had killed Firefox 70b7 so many times. Just for the moment things appear to be ok.

Comment 10

[Myron]

Interestingly the issue still exists for me, but what's happened is, somehow, Firefox created a fresh profile and synced data from another FireFox installation. When I launch old profile I get the same error as pictured so I'm not sure if removing and reinstalling a language pack was the fix for me.

Comment 11

[Francesco Lodolo [:flod]]

Duping against bug 1566084, since there is an update to the language pack available when Firefox updates, and that would have avoided the problem.

Comment 14

[Brian Grinstead [:bgrins]]

I'd like to clarify what regressed this, was this by Bug 1579730? The screenshot in comment 1 seems to point to this element maybe: https://hg.mozilla.org/releases/mozilla-beta/rev/2395cdb35d69#l1.10.

Comment 15

[Francesco Lodolo [:flod]]

(In reply to Brian Grinstead [:bgrins] from comment #14)

I'd like to clarify what regressed this, was this by Bug 1579730? The screenshot in comment 1 seems to point to this element maybe: https://hg.mozilla.org/releases/mozilla-beta/rev/2395cdb35d69#l1.10.

Yes. We uplifted a patch that included a new DTD string, loaded on startup. Since the language packs are compatible with a version and not with a specific build, and we don't update them at startup, the old language pack remains in use and creates a YSOD.

We uplifted DTD changes in the past, but didn't get this amount of bug reports. The reality is that the amount of language pack users increased on the beta channel, and we should likely reject uplift requests for any patch including new DTDs from now on.

Comment 16

[Robert Strong (they/them - no direct email)]

The issue bug 1566084 is suppose to address used to be handled on Firefox version change to a newer version by the add-ons manager's incompatible add-on check UI that was shown on startup and was removed without a replacement. So, it handled it when there was an update as well as when there was an upgrade due to installing a newer version. Bug 1566084 as described will never handle the upgrade scenario when installing a newer version since that happens without using app update.

Also, this issue affects beta which wouldn't have a version change afaik so for bug 1566084 to fix this bug app update would have to signal the add-ons manager that an update was available even for updates without a version change. This seems overkill especially for nightly builds which currently update twice a day.

I personally don't think bug 1566084 is a good fix for this bug due to both of these issues.