Last Comment Bug 641288 - Preferences window opens offscreen without titlebar, leaves white square when closed, can't be moved (with browser.preferences.instantApply=false)
: Preferences window opens offscreen without titlebar, leaves white square when...
Status: RESOLVED WORKSFORME
:
Product: Core
Classification: Components
Component: Widget: Cocoa (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal with 7 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 631750 636937 707890 733254 877801 (view as bug list)
Depends on:
Blocks: 727638
  Show dependency treegraph
 
Reported: 2011-03-12 20:51 PST by Joe Drew (not getting mail)
Modified: 2016-02-04 05:45 PST (History)
31 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
prefs.js gzipped (747.80 KB, application/x-gzip)
2011-03-12 20:52 PST, Joe Drew (not getting mail)
no flags Details
screenshot from user (64.32 KB, image/jpeg)
2011-03-13 23:12 PDT, [:Cww]
no flags Details
Screenshot of gui:config settings (60.34 KB, image/png)
2011-11-09 19:29 PST, Paul
no flags Details
Shows the unuseable Settings Dialog under MacOS with the standard setting. (58.47 KB, image/jpeg)
2012-03-29 02:40 PDT, Atlanx
no flags Details

Description Joe Drew (not getting mail) 2011-03-12 20:51:10 PST
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) 2011-03-12 20:52:41 PST
Created attachment 518995 [details]
prefs.js gzipped

Grr. This prefs.js is 2.2 MB, which is too big to attach to Bugzilla. Here it is, gzipped.
Comment 3 Asa Dotzler [:asa] 2011-03-12 21:34:16 PST
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) 2011-03-12 21:39:26 PST
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] 2011-03-12 21:44:08 PST
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: gavin@gavinsharp.com] 2011-03-12 21:46:49 PST
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) 2011-03-12 22:17:15 PST
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) 2011-03-12 22:57:28 PST
(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: gavin@gavinsharp.com] 2011-03-12 23:06:53 PST
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] 2011-03-12 23:08:46 PST
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) 2011-03-12 23:32:24 PST
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: gavin@gavinsharp.com] 2011-03-13 00:19:38 PST
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] 2011-03-13 23:12:36 PDT
Created attachment 519082 [details]
screenshot from user

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

Got a screenshot. attached.
Comment 14 Mike Beltzner [:beltzner, not reading bugmail] 2011-03-14 11:53:12 PDT
Sadly, our extension system is a footgun. Doesn't block.
Comment 15 David Gasperoni 2011-04-04 08:09:28 PDT
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 [:past] 2011-04-10 02:48:18 PDT
I can confirm that setting browser.preferences.instantApply to true fixes the problem.
Comment 17 kureta 2011-04-10 02:53:45 PDT
(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 2011-04-11 01:40:59 PDT
(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 2011-04-11 09:41:21 PDT
Disabling BetterPrivacy 1.49 cleared up the issue on my MacBook Pro running 10.6.7.
Comment 20 Justin Scott [:fligtar] 2011-04-25 08:07:31 PDT
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: gavin@gavinsharp.com] 2011-04-25 14:56:06 PDT
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 2011-05-05 00:25:52 PDT
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 2011-05-13 17:03:03 PDT
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 2011-05-14 16:50:19 PDT
FireGPG was also causing that problem for me - resetting instantApply to false and causing the white square.
Comment 25 Justin Scott [:fligtar] 2011-07-01 16:59:28 PDT
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] 2011-07-04 10:10:38 PDT
I filed bug 669188 to flag this in the validator. This is something we already look for, since it's changing defaults unnecessarily.
Comment 27 mcdavis941 (sporadically reading bugmail) 2011-07-08 21:29:57 PDT
*** Bug 636937 has been marked as a duplicate of this bug. ***
Comment 28 Joel Coreson 2011-08-25 10:18:53 PDT
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 2011-10-20 14:00:59 PDT
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 2011-11-09 19:29:38 PST
Created attachment 573411 [details]
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 2012-02-01 00:56:26 PST
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 32 Matthias Versen [:Matti] 2012-03-06 14:15:14 PST
*** Bug 707890 has been marked as a duplicate of this bug. ***
Comment 33 Matthias Versen [:Matti] 2012-03-06 14:15:29 PST
*** Bug 733254 has been marked as a duplicate of this bug. ***
Comment 34 Florian Leitner 2012-03-29 01:38:30 PDT
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 2012-03-29 02:29:11 PDT
(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 2012-03-29 02:40:57 PDT
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.
Comment 37 Pete Cahan 2012-03-29 02:58:32 PDT
(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 2012-03-29 02:59:32 PDT
(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 2012-06-04 12:29:03 PDT
This seems very related to Bug 679253.
Comment 40 Pete Cahan 2012-06-08 20:49:50 PDT
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 2012-07-30 22:18:08 PDT
(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 2012-07-30 22:18:41 PDT
so I doubt it
Comment 43 Dão Gottwald [:dao] 2012-07-31 00:52:24 PDT
Might be helpful to know when this broke.
Comment 44 Pete Cahan 2012-07-31 12:13:26 PDT
(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 2012-07-31 12:18:47 PDT
This is the same as Bug 631750.
Comment 46 Pete Cahan 2012-07-31 12:19:59 PDT
(In reply to DRW from comment #42)
> so I doubt it

How about before 50?
Comment 47 Florian Leitner 2012-07-31 13:16:15 PDT
(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) 2012-08-01 08:07:15 PDT
Dao, did you intentionally remove the regressionwindow-wanted? presumably we have builds going back that far!
Comment 49 Dão Gottwald [:dao] 2012-08-10 09:02:19 PDT
(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 2012-10-24 21:59:39 PDT
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 2012-10-24 22:17:24 PDT
(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) 2012-12-12 09:08:29 PST
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) 2012-12-12 10:01:38 PST
Joe, can you still reproduce this?
Comment 54 Joe Drew (not getting mail) 2012-12-12 11:25:23 PST
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) 2012-12-12 11:30:38 PST
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) 2012-12-12 11:39:10 PST
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 2012-12-12 13:17:15 PST
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 58 Joe Drew (not getting mail) 2013-01-02 10:27:12 PST
*** Bug 631750 has been marked as a duplicate of this bug. ***
Comment 59 [:Aleksej] 2013-06-04 06:25:48 PDT
*** Bug 877801 has been marked as a duplicate of this bug. ***
Comment 60 Stefan [:stefanh] (away until May 28) 2014-01-06 10:22:58 PST
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] (away until May 28) 2014-01-12 10:54:02 PST
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 Kruitbosch 2016-02-04 05:45:29 PST
Marking this WFM because Firefox no longer has the option of opening the preferences in a window.

Note You need to log in before you can comment on or make changes to this bug.