628841 - Switching Private Browsing autostart checkbox doens't re-enable child checkboxes with instantApply set to false

Status: RESOLVED WORKSFORME

(Firefox :: Private Browsing, defect)

Description

[Adrian Kalla [:adriank]]

Attachment: wrong result

In the L10n Mozmill tests we test the Privacy preferences pane by using controller.select() to switch the items of the menu list. Then, in the custom-subpane, we uncheck "Work always in private mode" and do other stuff.

Now, somewhere between Firefox 4.0b6 and 4.0b9, unchecking "Work always in private mode" on WINDOWS produces wrong results, as many items that are disabled (see wrong results screenshot), shouldn't be disabled (see expected results screenshot).


When trying to manually check&uncheck the "Work always in private mode" pref during the running Mozmill test, it is still not possible to enable the disabled elements. Because of that, and because of the fact, that the same tests work without problems with Fx 3.6 and 4.0b6 as well as they work without any problems on Mac and Linux with 4.0b9+, I suspect that we had some change in Firefox, that breakes something here. I'm not sure, if this is a Firefox regression or something that simply needs to be changed in Mozmill...

Comment 1

[Adrian Kalla [:adriank]]

Attachment: expected results

here the line in the shared module, where we perform the controller.select():
http://hg.mozilla.org/qa/mozmill-tests/file/e6ce2dd0e5d6/shared-modules/dom-utils.js#l370

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Adrian, can you please narrow down the range with available builds? Would be good to know when it has been regressed. Looks like it is not intentional.

Ehsan, are you aware of such a change?

Comment 3

[(no longer active)]

What is the _controller object?  What does _controller.select do exactly?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

The controller is a wrapper around a window in Mozmill which holds a couple of testing methods. You can see the code here:

https://github.com/whimboo/mozmill/blob/hotfix-1.5.2/mozmill/mozmill/extension/resource/modules/controller.js#L770

Comment 5

[Adrian Kalla [:adriank]]

Guess what: this seems to be a JaegerMonkey regression. The last working build is this one: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/09/2010-09-15-07-mozilla-central/firefox-4.0b7pre.en-US.win32.installer.exe (the changeset is: http://hg.mozilla.org/mozilla-central/rev/0caec4ddff74).
The first non-working build is http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/09/2010-09-16-04-mozilla-central/firefox-4.0b7pre.en-US.win32.installer.exe (changeset: http://hg.mozilla.org/mozilla-central/rev/f38ef1080bfe).

Henrik: could you please move the bug to the appropiate section, as this seems to be no more a Mozmill problem (and I don't know which section is appropriate...).

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0caec4ddff74&tochange=f38ef1080bfe

There are way too many checkins here. This does only happen on Windows? Or are you also able to reproduce on OS X?

Comment 7

[Adrian Kalla [:adriank]]

(In reply to comment #6)
> This does only happen on Windows? Or are
> you also able to reproduce on OS X?

I definitely can't reproduce this on OSX. I'm not sure, if this happens on Linux too, but at least I don't remember seeing it there.

Comment 8

[(no longer active)]

Someone needs to bisect the range.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Adrian, could you please create a simple Mozmill test for it? No external shared module should be used. To open the preferences dialog you can use:

https://developer.mozilla.org/en/Mozmill/Mozmill_Base_Object_Interfaces#getPreferencesController%28%29

I can then try to get a build env setup to start bisecting.

Comment 10

[Adrian Kalla [:adriank]]

Attachment: test case (Mozmill test)

It took me a bit longer than anticipated to get a working test case...
It turns out that it is essential to the bug to fire up to have the Main pane "selected" before starting the test (if testing through the IDE). It does not matter what happens between opening the preferences window with the Main pane selected and going to the Privacy pane - if the Main pane was not selected at the beginning, but e.g. the Content pane, then the bug won't happen.

Comment 11

[Adrian Kalla [:adriank]]

heh, now I can reproduce this even without Mozmill:

Prerequistes:
-new Firefox profile
OR
-existing Firefox profile with the "Privacy" preferences pane set to "Remeber" AND the *last* open preferences pane *must* be the "Main" pane!

Steps to reproduce:
1) See Prerequistes
2) Open Firefox 4.0 b7pre from 20100916+ under Windows
3) Open the Firefox Preferences and see the Main pane
4) Switch to the "Privacy" pane
5) Switch from "Remember" to "Don't remember"
6) Switch from "Don't remember" to "Custom"
7) Have fun trying to uncheck the "Work always in private" checkbox

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Thanks for that information Adrian! Now after querying a bit on MXR, I for sure know the causing bug now. It's not related to any Jaegermonkey change, but due to bug 567487.

author	Ehsan Akhgari 
	Wed Sep 15 11:19:02 2010 -0400 (at Wed Sep 15 11:19:02 2010 -0400)
changeset 53929	8e7511b71f59
parent 53928	cfa340639ce6
child 53930	79f4a9df664b
pushlog:	8e7511b71f59
Bug 567487 - Option to never remember history should disable the option to restore the last session; ui-r=limi r,a=gavin

This patch has added the following line to the main pain of the preferences dialog:

http://mxr.mozilla.org/mozilla-central/source/browser/components/preferences/main.xul#82

Request for blocking because this regression stops us from running parts of our l10n Mozmill tests

Comment 13

[(no longer active)]

(In reply to comment #11)
> heh, now I can reproduce this even without Mozmill:
> 
> Prerequistes:
> -new Firefox profile
> OR
> -existing Firefox profile with the "Privacy" preferences pane set to "Remeber"
> AND the *last* open preferences pane *must* be the "Main" pane!
> 
> Steps to reproduce:
> 1) See Prerequistes
> 2) Open Firefox 4.0 b7pre from 20100916+ under Windows
> 3) Open the Firefox Preferences and see the Main pane
> 4) Switch to the "Privacy" pane
> 5) Switch from "Remember" to "Don't remember"
> 6) Switch from "Don't remember" to "Custom"
> 7) Have fun trying to uncheck the "Work always in private" checkbox

I can't reproduce this.  What do you mean by "have fun trying to uncheck"?  Do you mean that the checkbox doesn't get unchecked?

What is the value of the browser.preferences.instantApply pref for you?  Do you see anything in the error console?

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Yeah, browser.preferences.instantApply has to be set to false. In such a case it is even reproducible on OS X now.

Comment 15

[Adrian Kalla [:adriank]]

(In reply to comment #13)
> I can't reproduce this.  What do you mean by "have fun trying to uncheck"?  Do
> you mean that the checkbox doesn't get unchecked?

The checkbox itself does get unchecked, but the child-checkboxes remain disabled.

Comment 16

[(no longer active)]

So it turns out that the onchange event is not dispatched by listening on the actual pref value, so a fix here would be removing the preference element, and triggering the updateBrowserStartupLastSession function from a pref observer.

Henrik, is this something that you may be interested in fixing?  :-)

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

(In reply to comment #16)
> Henrik, is this something that you may be interested in fixing?  :-)

If I would have time, for sure. Always interested in challenging stuff. But my list of work items is exploding this quarter. So sadly I have to say "no". But I would be happy if we could get this fixed for the final release and we can get the remaining l10n testing code for our Mozmill test in the repo.

Comment 18

[(no longer active)]

I can take it *only* if it's deemed to be a blocker (which, IMHO, it's not!)

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

I can't see that it could become a blocker, so I even wouldn't nominate it. Lets see if someone has interest to fix it.

Comment 20

[Mike Beltzner [:beltzner, not reading bugmail]]

Agree with comment 19, not a blocker.

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Adrian, for the time being we could flip the pref to make this test fully working.

Comment 22

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

Whimboo, do you want to mentor this bug? It has been around for some time without being touched, so I'm wondering if we should keep on listing it as "good first".

Comment 23

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

It's not my area of expertise. So no, I will not be a good mentor. Maybe Ehsan or Matthew.

Comment 24

[Josh Matthews [:jdm]]

We fixed this as part of the move to per-window private browsing.