Closed Bug 641288 Opened 12 years ago Closed 7 years ago

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

Categories

(Core :: Widget: Cocoa, defect)

Product:
Core
Component:
Widget: Cocoa
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: joe, Unassigned)

References

Details

Attachments

(4 files)

prefs.js gzipped
747.80 KB, application/x-gzip
Details
screenshot from user
64.32 KB, image/jpeg
Details
Screenshot of gui:config settings
60.34 KB, image/png
Details
Shows the unuseable Settings Dialog under MacOS with the standard setting.
58.47 KB, image/jpeg
Details 
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.
Attached file prefs.js gzipped — 
Grr. This prefs.js is 2.2 MB, which is too big to attach to Bugzilla. Here it is, gzipped.
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)
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.
Summary: Preferences doesn't open/opens offscreen without titlebar, leaves white square when closed → Preferences opens offscreen without titlebar, leaves white square when closed, can't be moved
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.
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?
Summary: Preferences opens offscreen without titlebar, leaves white square when closed, can't be moved → Preferences doesn't open/opens offscreen without titlebar, leaves white square when closed
Summary: Preferences doesn't open/opens offscreen without titlebar, leaves white square when closed → Preferences opens offscreen without titlebar, leaves white square when closed, can't be moved
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.
Summary: Preferences opens offscreen without titlebar, leaves white square when closed, can't be moved → Preferences window opens offscreen without titlebar, leaves white square when closed, can't be moved
(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.
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.
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.
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.
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.)
Attached image screenshot from user — 
https://support.mozilla.com/en-US/questions/792427

Got a screenshot. attached.
Sadly, our extension system is a footgun. Doesn't block.
blocking2.0: ? → -
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).
I can confirm that setting browser.preferences.instantApply to true fixes the problem.
(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.
(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
Disabling BetterPrivacy 1.49 cleared up the issue on my MacBook Pro running 10.6.7.
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?
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.
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.
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
FireGPG was also causing that problem for me - resetting instantApply to false and causing the white square.
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.
I filed bug 669188 to flag this in the validator. This is something we already look for, since it's changing defaults unnecessarily.
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
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?
Screenshot of add-on gui:config's miscellaneous settings, showing the "Instant apply" option and the associated help text.
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.
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.
(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
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.
(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.)
(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.
This seems very related to Bug 679253.
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?
(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
so I doubt it
Might be helpful to know when this broke.
Keywords: regression, regressionwindow-wanted
Summary: Preferences window opens offscreen without titlebar, leaves white square when closed, can't be moved → Preferences window opens offscreen without titlebar, leaves white square when closed, can't be moved (with browser.preferences.instantApply=false)
(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.)
This is the same as Bug 631750.
(In reply to DRW from comment #42)
> so I doubt it

How about before 50?
(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)
Dao, did you intentionally remove the regressionwindow-wanted? presumably we have builds going back that far!
(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?
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.
(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.
I suspect this is not a Firefox bug, but is instead a Cocoa widget bug. Certainly it's not getting traction in this component. :)
Component: Preferences → Widget: Cocoa
Product: Firefox → Core
Joe, can you still reproduce this?
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.
OK, then give us precise and detailed STR (including, if need be, what extension(s) we need to install).
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.
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.
Blocks: 727638
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.
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).
Marking this WFM because Firefox no longer has the option of opening the preferences in a window.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.