641288 - Preferences window opens offscreen without titlebar, leaves white square when closed, can't be moved (with browser.preferences.instantApply=false)

Status: RESOLVED WORKSFORME

(Core :: Widget: Cocoa, defect)

Description

[Joe Drew (not getting mail)]

Something in my wife's prefs.js has caused her Preferences window to (sometimes) not open on upgrade from 3.6 -> 4. When it does open, it opens 1/2 offscreen without a titlebar, and when I close it, it leaves a white window permanently on-screen. (This white window is then the parent of the preferences window if you do Firefox > Preferences again.)

I'm attaching her prefs.js here; I believe there's nothing personal in it, and copying it into a fresh profile is all that's necessary to reproduce the problem on OS X.

Speculatively marking blocking2:?, because there are other similar reports (bug 620743, bug 616587, bug 636937) and there is no way for the user to recover this aside from creating a new profile. We should definitely figure out what's causing this bug, and, if it's caused by some strange addon or other setting, minus this. If it's something we did wrong - well, that's another question entirely.

Comment 1

[Joe Drew (not getting mail)]

Attachment: prefs.js gzipped

Grr. This prefs.js is 2.2 MB, which is too big to attach to Bugzilla. Here it is, gzipped.

Comment 2

[Asa Dotzler [:asa]]

I found these reports all saying they see a square of gray or white left behind after closing the preferences window but I didn't see any saying prefs didn't come up at all. 

The reports started coming in on Jan 15, so Beta 9.

http://input.mozilla.com/en-US/beta/opinion/1706797
http://input.mozilla.com/en-US/beta/opinion/1616064
http://input.mozilla.com/en-US/beta/opinion/1578977
http://input.mozilla.com/en-US/beta/opinion/1544321
http://input.mozilla.com/en-US/beta/opinion/1497816
http://input.mozilla.com/en-US/beta/opinion/1486469
http://input.mozilla.com/en-US/beta/opinion/1409344
http://input.mozilla.com/en-US/beta/opinion/1387178
http://input.mozilla.com/en-US/beta/opinion/1372534
http://input.mozilla.com/en-US/beta/opinion/1350519
http://input.mozilla.com/en-US/beta/opinion/1284882
http://input.mozilla.com/en-US/beta/opinion/1234523
http://input.mozilla.com/en-US/beta/opinion/1231979
http://input.mozilla.com/en-US/beta/opinion/1230368
http://input.mozilla.com/en-US/beta/opinion/1219089
http://input.mozilla.com/en-US/beta/opinion/1173066
http://input.mozilla.com/en-US/beta/opinion/1095080
http://input.mozilla.com/en-US/beta/opinion/1056342
http://input.mozilla.com/en-US/beta/opinion/1056263
http://input.mozilla.com/en-US/beta/opinion/1053456

Comment 3

[Asa Dotzler [:asa]]

all of these input.mozilla.com reports sound exactly like bug 636937 that you noted above and I cannot find any other bug reports that mention this problem. I'm wondering if we've got two distinct problems, 1) preferences not coming up sometimes, and 2) the white or gray box being left behind on preference closing sometimes. There certainly appear to be a lot more reports of 2) than 1)

Comment 4

[Joe Drew (not getting mail)]

At one point, preferences didn't come up - that may be a red herring though. The white box is not the only symptom; as I said, the preferences open up in the top-left hand corner of the window, with half the window offscreen, and they can't be moved since a) the window has no window controls and b) even if it did they are offscreen.

Comment 5

[Asa Dotzler [:asa]]

OK, going back considerably further I find reports at input of preferences on Mac not opening http://input.mozilla.com/en-US/beta/search?product=firefox&sentiment=sad&date_end=&date_start=&platform=mac&version=--&q=can%27t+open+preference

Nothing on not being able to move the Preferences window or having a Preferences window offscreen. 

I'm still learning input, so maybe someone more experienced can search it better. We should also check with Support and see if they're seeing anything like this.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

The pref causing this is:
user_pref("browser.preferences.instantApply", false);

That's not the default value on Mac, and we don't ever change this pref in code.

Joe, do you have any idea why that pref might have been changed from its default?

Comment 7

[Joe Drew (not getting mail)]

It looks like there's at least one extension (modplugin, not distributed on AMO as far as I know) that has been setting both browser.preferences.instantApply and browser.preferences.animateFadeIn to false, though current versions seem to restrict itself to extensions.modplugin.instantApply et al.

I'm actually in the middle of writing that plugin's author an email for a different reason, so I'll include a link to this bug to see if he accidentally caused it with past versions.

I'm very interested to know if we have other plugins on AMO that twiddle instantApply.

Comment 8

[Joe Drew (not getting mail)]

(Comment private because it contains the details of an MXR search of AMO, available at https://mxr.mozilla.org/addons/ to security-group people.)

There are a few addons that either expose the pref for instant apply or explicitly set it. Among the plugins that set it to false are:

https://addons.mozilla.org/en-US/firefox/addon/adblock-plus-filter-uploader/
https://addons.mozilla.org/en-us/firefox/addon/classic-compact-options/
https://addons.mozilla.org/en-us/firefox/addon/mozilla-labs-prism/

It hurts me deep in my hurting place, but I feel like this might need to block.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Are you sure those addons actually cause the pref to be set when just run normally? Seems like we would have heard about this before now if so. I don't think we can block on this without more evidence that it's affecting many users.

Comment 10

[Asa Dotzler [:asa]]

I don't think this is the kind of bug to block on. Several not terribly popular extensions make it easy to flip a pref that breaks the Preferences window on Mac. There's a straight-forward workaround that we can relnote and deliver via Support.

Comment 11

[Joe Drew (not getting mail)]

Note to self: comment private status does not persist through midair collisions.

I don't know if those addons cause the pref to be set when just run normally, no. Some of them definitely contain code that looks like it would, though.

user_pref("browser.preferences.instantApply", false) for example.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

That looks like an entry from a default pref file, which may or may not have an effect depending on how it's packaged in the extension.

(I unhid comment 8 intentionally - there's nothing secret there. The auth on the addons AMO search is just there for hysterical raisins.)

Comment 13

[[:Cww]]

Attachment: screenshot from user

https://support.mozilla.com/en-US/questions/792427

Got a screenshot. attached.

Comment 14

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

Sadly, our extension system is a footgun. Doesn't block.

Comment 15

[David Gasperoni]

I can add that the whenever opening the pref window, the window itself gets vacuumed out from the white block, and the gets vacuumed in again in the white block.

The only exception is for the first time that the pref window opens, but it does appear off screen and without window chrome (the close, minimize, zoom buttons).

Comment 16

[Panos Astithas (he/him) [:past] (please ni?)]

I can confirm that setting browser.preferences.instantApply to true fixes the problem.

Comment 17

[kureta]

(In reply to comment #16)
> I can confirm that setting browser.preferences.instantApply to true fixes the
> problem.

It fixed the problem for me too.

Comment 18

[David Gasperoni]

(In reply to comment #16)
> I can confirm that setting browser.preferences.instantApply to true fixes the
> problem.

confirmed. it is to find which extension causes it

Comment 19

[CharlieG]

Disabling BetterPrivacy 1.49 cleared up the issue on my MacBook Pro running 10.6.7.

Comment 20

[Justin Scott [:fligtar]]

This was happening on my Mom's computer as well, and changing the pref fixed it.

Do we need to outreach to add-ons here or add it to the AMO validator? Is there a legitimate reason to change this pref?

Comment 21

[:Gavin Sharp [email: [e-mail]]]

I don't know of any legitimate reasons. Add-ons can override the default behavior for their own prefpanes using the instantApply attribute on individual <preference> or <prefpane> elements, so there should be no need to change the global pref.

Comment 22

[rhand_mbugs]

I have the same issue on Firefox 4.0.1 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1) . Screenshot attached by bug reporter is what I see as soon as I have closed preferences. Only by restarting Firefox can I remove it. It is really annoying as it blocks the view. Without restarting FF I am forced to move my browser windows to see things properly and not be bothered by this grey block in the top left corner. When I set browser.preferences.instantApply to true and restarted and opened and closed preferences the grey block did not appear again.

Comment 23

[Spyro Polymiadis]

howdy all...

i also have this problem.. and i have changed the instantapply option to true, and the problem remained... i have been able to track down the problem causing this - it seems like the problem lies with FireGPG addon (in my case). This addon seems to override the instantapply option - and cause the pref window to show OK/Cancel - and causes the top left square to appear when closed regardless of the config setting. 

HTH
Spyro

Comment 24

[muppetry]

FireGPG was also causing that problem for me - resetting instantApply to false and causing the white square.

Comment 25

[Justin Scott [:fligtar]]

Jorge, can you please file the relevant validator bugs to get this into our AMO checks if you agree with the earlier comments. We should also look for existing add-ons that use this and do outreach.

Comment 26

[Jorge Villalobos [:jorgev] (he/him)]

I filed bug 669188 to flag this in the validator. This is something we already look for, since it's changing defaults unnecessarily.

Comment 28

[Joel Coreson]

Toggle Proxy 1.4 was the culprit for me. https://addons.mozilla.org/en-US/firefox/addon/toggle-proxy-51740/

FF 5.0.1 on OS X 10.6.8

Comment 29

[zakwilcox+mozillabugzilla]

Bit me on 6.0.2; not sure what add-on, but...

While it seems sensible to explicitly deprecate the practice of globally setting the preference (using the validator), it's worth keeping in mind that it's the preference that's ultimately broken in Firefox-on-Mac itself because it's the implementation of "false" that causes this white box, not the add-ons.

I've not used non-Mac Firefox but if the preference is not used there either, is poorly supported (this bug is getting dusty) and if the fix isn't simple, perhaps dropping the preference altogether should be considered?

Comment 30

[Paul]

Attachment: Screenshot of gui:config settings

Screenshot of add-on gui:config's miscellaneous settings, showing the "Instant apply" option and the associated help text.

Comment 31

[Pete Cahan]

This bug seems to be the same as the new bug listed as bug 631750.

In my experience, setting the instantApply false is used to get the OK and Cancel buttons, which are not normally available in Firefox-on-Mac.

Comment 34

[Florian Leitner]

I, too, can confirm that setting the (changed) config browser.preferences.instantApply back to true fixed the problem for me on OSX 10.7.3 and FF 11.0. Re-enabling all my extension (I had disabled them before looking over here), however, was not able to reproduce the problem, so whatever extension changed the setting seems to have been fixed.

Comment 35

[Atlanx]

(In reply to Pete Cahan from comment #31) 
> In my experience, setting the instantApply false is used to get the OK and
> Cancel buttons, which are not normally available in Firefox-on-Mac.

Yes, thats exactly why i changed the setting to false.

Because the setting-window of the AVM Fritz!Box Firefox-Add-on*) 
has no (ok)-Button to save the settings under Mac-OS when 
browser.preferences.instantApply == true

*) http://www.avm.de/de/Service/FRITZ_Tools/browser_plugin.html

Comment 36

[Atlanx]

Attachment: Shows the unuseable Settings Dialog under MacOS with the standard setting.

Shows the unuseable Settings Dialog of the Fritz!Box Firefox-Add-on under MacOS with the standard setting and the useable Setting Dialog with the non-standard setting browser.preferences.instantApply=true which produces the grey box bug.

Comment 37

[Pete Cahan]

(In reply to Atlanx from comment #35)
> (In reply to Pete Cahan from comment #31) 
> > In my experience, setting the instantApply false is used to get the OK and
> > Cancel buttons, which are not normally available in Firefox-on-Mac.
> 
> Yes, thats exactly why i changed the setting to false.
> 
> Because the setting-window of the AVM Fritz!Box Firefox-Add-on*) 
> has no (ok)-Button to save the settings under Mac-OS when 
> browser.preferences.instantApply == true
> 
> *) http://www.avm.de/de/Service/FRITZ_Tools/browser_plugin.html

It is also the reason that the install instructions for modplugin for Mac users tell the user to set browser.preferences.instantApply to false. Anyone working on this can contact Ed Hibbert for details. (I can provide direct email address, if needed.)

Comment 38

[Pete Cahan]

(In reply to Atlanx from comment #36)
> Created attachment 610495 [details]
> Shows the unuseable Settings Dialog under MacOS with the standard setting.
> 
> Shows the unuseable Settings Dialog of the Fritz!Box Firefox-Add-on under
> MacOS with the standard setting and the useable Setting Dialog with the
> non-standard setting browser.preferences.instantApply=true which produces
> the grey box bug.

This is ezactly what happens with modplugin, as well.

Comment 39

[Pete Cahan]

This seems very related to Bug 679253.

Comment 40

[Pete Cahan]

Still a problem under Firefox 13.0

Has been a problem at least since Firefox 4.

Is there any way to increase the priority on this so it get fixed before version 20 comes out?

Comment 41

[DRW]

(In reply to Pete Cahan from comment #40)
> Still a problem under Firefox 13.0
> 
> Has been a problem at least since Firefox 4.
> 
> Is there any way to increase the priority on this so it get fixed before
> version 20 comes out?

still exists in 17.0a1 (2012-07-22

Comment 42

[DRW]

so I doubt it

Comment 43

[Dão Gottwald [:dao]]

Might be helpful to know when this broke.

Comment 44

[Pete Cahan]

(In reply to Dão Gottwald [:dao] from comment #43)
> Might be helpful to know when this broke.

There were reports back to 4.0b12, maybe before. See Bug 637162.
I only started with Firefox-on-Mac 10.


Also, it seems to only apply to Firefox-on-Mac with browser.preferences.instantApply=false. (This MUST be set false to get OK and CANCEL buttons on Mac.)

Comment 45

[Pete Cahan]

This is the same as Bug 631750.

Comment 46

[Pete Cahan]

(In reply to DRW from comment #42)
> so I doubt it

How about before 50?

Comment 47

[Florian Leitner]

(In reply to Pete Cahan from comment #44)
> (In reply to Dão Gottwald [:dao] from comment #43)
> > Might be helpful to know when this broke.
> 
> There were reports back to 4.0b12, maybe before. See Bug 637162.
> I only started with Firefox-on-Mac 10.
> 
> 
> Also, it seems to only apply to Firefox-on-Mac with
> browser.preferences.instantApply=false. (This MUST be set false to get OK
> and CANCEL buttons on Mac.)

fwiw: as I did not update my Firefox for quite some while on one machine, I can report that this bug was already present as far back as the 3.x series (i.e., <=3.6)

Comment 48

[Joe Drew (not getting mail)]

Dao, did you intentionally remove the regressionwindow-wanted? presumably we have builds going back that far!

Comment 49

[Dão Gottwald [:dao]]

(In reply to Joe Drew (:JOEDREW!) from comment #48)
> Dao, did you intentionally remove the regressionwindow-wanted? presumably we
> have builds going back that far!

There doesn't seem to be a reason to believe that this is a regression at all. Has anyone ever seen this work correctly?

Comment 50

[Malbone]

This bug was present when running TenFourFox 10.0.9 on a PPC Mac G4.  All of the reported behaviors occurred -- unable to select preference panes; the only way to dismiss the Preferences window was to use the Esc key, which left the blank square covering the back-forward arrows and the leftmost tab.  By deleting and adding back extensions, I was able to isolate the extension that was causing it on my Mac -- TRUSTe Privacy Plugin 2.0.  (This is not the same as TRUSTe Tracker Protection Beta 1.1.2c)  Disabling that extension got rid of the problem.

Comment 51

[Pete Cahan]

(In reply to Malbone from comment #50)
> This bug was present when running TenFourFox 10.0.9 on a PPC Mac G4.  All of
> the reported behaviors occurred -- unable to select preference panes; the
> only way to dismiss the Preferences window was to use the Esc key, which
> left the blank square covering the back-forward arrows and the leftmost tab.
> By deleting and adding back extensions, I was able to isolate the extension
> that was causing it on my Mac -- TRUSTe Privacy Plugin 2.0.  (This is not
> the same as TRUSTe Tracker Protection Beta 1.1.2c)  Disabling that extension
> got rid of the problem.

I have found that even running no extensions didn't clear the problem when browser.preferences.instantApply=false.
If browser.preferences.instantApply=true (which is the default for Macs), I have not found any extension that causes the problem, but there is no Cancel or OK button.

Comment 52

[Joe Drew (not getting mail)]

I suspect this is not a Firefox bug, but is instead a Cocoa widget bug. Certainly it's not getting traction in this component. :)

Comment 53

[Steven Michaud [:smichaud] (Retired)]

Joe, can you still reproduce this?

Comment 54

[Joe Drew (not getting mail)]

Yep. And my wife always has to deal with this because an addon she uses for her volunteer work (the Freecycle modplugin) requires user_pref("browser.preferences.instantApply", false), which causes this bug.

Comment 55

[Steven Michaud [:smichaud] (Retired)]

OK, then give us precise and detailed STR (including, if need be, what extension(s) we need to install).

Comment 56

[Joe Drew (not getting mail)]

1. New profile.
2. About:config -> search for instantapply -> Toggle browser.preferences.instantApply to false.
3. Restart Firefox for good measure.
4. Firefox > Preferences.
5. Note that the preferences window has no titlebar.
6. Press cancel.
7. Grey square left on the screen.

Comment 57

[Pete Cahan]

Just to summarize a couple of things:
1. No extensions are needed to reproduce.
2. It occurs on Macs when instantapply is false. It has not been reported in other OS or if instantapply is true.
3. Macs need the ability to run with instantapply set false because otherwise there are no OK or Cancel buttons.
4. This bug is duplicated by bug 631750 and bug 679253.

Comment 60

[Stefan [:stefanh]]

So, the prefwindow is opened by the openPreferences function in utilityOverlay.js. If you have set instantapply to false, the openDialog features are changed:
-------------------------------------------------------------
    var features = "chrome,titlebar,toolbar,centerscreen" + (instantApply ? ",dialog=no" : ",modal");
-------------------------------------------------------------

So with the pref set to false, features = "chrome,titlebar,toolbar,centerscreen,modal". That should be enough to open the window as a sheet - but for some reason it isn't.

Comment 61

[Stefan [:stefanh]]

OK, so the reason it won't open as a sheet (meaning attached to the browser window) is because the parent in this case is the hidden window( the preferences menuitem in the application menu is created by nsMenuBarX.mm).

Comment 62

[:Gijs (he/him)]

Marking this WFM because Firefox no longer has the option of opening the preferences in a window.