1532701 - The "Always check if Firefox is your default browser" checkbox status can be changed even though it is locked

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect, P3)

Description

[Emil Ghitta, QA [:emilghitta]]

Attachment: DefaultBrowser.gif

Affected versions

• Firefox 66.0b13 (BuildId:20190304101322).
• Firefox 67.0a1 (BuildID:20190305092747).
• Firefox 65.0.2 (BuildId:20190225143501).
• Firefox 60.5.2esr (BuildId:20190221164337).

Affected platforms

• Windows 10 64bit.
• Windows 7 64bit.
• macOS 10.13.
• Ubuntu 16.04 64bit.

Steps to reproduce

1. Launch Firefox.
2. Access the about:preferences page.
3. Click the "Make Default" button. (in order to lock the "Always check if Firefox is your default browser checkbox).
4. Refresh the about:preferences page.
5. Quickly uncheck the "Always check if Firefox is your default browser" checkbox.

Expected result

• Unchecking the "Always check if Firefox is your default browser" checkbox is not possible as long as it is locked.
• The browser.shell.checkDefaultBrowser pref remains set to true and refreshing the about:preferences page doesn't save the actions performed in step 5.

Actual result

• The user is able to check the "Always check if Firefox is your default browser" checkbox if the about:preferences page is refreshed even though it is displayed as locked.
• The browser.shell.CheckDefaultBrowser pref changes to false and the actions performed in step 5 are saved.

Regression range

I will try to get back with a regression range asap.

Additional notes

• For further information regarding this issue, please observe the attached screencast.

Comment 1

[:Gijs (he/him)]

Mike, is this something you could investigate? I'm not sure what's going on here, but it seems to affect 60esr, so we might want to consider our options here if this affects enterprises (not sure if this pref is something they care about, I'd imagine they just restrict actually changing the default?)

Comment 2

[:Gijs (he/him)]

(Going to P3 for now but we can up that if this affects enterprises significantly)

Comment 3

[Mike Kaply [:mkaply]]

I'll take. I know it used to work.

Comment 4

[Mike Kaply [:mkaply]]

1. I thought this was about enterprise locking, but I'm still looking.

2. Why do we disable this box at all when you check it? That seems really counter intuitive.

Comment 5

[Mike Kaply [:mkaply]]

I think this is actually part of a more serious bug.

If you just go to preferences and hit reload a few times, some checkboxes start having the wrong value and this particular checkbox becomes disabled.

When this happens, I see "this.windowElement is null" in DOMLocalization.jsm line 528.

Comment 6

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #5)

I think this is actually part of a more serious bug.

If you just go to preferences and hit reload a few times, some checkboxes start having the wrong value and this particular checkbox becomes disabled.

When this happens, I see "this.windowElement is null" in DOMLocalization.jsm line 528.

Please can you file a separate bug for this with more details, mark it blocking bug 1532735 for now, and needinfo :gandalf?

Comment 7

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello, I've linked bellow the regression results:

Last good revision: e4b9b1084292686d3eb50ba0cadd85950824c955 (2019-01-25)
First bad revision: bb2895bfd1bc3d83c309e904dbe74e0c60c3fac9 (2019-01-26)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e4b9b1084292686d3eb50ba0cadd85950824c955&tochange=bb2895bfd1bc3d83c309e904dbe74e0c60c3fac9

Have to mention that on unaffected builds if you refresh the page several times the greyed checkbox is unchecked but browser.shell.CheckDefaultBrowser pref is not changed and refreshing it again automatically checks the box.

Comment 8

[Mike Kaply [:mkaply]]

Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1539386 opened for the problem I saw (and that Alexandru saw as well).

Looking at the regression range posted, these bugs are there:

9ae7ae0acee4 Zibi Braniecki — Bug 1518252 - Block layout on Fluent. r=smaug
4c5dafe73518 Zibi Braniecki — Bug 1518252 - Make docl10n tests non-racy. r=Pike

Comment 9

[Pascal Chevrel:pascalc]

We have shipped 2 releases with this bug, so it's fix-optional for 67. If a safe patch materializes in the next 2 weeks, we can evaluate an uplift.

Comment 10

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1532701 - Disabled checkboxes should not accept label@control being clicked to toggle their checked state. r?Gijs

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c4bdde9df111
Disabled checkboxes should not accept label@control being clicked to toggle their checked state. r=Gijs

Comment 12

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/c4bdde9df111

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

Let's verify before uplift.
Also, the regression range and bugs mentioned as possible causes don't match up with ESR 60 being affected.
jaws, are you sure ESR is affected?

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

After discussion with mkaply, let's let this ride to release with 68.

Comment 15

[Jared Wein [:jaws] (please needinfo? me)]

Redirecting my needinfo to Emil who had marked ESR 60 as affected.

Comment 16

[Emil Ghitta, QA [:emilghitta]]

I can reconfirm that this issue is reproducible using Firefox 60.6.1esr (BuildId:20190322020346) by spam refreshing the about:preferences page (using the ctrl + r keyboard combination).

Comment 17

[Mike Kaply [:mkaply]]

Spam refreshing the page is actually https://bugzilla.mozilla.org/show_bug.cgi?id=1539386. Do you see an error on the console?

Comment 18

[Emil Ghitta, QA [:emilghitta]]

Indeed, it looks like Bug 1539386:
TypeError: this._callback is null
TypeError: windows is null

I'm unable to reproduce this on latest Nightly.

Comment 19

[Mike Kaply [:mkaply]]

I don't like this on 60, but I think the patches that ended up fixing bug 1539386 are too large to backport.

So I think we'll just have to deal with it.

Comment 20

[Emil Ghitta, QA [:emilghitta]]

Hi Jared,

I can still reproduce this issue using Firefox 68.0a1 (BuildId:20190515092556) on Windows 10 64bit and macOS 10.12.6 by following the steps from comment 0.

Can you please have a look?

Thanks!

Comment 21

[Marcela (Please NI request to Brindusa Tot)]

Hi Jared!
I was able to reproduce this issue using Firefox 69.0a1 (2019-06-26) (BuildID: 20190626215508) on Ubuntu 18.04.2 LTS.

Could you please take a look?

Comment 22

[Mike Kaply [:mkaply]]

I think that the new behavior should get a new bug. And specifically:

When Firefox is the default browser and you load preferences, it take a second for "Always check if Firefox is yout default browser" to become disabled. This allows you to uncheck it before it becomes disabled.

Comment 23

[Daniel Kolsis]

Another bug was logged, Bug 1582740.