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.

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?)

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

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

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.

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.

(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?

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.

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

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.

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

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?

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

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

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).

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

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

I'm unable to reproduce this on latest Nightly.

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.

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!

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?

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.

Another bug was logged, Bug 1582740.