Closed Bug 1423793 Opened 7 years ago Closed 6 years ago

XML Parsing Error undefined entity

Categories

(Toolkit :: Startup and Profile System, defect)

Product:
Toolkit
Component:
Startup and Profile System
Version:
59 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1420775

People

(Reporter: u123541, Unassigned)

References

Details

(Keywords: nightly-community) 

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20171202100103

Steps to reproduce:

Linux Mageia 6   59.0a1 (2017-12-06) (64-bit)
[Version does not yet include "59 Branch"]

1. create new userid
2. start Nightly (/usr/local/bin/firefox/firefox)


Actual results:

Get small window containing:

XML Parsing Error: undefined entity
Location: chrome://browser/content/browser.xul
Line Number 346, Column 5:    <key id="key_quitApplication" key="&quitApplicationCmd.key;"
----^

If I start into profile manager (-P), I can setup a new "Default User" profile; but Start Nightly gives same error.


Expected results:

Whatever should happen first time Nightly is run on a new [virgin] userid.

Nightly runs fine on older existing userids.
Component: Untriaged → Startup and Profile System
Product: Firefox → Toolkit
What is your locale (Firefox)?
Flags: needinfo?(pf)
See Also: → 1420775
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
Flags: needinfo?(pf)
You are using the English version of Firefox?
Yes. You sound surprised...  :)
The errors often occurs while language packs that are incorrect or mismatched.


Can you try the https://mozilla.github.io/mozregression/ to find the regression range?
Keywords: nightly-community
Version: 58 Branch → 59 Branch
[this comment collided -- will check regression...]
Interesting...  just tried starting with:
  /usr/local/bin/firefox/firefox -safe-mode 
and it starts fine.  That would indicate plugin/extension issues; but there's only the OpenH264 Video Codec.
59.0a1 (2017-12-07) (64-bit) won't start normally.
Where is mozregression trying to install?  I'm getting:
2017-12-07T16:29:26: INFO : Running mozilla-central build for 2017-12-04
2017-12-07T16:29:26: ERROR : Unable to install '/home/testff/.mozilla/mozregression/persist/2017-12-04--mozilla-central--firefox-59.0a1.en-US.linux-x86_64.tar.bz2'
2017-12-07T16:29:26: INFO : Stopped
I don't know, maybe some errors occurred during installation (unzip).

https://bugzilla.mozilla.org/enter_bug.cgi?product=Testing&component=mozregression
(In reply to YF (Yang) from comment #8)
> I don't know, maybe some errors occurred during installation (unzip).

sorry, tar.bz2 for you.
The "tar xf" was fine. It installed in .mozilla/mozregression  Started it and tried "Run single build" and it downloaded 2017-12-04--mozilla-central--firefox-59.0a1.en-US.linux-x86_64.tar.bz2; then gave the above errors.

I'm having to manually install the binaries for testing...  It's been a LONG time since I tried running FF on a virgin account, so this could be a really old bug...
OK...  12-04 and 12-01 failed.  11-01 starts; but now that it created the ~/.mozilla directory, the others work.  So I'll have to remove the .mozilla directory to see where the problem starts -- looks like sometime between 11-01 and 12-01 for now.
Unfortunately, the nature of this bug is such that .mozilla needs to be created fresh on each test; so having mozregression downloads image files into ~/.mozilla/mozregression/persist/ which is an extra problem.  My steps at the moment are:
- mkdir -p ~/.mozilla/mozregression/persist/  # temp for download only
- # use mozregression to download an image into it; would be easier if I had a wget path to use
- mv ~/.mozilla/mozregression/persist/* FF/  # move the downloaded for safekeeping
- tar -C bin -xf FF/<image>.tar.bz2 
- mv bin/firefox bin/firefoxMMDD  # date the version
- rm -rf ~/.mozilla   # must remove it to test for this bug
- bin/firefoxMMDD/firefox
- mv ~/.mozilla ~/.mozillaMMDD  # save it as matching version

Repeat to continue binary search.  

The point is that mozregression should not download into ~/.mozilla; and having a way to manage the image and .mozilla versions would help for bugs like this one.

Once I track down the version which begins failing, I'll compare two .mozillaMMDD directories (without mozregression in them)...
OK...  the bug first appeared in 2017-11-04.

$ diff -r .mozilla1103/ .mozilla1104/
Only in .mozilla1103/firefox/Crash Reports: InstallTime20171103220715
Only in .mozilla1104/firefox/Crash Reports: InstallTime20171104220420
Only in .mozilla1104/firefox: fpx1949p.default
Only in .mozilla1103/firefox: lc6buygg.default
diff -r .mozilla1103/firefox/profiles.ini .mozilla1104/firefox/profiles.ini
7c7
< Path=lc6buygg.default
---
> Path=fpx1949p.default

Without a ~/.mozilla directory, 1104 and later fail. 
Without a ~/.mozilla directory, 1103 and earlier work. 

With a ~/.mozilla directory created by 1104 and later. 1104 and later fail.
With a ~/.mozilla directory created by 1103 and earlier. 1104 and later work.

With a ~/.mozilla directory created by 1104 and later; then running 1103 and earlier, 1104 and later now work.

I thought about providing copies of .mozilla1103 and .mozilla1104; but diff above shows virtually no differnce, so it might be best to see the bug for yourselves...
Where do you install Firefox from? Sorry if you already provided that information and I missed it.

The key that is marked as missing was changed over 7 months ago, I wonder if there's a language pack somewhere messing things up
https://hg.mozilla.org/mozilla-central/rev/5be871146313
(In reply to Francesco Lodolo [:flod] from comment #15)
> Where do you install Firefox from? Sorry if you already provided that
> information and I missed it.

To clarify, I meant Firefox before you started trying mozregression.
You're on linux. Is there a chance you have an outdated language pack that is registering old resources for your Firefox?
Can you verify in ~/.mozilla/extensions if there's a language pack from the distro? If it's there, can you try removing it and create a new profile?
Flags: needinfo?(pf)
I never use language packs.  Today, there is a minor change in the output:

XML Parsing Error: undefined entity
Location: chrome://browser/content/browser.xul
Line Number 347, Column 5:    <key id="key_quitApplication" key="&quitApplicationCmd.key;"
----^

Line number changed from 346 to 347.  And...  the "Line Number..." line has always had &lt; and &gt; around it; the next line points to &lt;   (missed that bugzilla hides some characters).
Flags: needinfo?(pf)
It doesn't matter if you never installed a language pack yourself, the distro could have done it for you. Can you check ~/.mozilla/extensions?

> Can you verify in ~/.mozilla/extensions if there's a language pack from the
> distro? If it's there, can you try removing it and create a new profile?
I've never seen it do that...
$ ll -a .mozilla/extensions/
total 8
drwxr-xr-x 2 fftest fftest 4096 Oct 17  2014 ./
drwxr-xr-x 6 fftest fftest 4096 Jan  9 09:00 ../
(In reply to Pierre Fortin from comment #21)
> I've never seen it do that...
> $ ll -a .mozilla/extensions/

This is in your Unix user folder (~)? Or is it the extensions folder in your (Firefox) profile? Can you check both?
This is a VIRGIN linux account as indicated in the original report. The only thing I've done on that userid was to try to start Nightly; nothing else. There are no extensions available to this userid.
(In reply to Pierre Fortin from comment #23)
> This is a VIRGIN linux account as indicated in the original report.

That's clear, what I'm trying to explain is that it might not matter. I've only seen this kind of errors on Linux, with obsolete language packs lingering around and put there by the distribution (e.g. bug 1420775). 

The fact that you can reach the profile manager (language pack is not active yet), but not the main window is another symptom of a broken language pack.

Does Linux Mageia 6 ship with Firefox by default (stable or ESR release)? What's the language of your distribution? If Linux Mageia ships Firefox, and your distribution is in French, you might have a French language pack somewhere.

I'm not trying to waste your time, just to figure out what's going on. If you could answer comment 22, that would help. If there are no language packs, then I'm out of explanations.
Well, I never installed a language pack - ever. I use Mageia 6 as provided (English only AFAIK).  Does this help?:
$ echo $LANGUAGE
en_US.UTF-8:en_US:en
$ echo $LANG
en_US.UTF-8
$ rpm -qa | grep lang
liblangtag-data-0.6.2-3.mga6
lib64langtag1-0.6.2-3.mga6
lib64slang2-2.3.0-1.mga6
libreoffice-langpack-en-5.3.4.2-3.mga6
liblangtag-0.6.2-3.mga6

Re comment 22: sorry, I assumed "ll -a .mozilla/extensions/" was clear since .mozilla is always(?) in ~.

The virgin account is virtually empty. After starting Nightly with /usr/local/bin/firefox/firefox, it adds lots of dirs/files -- maybe there's a clue based on how far it gets in creating those. Here are the very last dir/files it created before(?) displaying the error:
$ ll -R --full-time .mozilla/
.mozilla/firefox:
drwx------ 8 fftest fftest 4096 2018-01-10 23:15:28.342221883 -0500 rtd12oaw.default/

.mozilla/firefox/rtd12oaw.default:
-rw-rw-r-- 1 fftest fftest       0 2018-01-10 23:15:28.322221552 -0500 SecurityPreloadState.txt
-rw-rw-r-- 1 fftest fftest     604 2018-01-10 23:15:28.322221552 -0500 SiteSecurityServiceState.txt
-rw-rw-r-- 1 fftest fftest       4 2018-01-10 23:15:28.342221883 -0500 Telemetry.ShutdownTime.txt

And the contents...
SecurityPreloadState.txt:
normandy.cdn.mozilla.net:HSTS   0       17542   1547179676657,1,1,2
normandy-cloudfront.cdn.mozilla.net:HPKP        0       17542   1515730076905,1,0,WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18=r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E=YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=sRHdihwgkaib1P1gxX8HFszlD+7/gTfNvuAybgLPNis=
normandy-cloudfront.cdn.mozilla.net:HSTS        0       17542   1547179676904,1,1,2
normandy.cdn.mozilla.net:HPKP   0       17542   1515730076658,1,0,WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18=r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E=YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=sRHdihwgkaib1P1gxX8HFszlD+7/gTfNvuAybgLPNis=

Telemetry.ShutdownTime.txt:
192
(In reply to Pierre Fortin from comment #25)
> Well, I never installed a language pack - ever. I use Mageia 6 as provided
> (English only AFAIK).  Does this help?

Yes. At this point I'm sadly out of ideas, besides maybe searching the entire system for .xpi files.
I installed Mageia 6 from Mageia-6-x86_64-DVD.iso, with Plasma and en-US.

It has several language packs around in /usr/share/mozilla/extensions (en-GB, en-US, en-ZA). 

Do you have them? Can you try removing them and creating a new profile? If it works, it should be duped against bug 1420775.
Downloaded Nightly, creating a new profile gives me exactly the same error as you. 

That's because the language pack is for the version of Firefox shipping in Mageia (52 ESR). That's also why the error is slightly different than bug 1420775 (Fedora ships 57).

Removing those language packs lets me create a new profile.
Flags: needinfo?(pf)
I install from a local mirror rather than DVD.  This gives me only one xpi file in /usr/share/mozilla: langpack-en-US@firefox.mozilla.org.xpi  Removing it resolves the error; BUT...  it doesn't explain why *existing* userids don't fail this way.  I've tried removing ~/.mozilla to return to virgin userid; starting without the extension which works, then leaving the resultant ~/.mozilla -- as long as the xpi is in place, new userids fail; but existing userids work...   something in the latter must prevent FF using /usr/share/mozilla/...

$ ll .mozilla/extensions/\{ec8030f7-c20a-464f-9b0e-13a3a9e97384\}/
total 0
$ ll .mozilla/firefox/iowvrjx2.default-1404854812966/extensions
total 11272
-rw------- 1 pfortin pfortin   30770 Oct  7 03:26 {170503FA-3349-4F17-BC86-001888A5C8E2}.xpi
-rw------- 1 pfortin pfortin  369927 Jan 10 14:04 {73a6fe31-595d-460b-a920-fcc0f8843232}.xpi
-rw------- 1 pfortin pfortin  148820 Sep 29 21:57 {86d73a1c-2ec5-4b7a-b249-60cec805dc99}.xpi
-rw------- 1 pfortin pfortin  387435 Jan  7 13:52 'artur.dubovoy@gmail.com.xpi'
-rw------- 1 pfortin pfortin   35955 Sep 30 02:58 {b9acf540-acba-11e1-8ccb-001fd0e08bd4}.xpi
-rw------- 1 pfortin pfortin   25174 Feb 14  2017 {b9bfaf1c-a63f-47cd-8b9a-29526ced9060}.xpi
-rw------- 1 pfortin pfortin  535491 Dec 14 12:11 {b9db16a4-6edc-47ec-a1f4-b86292ed211d}.xpi
-rw------- 1 pfortin pfortin  557203 Dec 27 13:05 {bee6eb20-01e0-ebd1-da83-080329fb9a3a}.xpi
-rw------- 1 pfortin pfortin 1142053 Nov 16 10:18 {c45c406e-ab73-11d8-be73-000a95be3b12}.xpi
-rw------- 1 pfortin pfortin 1044671 Dec 12 12:03 {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi
-rw------- 1 pfortin pfortin   46506 Apr 27  2016 {e968fc70-8f95-4ab9-9e79-304de2a71ee1}.xpi
-rw------- 1 pfortin pfortin 1637863 Jan 11 14:06 '@emojikeyboard.xpi'
-rw------- 1 pfortin pfortin  170911 Jul 27 17:44 'ffext_basicvideoext@startpage24.xpi'
-rw------- 1 pfortin pfortin 2617076 Feb 28  2017 'firebug@software.joehewitt.com.xpi'
-rw------- 1 pfortin pfortin  695048 Nov 23  2016 'jid0-edalmuivkozlouyij0lpdx548bc@jetpack.xpi'
-rw------- 1 pfortin pfortin  294625 Sep  7  2016 'jid0-o5wF3ZcwkGhi9v4Ky4lAj@jetpack.xpi'
-rw------- 1 pfortin pfortin   15446 Mar  4  2016 'jid1-cplLTTY501TB2Q@jetpack.xpi'
-rw------- 1 pfortin pfortin  937042 Nov 15 10:16 'jid1-NIfFY2CA8fy1tg@jetpack.xpi'
-rw------- 1 pfortin pfortin   26824 Sep 18 02:12 'jid1-qj0w91o64N7Eeg@jetpack.xpi'
-rw------- 1 pfortin pfortin   98284 Feb 14  2016 'jid1-sNL73VCI4UB0Fw@jetpack.xpi'
-rw------- 1 pfortin pfortin   52844 Sep 10  2016 'jsdeobfuscator@adblockplus.org.xpi'
-rw------- 1 pfortin pfortin  150055 Aug 26 19:45 'TabsTree@traxium.xpi'
-rw------- 1 pfortin pfortin   33896 Oct  3  2015 'vwof@drev.com.xpi'
-rw------- 1 pfortin pfortin  238604 Jan 11 14:06 'YoutubeDownloader@PeterOlayev.com.xpi'
-rw------- 1 pfortin pfortin  207242 Apr 27  2016 'yslow@yahoo-inc.com.xpi'

Anyway, sounds like some form of versioning may be needed...
Flags: needinfo?(pf)
(In reply to Pierre Fortin from comment #29)
> I install from a local mirror rather than DVD.  This gives me only one xpi
> file in /usr/share/mozilla: langpack-en-US@firefox.mozilla.org.xpi  Removing
> it resolves the error; BUT...  it doesn't explain why *existing* userids
> don't fail this way.  I've tried removing ~/.mozilla to return to virgin
> userid; starting without the extension which works, then leaving the
> resultant ~/.mozilla -- as long as the xpi is in place, new userids fail;
> but existing userids work...   something in the latter must prevent FF using
> /usr/share/mozilla/...

Existing profile: the language pack has already been correctly disabled (and ignored), since it's not compatible with the new version.

New profile: the add-on is initially loaded even if it's incompatible, and breaks the profile. See bug 1420775 comment 28.

That's exactly the same behavior I see, in both Fedora and Mageia.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.