Closed
Bug 641288
Opened 14 years ago
Closed 9 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)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: joe, Unassigned)
References
Details
Attachments
(4 files)
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.
Reporter | ||
Comment 1•14 years ago
|
||
Grr. This prefs.js is 2.2 MB, which is too big to attach to Bugzilla. Here it is, gzipped.
Comment 2•14 years ago
|
||
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•14 years ago
|
||
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)
Reporter | ||
Comment 4•14 years ago
|
||
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
Comment 5•14 years ago
|
||
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•14 years ago
|
||
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
Updated•14 years ago
|
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
Reporter | ||
Comment 7•14 years ago
|
||
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.
Reporter | ||
Updated•14 years ago
|
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
Reporter | ||
Comment 8•14 years ago
|
||
(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•14 years ago
|
||
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•14 years ago
|
||
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.
Reporter | ||
Comment 11•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
https://support.mozilla.com/en-US/questions/792427
Got a screenshot. attached.
Comment 14•14 years ago
|
||
Sadly, our extension system is a footgun. Doesn't block.
blocking2.0: ? → -
Comment 15•14 years ago
|
||
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•14 years ago
|
||
I can confirm that setting browser.preferences.instantApply to true fixes the problem.
Comment 17•14 years ago
|
||
(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•14 years ago
|
||
(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•14 years ago
|
||
Disabling BetterPrivacy 1.49 cleared up the issue on my MacBook Pro running 10.6.7.
Comment 20•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
FireGPG was also causing that problem for me - resetting instantApply to false and causing the white square.
Comment 25•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
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•13 years ago
|
||
Screenshot of add-on gui:config's miscellaneous settings, showing the "Instant apply" option and the associated help text.
Comment 31•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
(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•13 years ago
|
||
This seems very related to Bug 679253.
Comment 40•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
so I doubt it
Comment 43•13 years ago
|
||
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)
Comment 44•13 years ago
|
||
(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•13 years ago
|
||
This is the same as Bug 631750.
Comment 46•13 years ago
|
||
(In reply to DRW from comment #42)
> so I doubt it
How about before 50?
Comment 47•13 years ago
|
||
(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)
Updated•13 years ago
|
Keywords: regression,
regressionwindow-wanted
Reporter | ||
Comment 48•13 years ago
|
||
Dao, did you intentionally remove the regressionwindow-wanted? presumably we have builds going back that far!
Comment 49•13 years ago
|
||
(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•12 years ago
|
||
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•12 years ago
|
||
(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.
Reporter | ||
Comment 52•12 years ago
|
||
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
Comment 53•12 years ago
|
||
Joe, can you still reproduce this?
Reporter | ||
Comment 54•12 years ago
|
||
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•12 years ago
|
||
OK, then give us precise and detailed STR (including, if need be, what extension(s) we need to install).
Reporter | ||
Comment 56•12 years ago
|
||
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•12 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
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•9 years ago
|
||
Marking this WFM because Firefox no longer has the option of opening the preferences in a window.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•