Closed Bug 1420775 Opened 2 years ago Closed 2 years ago

Startup error; Undefined entity <menuitem class="pageActionContextMenuItem extensionUnpinned"

Categories

(Toolkit :: Add-ons Manager, defect, P2)

58 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla59
Tracking Status
firefox-esr52 --- unaffected
firefox57 --- unaffected
firefox58 + wontfix
firefox59 --- verified

People

(Reporter: yannik, Assigned: kmag)

References

Details

(Keywords: regression)

Attachments

(3 files)

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171113102334

Steps to reproduce:

Suddenly, when starting Firefox Developer Edition 58.0b6, it fails with the following error message:

XML read error: entity not defined
Location: chrome://browser/content/browser.xul
Line Number 1165, Column 7:      <menuitem class="pageActionContextMenuItem extensionUnpinned"

This very same issue has been reported on stackoverflow already: https://stackoverflow.com/questions/47411800/driver-error-in-firefox-quantum-with-selenium-and-xul

I tried to resolve this by:
 - Reinstalling firefox developer edition
 - removing all addons
 - removing my profile and creating a new one

In safe mode firefox starts without issues, but even with a new profile (no addons, nothing) it still fails to start
Component: Untriaged → General
Summary: Startup crash; Undefined entity <menuitem class="pageActionContextMenuItem extensionUnpinned" → Startup error; Undefined entity <menuitem class="pageActionContextMenuItem extensionUnpinned"
sounds like localization issue.
do you have extra locale installed?
if so, try removing it.
it may be installed via distro package manager in some case.
Flags: needinfo?(yannik)
(In reply to Tooru Fujisawa [:arai] from comment #1)
> sounds like localization issue.
> do you have extra locale installed?
> if so, try removing it.
> it may be installed via distro package manager in some case.

This is on Fedora 27. I do not have any extra locales installed:

 ~ sudo dnf list installed |grep firefox
firefox.x86_64                          57.0-2.fc27                     @updates

The bug persists with Firefox Developer Edition 58.0b9 (aurora channel)
Flags: needinfo?(yannik)
what locale is used for firefox UI when you start firefox in safe mode?
(In reply to Tooru Fujisawa [:arai] from comment #3)
> what locale is used for firefox UI when you start firefox in safe mode?

German language is used for UI elements when starting in safe mode.

When the bug suddenly appeared with the (german) dev-edition I used for atleast a year without issue, I also tried an additional fresh installation from the german firefox developer edition page, using the following download link:
https://download.mozilla.org/?product=firefox-devedition-latest-ssl&os=linux64&lang=de

To no avail. Both the installation I had in use for a long time, and the newly installed one do have the same bug.
See Also: → 1423793
I just tried downloading the latest german devedition, couldn't reproduce.
Francesco, any idea what could be going on here?
Flags: needinfo?(francesco.lodolo)
Adding a few l10n people, since I'm out of ideas. 

My first guess would be en-US build with a broken German language pack installed (or a language pack for another version, but compatibility checks should prevent that). But he tried creating a new profile and also an official build, and that should fix the problem.

@yannik
To clarify: is it still broken with this? Even creating a new profile? I assume you get to the Profile Manager, and this error shows up only when loading the browser window
https://www.mozilla.org/de/firefox/channel/desktop/#developer
Flags: needinfo?(francesco.lodolo) → needinfo?(yannik)
Francesco: I have just tried this again with the link you provided; same problem, even with a new profile.

The Profile Manager starts perfectly fine, the errors occurs when starting the browser.

I'd very much appreciate any fixes to this.
Flags: needinfo?(yannik)
Duplicate of this bug: 1428983
Copying some info over from bug 1428983, since I feel we're spreading the discussion in too many places.

Bug 1428983:
* Fedora 27 (kernel 4.14.11-300), Firefox Nightly downloaded from ftp.mozilla.org (not Fedora's package)
* It works in safe-mode
* Both Nightly and Beta show the YSOD

Nightly

> Chyba parsování XML: Nedefinovaná entita
> Adresa: chrome://browser/content/browser.xul
> Řádek 667, sloupec 9:        <menuitem id="context-back"
> --------^

Beta 58.0b3

> Chyba parsování XML: Nedefinovaná entita
> Adresa: chrome://browser/content/browser.xul
> Řádek 1165, sloupec 7:      <menuitem class="pageActionContextMenuItem extensionUnpinned"
> ------^

Both this bug and bug 1428983 have Fedora in common. Bug 1423793 has a different distro.
Installed Fedora 27 in a VM (Fusion on macOS), language set to Italian.

$ locale
LANG=it_IT.UTF-8
LC_CTYPE="it_IT.UTF-8"
LC_NUMERIC="it_IT.UTF-8"
LC_TIME="it_IT.UTF-8"
LC_COLLATE="it_IT.UTF-8"
LC_MONETARY="it_IT.UTF-8"
LC_MESSAGES="it_IT.UTF-8"
LC_PAPER="it_IT.UTF-8"
LC_NAME="it_IT.UTF-8"
LC_ADDRESS="it_IT.UTF-8"
LC_TELEPHONE="it_IT.UTF-8"
LC_MEASUREMENT="it_IT.UTF-8"
LC_IDENTIFICATION="it_IT.UTF-8"
LC_ALL=

1) Pre-installed Firefox starts without issues

57.0.4 (64 bit)
Mozilla Firefox for Fedora
fedora - 1.0

2) Downloaded Nightly in Italian
https://download.mozilla.org/?product=firefox-nightly-latest-l10n-ssl&os=linux64&lang=it

Started Nightly with the existing profile (on purpose). It works normally.

If I create a new profile though, I get the YSOD error. Investigating.

Note that this doesn't happen for me on Ubuntu, so I still have the feeling it's something in the distro.
In ~/.mozilla/extensions, there is an Italian language pack

~/.mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/langpack-it@firefox.mozilla.org.xpi

Removing that folder, lets me create a new profile without issues.

The install.rdf file is correct in terms of compatibility

<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
<em:minVersion>57.0.4</em:minVersion>
<em:maxVersion>57.*</em:maxVersion>

Are we completely ignoring compatibility checks for language packs?
Final note: the only way for me to start one of the broken profiles is to remove the folder and delete extensions.json

@zibi
Any idea about comment 12? Feel free to redirect the NI
Flags: needinfo?(gandalf)
Francesco: Glad you were able to reproduce the issue. You wrote it only occured after creating a new profile - for me it happened with my normal profile one day without any changes (i.e. creating/changing profiles) on my side.

However, I'd like to add, that most often I had to open firefox twice after changing/creating a profile to have the error occur. On the first time. Maybe you can try starting FF with the default profile atleast twice/thrice to broaden your test case.
Flags: needinfo?(francesco.lodolo)
(Unfortunately, I'm unable to edit my comment). 

Can we get this bug marked as CONFIRMED?
(In reply to yannik from comment #14)
> Francesco: Glad you were able to reproduce the issue. You wrote it only
> occured after creating a new profile - for me it happened with my normal
> profile one day without any changes (i.e. creating/changing profiles) on my
> side.

Not completely sure why that could happen. Maybe Fedora updated the language pack in .mozilla/extensions?

> However, I'd like to add, that most often I had to open firefox twice after
> changing/creating a profile to have the error occur. On the first time.
> Maybe you can try starting FF with the default profile atleast twice/thrice
> to broaden your test case.

I tried restarting the "default" profile several times (the one created with the 57 Fedora build), and it keeps working.

I have no idea how to debug this, but I wonder if the language pack is ignored in the "default" profile because it upgraded from 57 to 59, and that disabled it, while compatibility checks are ignored with on a new profile.

I can safely reproduce this: create a profile with 57 (Fedora bundled), start the same profile with 59, and that profile works. Create a new profile, it's broken.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(francesco.lodolo)
Francesco: Let me clarify this. I never swapped profiles between stable (57) and developer (59) or did anything alike. 
I was using this installation of FF developer edition since maybe FF 50, with just one profile. As I was starting the browser one day, suddenly the bug appeared.

I only tried creating a new profile afterwards, because I thought the issue was somehow related to the profile (maybe a faulty addon or similar).
I am not totally sure, but from my memory it's not unlikely this happened just after my installation of dev edition updated itself. Perhaps to the version I initially mentioned, but I think not, as I only opened the bug after it still didn't work after a week or so.
(In reply to yannik from comment #17)
> I was using this installation of FF developer edition since maybe FF 50,
> with just one profile. As I was starting the browser one day, suddenly the
> bug appeared.

Maybe the language pack was always there (from Fedora's package), but it was correctly ignored. And at some point, we stopped checking correctly for compatibility.
[Tracking Requested - why for this release]: it looks like we fail to ignore existing language packs that are not compatible with the version of Firefox currently running.
A couple of questions:

- in an unaffected profile, can you install the broken language pack? I'd like to find out if this is just startup.
- in a broken file, what information about the langpack is in extensions.json and addons.json (which hopefully corresponds to the lz4 version)?
(In reply to Axel Hecht [:Pike] from comment #21)
> - in an unaffected profile, can you install the broken language pack? I'd
> like to find out if this is just startup.

No, I can't. Note that this is an old-style language pack with install.rdf, and that was blocked in bug 1413322.

> - in a broken file, what information about the langpack is in
> extensions.json and addons.json (which hopefully corresponds to the lz4
> version)?

addons.json is empty. 

{"schema":5,"addons":[]}

The one inside .lz4 is pretty much unreadable for me, but I can spot a reference to the language pack.

extensions.json
Plenty of references to the add-on ID
Moving NI per IRC conversation.

Summary:
* There's a language pack (old style) in ~/.mozilla/extensions, with compatibility set to 57. This is placed by Fedora 27, which ships Firefox 57.
* If you create a new profile with 59 or 58, it doesn't start. Profile manager starts, the profile itself dies with a YSOD.

Naive question: we don't check for compatibility when the add-on is installed from ~/.mozilla/extensions? Not sure if that happens only with old-style language packs, or also with webext langpacks.

At least in my case, reusing a profile created in 57 with a newer version works, I assume because the language pack gets correctly disabled.

Can you help figuring out what's going on?
Flags: needinfo?(kmaglione+bmo)
Flags: needinfo?(gandalf)
Flags: needinfo?(aswan)
(In reply to Francesco Lodolo [:flod] from comment #22)
> The one inside .lz4 is pretty much unreadable for me, but I can spot a
> reference to the language pack.

For future reference:

https://gist.github.com/823aa149dcc6103b6348bd5117914105
Component: General → Add-ons Manager
Product: Firefox → Toolkit
I can reproduce this on Ubuntu by storing
https://ftp.mozilla.org/pub/firefox/releases/57.0.4/linux-x86_64/xpi/it.xpi

as
~/.mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/langpack-it@firefox.mozilla.org.xpi

and creating a new profile from Nightly (59).

If I try the same with a 58b langpack (webext), everything seems to work as expected
https://ftp.mozilla.org/pub/firefox/releases/58.0b15/linux-x86_64/xpi/it.xpi
It looks like what's happening is that we scan the user system add-ons directory at startup, notice the langpack, and add it to XPIStates, and trigger a database rebuild... and then something goes wrong. The install.rdf doesn't have a valid type in 58+, so it doesn't get added to the DB. But it also doesn't get removed from XPIStates or marked disabled. And since XPIStates are what we use to register non-bootstrapped chrome.manifest files, the add-on's manifest gets registered.

We should probably leave the XPI in XPIStates so that we don't trigger a rebuild on every startup, and just mark it disabled.
Flags: needinfo?(kmaglione+bmo)
If this is a regression in 58, we may have to consider blocking on it as it will break a lot of workflows - namely people who installed Firefox dev edition on Linux if they already have stable Firefox installed.

If this behavior already existed previously, then I believe it's a regular bug and we should prioritize it accordingly.
Duplicate of this bug: 1423793
Hi Florin,
Can you help find some QA to check if this issue is a new regression in 58 or it has been there?
Flags: needinfo?(florin.mezei)
I was unable to reproduced this issue with build 58.0b6 and 58.0b9 DevEd, under Ubuntu (12.04 x32, 16.04 x64). 
Due to some technical difficulties, we couldn't test this on a Fedora machine but we will sort things out on Monday, retest it on  and come back with a final conclusion. Leaving needinfo on myself as a reminder.
Flags: needinfo?(florin.mezei) → needinfo?(bogdan.maris)
(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #32)
> I was unable to reproduced this issue with build 58.0b6 and 58.0b9 DevEd,
> under Ubuntu (12.04 x32, 16.04 x64). 

Just in case: did you follow the steps described in comment 27?
This is a regression in 58. Prior to 58, langpack install.rdfs were supported, so the extension compatibility got updated correctly on upgrade.
Should this block 58 then? I'm worried about the impact on the Linux dev population
Sorry for the slow reply but Kris has a handle on this and I'm about to be on PTO for a week so lets put this in his capable hands.
Assignee: nobody → kmaglione+bmo
Flags: needinfo?(aswan)
(In reply to Francesco Lodolo [:flod] from comment #33)
> (In reply to Bogdan Maris, QA [:bogdan_maris] from comment #32)
> > I was unable to reproduced this issue with build 58.0b6 and 58.0b9 DevEd,
> > under Ubuntu (12.04 x32, 16.04 x64). 
> 
> Just in case: did you follow the steps described in comment 27?

I missed that.., I retested again today on Ubuntu and Fedora, here are the results:

I reproduced this bug on Fedora (22 x64) with 58.0b6 DevEdition (de) and the latest Nightly (2018-01-14) (de), after changing the language of the os to german. I retested in order to find a regression and  obtained the following results:
Last good: 20171103220715
First bad: 20171104100412
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=66f496680fae6e7d8f02bc17ff58b9234ee07c70&tochange=14fd26761bc4d10c5334abe50d7b6f3a5908f08d

I was able to reproduce this issue, after all, on Ubuntu (16.04 x64) with 58.0b6 DevEdition (it) and the latest Nightly (2018-01-14) (it), according to comment 27. The regression range was different from the one obtained on Fedora: 
Last good: 20171110100139
First bad: 20171111100349
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=864174ac0707207f7fc698ed6c3c47c043e99395&tochange=57eb0baf17ce8678767abfbf17bdb0acfd8909ad

Moreover i was able to detect that even after the start-up, an error appears in about:support starting with the second nightly build from 2017-11-08:

> Errore interpretazione XML: entità non definita Indirizzo: 
> jar:file:///home/bogdan.maris/Desktop/firefox%20(5)/omni.ja!/chrome/toolkit/content/global/aboutSupport.xhtml Riga numero 701, colonna 9:
>        &aboutSupport.intlTitle;
> --------^
Last good: 20171108110838
First bad: 20171108221316
Pushlog: Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7851d6768dfd9fe5568d1315a98f142d9bb9234f&tochange=f63559d7e6a570e4e73ba367964099394248e18d
Flags: needinfo?(bogdan.maris)
(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #37)
> (In reply to Francesco Lodolo [:flod] from comment #33)
> > (In reply to Bogdan Maris, QA [:bogdan_maris] from comment #32)
> > > I was unable to reproduced this issue with build 58.0b6 and 58.0b9 DevEd,
> > > under Ubuntu (12.04 x32, 16.04 x64). 
> > 
> > Just in case: did you follow the steps described in comment 27?
> 
> I missed that.., I retested again today on Ubuntu and Fedora, here are the
> results:
> 
> I reproduced this bug on Fedora (22 x64) with 58.0b6 DevEdition (de) and the
> latest Nightly (2018-01-14) (de), after changing the language of the os to
> german. I retested in order to find a regression and  obtained the following
> results:
> Last good: 20171103220715
> First bad: 20171104100412
> Pushlog:
> https://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=66f496680fae6e7d8f02bc17ff58b9234ee07c70&tochange=14fd
> 26761bc4d10c5334abe50d7b6f3a5908f08d
> 

Thanks for finding the regression ranges.

Bug 1413322, stop loading legacy langpacks, is in that first regression range.
Priority: -- → P2
Comment on attachment 8943361 [details]
Bug 1420775: Mark detected add-ons initially disabled.

https://reviewboard.mozilla.org/r/213688/#review219784
Attachment #8943361 - Flags: review?(rhelmer) → review+
Comment on attachment 8943361 [details]
Bug 1420775: Mark detected add-ons initially disabled.

https://reviewboard.mozilla.org/r/213688/#review219980

::: toolkit/mozapps/extensions/test/xpcshell/test_invalid_install_rdf.js:50
(Diff revision 1)
> +    targetApplications: [{
> +      id: "xpcshell@tests.mozilla.org",
> +      minVersion: "1",
> +      maxVersion: "1"
> +    }],
> +    name: "Invalid install.rdf extension",

shouldn't this one say "Valid"?
Comment on attachment 8943361 [details]
Bug 1420775: Mark detected add-ons initially disabled.

https://reviewboard.mozilla.org/r/213688/#review219980

> shouldn't this one say "Valid"?

Yes. Thanks.
Every time I've tried to land this, trees have been closed for a different reason. So for once, I'm going to try autoland...
Pushed by maglione.k@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/45db28ced0f7
Mark detected add-ons initially disabled. r=rhelmer
https://hg.mozilla.org/mozilla-central/rev/45db28ced0f7
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Does this mean, this will only be fixed in 59 and not in the upcoming 58 release? I dearly hope not.
(In reply to yannik from comment #46)
> Does this mean, this will only be fixed in 59 and not in the upcoming 58
> release? I dearly hope not.

This is going to be available in Nightly later today (or tomorrow), 58 is going to be released on Tuesday, so there's no time to include it.

I assume, depending on the volume of bugs reported, it could be considered as a ride-along for a dot release.

In the meantime, it would be great to verify that the problem is indeed fixed with the upcoming Nightlies.
Verified on Fedora, 59.0a1 (2018-01-21) (64 bit)
Status: RESOLVED → VERIFIED
Duplicate of this bug: 1433744
Please nominate this for mozilla-release approval so it's on the radar for Fx58 dot release consideration. It grafts cleanly as-landed.
Flags: needinfo?(kmaglione+bmo)
Flags: in-testsuite+
I don't think there's much point in uplifting to release at this point. The bad entries are already in XPIStates for existing profiles. If we want to fix existing broken profiles, I think we need to change the DB reconciliation code.
Flags: needinfo?(kmaglione+bmo)
You need to log in before you can comment on or make changes to this bug.