1584092 - "General" tab is not shown when MOZ_UPDATER is not defined

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect, P1)

Description

[[e-mail]]

Attachment: "General" first enter.

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

I have Nightly 71.0a1 (2019-09-25) (64-bit) on Ubuntu 18.04.

"Menu > Preferences"

Actual results:

"General" opens with empty contents.
All others are OK.

Expected results:

"General" with normal contents, like "Startup", "Language", "Downloads" etc.

Comment 1

[[e-mail]]

Attachment: "General" after visiting "Home"

Click "Home" then "General" again.
Actually it happens with any other sections: when you are back to "General" you see previous contents and don't see "General" contents.

Comment 2

[Francesco Lodolo [:flod]]

If you open the browser console (Tools->Developer Tools->Browser Console), clear the content, then try to open the preferences, do you see any error reported when it shows up empty?

Comment 3

[[e-mail]]

(In reply to Francesco Lodolo [:flod] from comment #2)

If you open the browser console (Tools->Developer Tools->Browser Console), clear the content, then try to open the preferences, do you see any error reported when it shows up empty?

No, none. Just empty Console.

Comment 4

[:Gijs (he/him)]

Can you use mozregression ( https://mozilla.github.io/mozregression/ ) to find out when this broke?

Comment 5

[[e-mail]]

Yes, I did.

mozregression said this:

mozregression --good 2019-09-09 --bad 2019-09-26
 0:02.56 INFO: Testing good and bad builds to ensure that they are really good and bad...
 0:02.56 INFO: Using local file: /home/dayfuaim/.mozilla/mozregression/persist/2019-09-09--mozilla-central--firefox-71.0a1.en-US.linux-x86_64.tar.bz2
 0:02.56 INFO: Running mozilla-central build for 2019-09-09
 0:11.09 INFO: Launching /tmp/tmpvPt6GU/firefox/firefox
 0:11.09 INFO: Application command: /tmp/tmpvPt6GU/firefox/firefox --allow-downgrade -profile /tmp/tmpdAJUT8.mozrunner
 0:11.10 INFO: application_buildid: 20190909214621
 0:11.10 INFO: application_changeset: bdb64cf16b68c4a7212ba16aef425bce66d8f4ca
 0:11.10 INFO: application_name: Firefox
 0:11.10 INFO: application_repository: https://hg.mozilla.org/mozilla-central
 0:11.10 INFO: application_version: 71.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good
 0:41.44 INFO: Using local file: /home/dayfuaim/.mozilla/mozregression/persist/2019-09-26--mozilla-central--firefox-71.0a1.en-US.linux-x86_64.tar.bz2 (downloaded in background)
 0:41.44 INFO: Running mozilla-central build for 2019-09-26
 0:50.45 INFO: Launching /tmp/tmp6JEhsx/firefox/firefox
 0:50.45 INFO: Application command: /tmp/tmp6JEhsx/firefox/firefox --allow-downgrade -profile /tmp/tmpoSFauh.mozrunner
 0:50.46 INFO: application_buildid: 20190926213542
 0:50.46 INFO: application_changeset: 1d189ae70326e415f8590e3aeee24885fb8418bc
 0:50.46 INFO: application_name: Firefox
 0:50.46 INFO: application_repository: https://hg.mozilla.org/mozilla-central
 0:50.46 INFO: application_version: 71.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good
 1:10.48 ERROR: Build was expected to be bad! The initial good/bad range seems incorrect.

Apparently "clean" Nightly (from Mozilla Central) is good.
But I have Ubuntu-biuld (if I can say that, see screen). It is bad.

Comment 6

[[e-mail]]

Attachment: Ubuntu Nightly "About" screenshot

Comment 7

[:Gijs (he/him)]

If you try your ubuntu nightly build with a clean profile ( https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles ) do you see the same problem?

Comment 8

[[e-mail]]

Yes.
And also I have tried complete reinstall (remove, clean, install).
The same issue.

So, I left trying to make it work (I have my job to do) and installed non-Ubuntu build from https://download.mozilla.org/?product=firefox-nightly-latest-l10n-ssl&os=linux64&lang=ru.

I'm about to close this bug for now.

Comment 9

[:Gijs (he/him)]

Mike, any ideas what might be up here, or who admins the Ubuntu PPA or why it'd be broken? (I suspect the crash reporter or telemetry-related changes, but I have no idea how to find out off-hand)

Comment 10

[Andreas Matre]

I also experience this bug, it happens reliably with a clean profile.
Build ID = 20191007073613
User Agent = Mozilla/5.0 (X11; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0
I'm running Arch Linux.

However I also get one line of output from the Browser Console when it happens: TypeError: document.getElementById(...) is null 2 main.js:293:10

Otherwise I experience the same thing as [e-mail] where it works fine in the builds I get from mozregression.

Comment 11

[:Gijs (he/him)]

(In reply to Andreas Matre from comment #10)

I also experience this bug, it happens reliably with a clean profile.
Build ID = 20191007073613
User Agent = Mozilla/5.0 (X11; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0
I'm running Arch Linux.

However I also get one line of output from the Browser Console when it happens: TypeError: document.getElementById(...) is null 2 main.js:293:10

Is there an arrow to get a stack for these errors? This address (ie line 293 of main.js) unfortunately is in a utility function so it doesn't really narrow down what the issue is...

Comment 12

[Ian Moody [:Kwan] (UTC+0)]

Whoops, look at all these unconditional references
https://searchfox.org/mozilla-central/rev/5cb522c7baba24e55874809e0e206b001494c1e9/browser/components/preferences/in-content/main.js#420,423,426,429,432
to elements that are compiled out with ac_add_options --disable-updater
https://searchfox.org/mozilla-central/rev/5cb522c7baba24e55874809e0e206b001494c1e9/browser/components/preferences/in-content/main.inc.xul#438,443,449,455,480,495,534

(installed nightly in a VM and while there didn't seem to be a stack, setting a breakpoint in setEventListener showed "checkForUpdatesButton" is the first value of aId that doesn't return anything from getElementById())

Comment 13

[Ian Moody [:Kwan] (UTC+0)]

Attachment: Bug 1584092 - Don't add listeners to non-existent buttons in preferences. r=Gijs

Since when the updater isn't enabled the buttons aren't included, so the
getElementById() call fails and breaks the main preferences page.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/18f7137336ca
Don't add listeners to non-existent buttons in preferences. r=Gijs

Comment 15

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/18f7137336ca

Comment 18

[Alin Ilea, Desktop Test Engineering]

Hi,

I didn't manage to reproduce the issue following the steps provided in the description on all OS platforms using Fx 71.0a1 (2019-09-25). Can you please verify that the issue is fixed in the latest Beta build and report back the results? You can download the build from the following link:
http://archive.mozilla.org/pub/devedition/candidates/71.0b11-candidates/build1/

Thanks in advance.

Comment 19

[:Gijs (he/him)]

(In reply to Alin Ilea from comment #18)

Hi,

I didn't manage to reproduce the issue following the steps provided in the description on all OS platforms using Fx 71.0a1 (2019-09-25). Can you please verify that the issue is fixed in the latest Beta build and report back the results? You can download the build from the following link:
http://archive.mozilla.org/pub/devedition/candidates/71.0b11-candidates/build1/

Thanks in advance.

No, this won't work - the official beta/devedition builds never had this problem. To check if it's fixed, you'd need to use an ubuntu ppa build (https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa, see specifically "add this ppa to your system" section)

Comment 20

[Alin Ilea, Desktop Test Engineering]

Hi,

I was not able to reproduce this issue in order to verify the fix, but since it is in release from 71 and no other bugs were reported on this, I will remove the qe-verify+.