I thought I might try this button that I saw in about:support today for the first time. "Tune up" to me sounds like it would run the garbage collector, clear caches, restart to clear up possible memory fragmentation, that kind of thing. After pressing that button, a dialog appeared, with just two buttons in it (see screenshot), which just asked me again, if I wanted to refresh firefox, so I pressed it. I was surprised a _lot_ when it created a completely new profile, removed all my extensions, and gave me no indication of where the old profile might have been backed-up to -- indeed I haven't found it anywhere (good that I myself had backed up my home directory not long before). Now that FF restarted with this new profile (that I didn't want), pressing that button indeed puts up a confirmation dialog which contains some explanation. This from an old-time user (and ex-developer) who is now pretty angry that he has to spend his time to file this bug...

Wow, that's terrible. Yes, the dialog should be more descriptive. But in my case, it is: http://imgur.com/OihuGwk On your new profile, if you go look at this dialog, it still looks this empty? Are there any errors in the browser console?

(In reply to :Gijs Kruitbosch from comment #1) > Wow, that's terrible. > > Yes, the dialog should be more descriptive. But in my case, it is: > > http://imgur.com/OihuGwk > > On your new profile, if you go look at this dialog, it still looks this > empty? Are there any errors in the browser console? Obviously, I meant, on your new (restored) old profile ...

In the restored profile, the dialog is shown again as in attachment 8556988 [details]. (The new "tuned" profile had shown the dialog that is visible in your screenshot.)Error: WebGL: I don't get any error messages in the console when clicking the button. Loading about:support gives me Refused to create native OpenGL context because of blacklisting. Troubleshoot.jsm:380 Error: WebGL: WebGL creation failed. Troubleshoot.jsm:380 but that's not something that I would associate with this bug. Anyway, when I click on a button called "Refresh Firefox" under a title "... tune up" I would not expect either of these the two operations mentioned there, since tuning is when I customize something to _my_ requirements, i.e. install add-ons and customize settings. "De-tune" would be a much better description... By the way, in the meantime I found that indeed FF had backed-up my profile as well when "refreshing", into $HOME/Desktop/. Because I don't run a desktop environment on this machine, I only noticed when my private backup script verbosely removed the Desktop directory and its contents.

(In reply to Peter Weilbacher from comment #3) > In the restored profile, the dialog is shown again as in attachment 8556988 [details] > [details]. > (The new "tuned" profile had shown the dialog that is visible in your > screenshot.)Error: WebGL: > > I don't get any error messages in the console when clicking the button. > Loading about:support gives me > > Refused to create native OpenGL context because of blacklisting. > Troubleshoot.jsm:380 > Error: WebGL: WebGL creation failed. Troubleshoot.jsm:380 > > but that's not something that I would associate with this bug. > > Anyway, when I click on a button called "Refresh Firefox" under a title "... > tune up" I would not expect either of these the two operations mentioned > there, since tuning is when I customize something to _my_ requirements, i.e. > install add-ons and customize settings. "De-tune" would be a much better > description... > > By the way, in the meantime I found that indeed FF had backed-up my profile > as well when "refreshing", into $HOME/Desktop/. Because I don't run a > desktop environment on this machine, I only noticed when my private backup > script verbosely removed the Desktop directory and its contents. I'm confused how you can have visual dialogs with no desktop environment. What window manager are you running, and does this reproduce with other window managers? I mean, the main concern here is the dialog not warning you appropriately. Keep in mind "cancel" is still the default action here (I take no responsibility for how your WM indicates that default button, but on Windows and OS X it's pretty obvious that if you don't know, that's the button you should be pressing). The backups are expected, and you're in a tiiiiiiiiny minority who doesn't have a desktop and therefore don't notice the backup being made, so I don't think we will change that. The wording is encouraging people to do this because for most users, the things they lose are negligible, and it fixes a lot (think 90%) of the issues people have with Firefox. It used to be called "Firefox reset" but users thought it too scary (thinking they'd lose history, bookmarks, passwords, homepage, etc.) and so it was changed to be more friendly. Considering the backups and the more informative warning people generally get, I don't think this is as terrible as comment #0 suggested. All that said, we should really fix the warning dialog to actually display a message on whatever WM you're using. :-\

Desktop environment != Window manager. I can reproduce this problem with profiles on at least two machines, one running openSUSE and fluxbox as window manager and Mozilla's Firefox, one running XUbuntu and XFCE4 (with xfwm and Ubuntu's Firefox). And I doubt that the window manager has anything to do with it, since I can resize the window to any size, but the text that should be there does not appear -- the dialog stays empty except for the two buttons.

(In reply to Peter Weilbacher from comment #5) > Desktop environment != Window manager. > > I can reproduce this problem with profiles on at least two machines, one > running openSUSE and fluxbox as window manager and Mozilla's Firefox, one > running XUbuntu and XFCE4 (with xfwm and Ubuntu's Firefox). > > And I doubt that the window manager has anything to do with it, since I can > resize the window to any size, but the text that should be there does not > appear -- the dialog stays empty except for the two buttons. But the dialog is not empty in a clean profile? Is the dialog empty if you open it from safe mode?

This bug is wandering into the weeds a bit. 1) This feature is heavily used and promoted by support as a simple way to fix a plethora of problems for general users. It's not really targeted at advanced users such as yourself, and has been extremely well-received for the years it's been in use. 2) It's clearly a problem that this dialog is showing up empty, as shown in attachment 8556988 [details]. If that's a bug in our code we should definitely fix it. Matt, have you heard of anything like this before? Anything else to look at?

I haven't seen reports of this before. It's possible there is a JS error populating the dialog but it's pretty static[1] with string entities inline and no onload code. It sounds like Peter didn't see anything in the Browser Console (Ctrl-Shift-J) when he clicked on the button in about:support so I'm left wondering if this is a XUL layout bug. Peter, if you load chrome://global/content/resetProfile.xul in a new tab, do you see the additional text? If you can setup a build environment you could try making the dialog resizable[2] (if it's not already) and/or add a window.sizeToContent(); call onload. [1] https://mxr.mozilla.org/mozilla-central/source/toolkit/content/resetProfile.xul [2] https://mxr.mozilla.org/mozilla-central/source/toolkit/modules/ResetProfile.jsm?rev=70488f55e30d#71

Interesting, on one system clearly the Ghostery extension is responsible. Even though the ghost is greyed out on about:support if Ghostery is enabled as an add-on, the text in the dialog does not show (even though I can see it in chrome://global/content/resetProfile.xul without problems). If I disable Ghostery as add-on, the ghost is of course not shown at all, and the text appears after I click "Refresh Firefox...". On another machine, -safe-mode caused that "Refresh Firefox..." button to disappear altogether. But that's the Ubuntu version of FF 35.0.1, so maybe it's the wrong place to discuss this. Installing Ghostery into a new profile seems to sometimes cause this bug. I guess I should take this problem as bug-report to the Ghostery forum?

(In reply to Peter Weilbacher from comment #9) > On another machine, -safe-mode caused that "Refresh Firefox..." button to > disappear altogether. But that's the Ubuntu version of FF 35.0.1, so maybe > it's the wrong place to discuss this. The button only shows up if the profile you're running is the 'default' profile (see profiles.ini). And yes, it sounds like this is worth bringing up with the ghostery people, although I'm not sure what makes you say it "sometimes" causes this bug if you install it in a new profile... either way, that might be something to figure out with the ghostery folks?

The Ghostery forum pointed me to bug 1128127, and indeed I see that, too, in the affected profiles. The History -> Clear Recent History... dialog also shows up empty. All other dialogs that I found are either native ones (File -> Print...) or implemented inside the content area (Help -> Submit Feedback...), and work.

Ghostery is blaming us for this, but I can't reproduce so I have no idea what's going on. TBH, naively (and from the assertion failure in the duped bug) it would seem that they're trying to load stuff into every XUL document in a way that doesn't work. They should probably whitelist XUL docs with chrome:// URLs and not do whatever they're doing in there. Moving to add-on compat because that's where this belongs.

I can reproduce this with the following steps (Firefox 44.0.1 64 bit, Windows 8.1 64 bit): 1. Create a new profile. 2. Open about:config. 3. Create Boolean preference nglayout.debug.disable_xul_cache and set it to true. 4. Install Adblock Plus (version 2.7.1 at the moment). 5. Just in case: Close Firefox and launch it again. 6. Go to menu 'History' > 'Clear Recent History'. Actual result: Dialog is collapsed, only title bar and buttons shown. Expected result: All elements of dialog shown.

(In reply to Sebastian H. [:aryx][:archaeopteryx] from comment #14) > 6. Go to menu 'History' > 'Clear Recent History'. > Actual result: > Dialog is collapsed, only title bar and buttons shown. > Expected result: > All elements of dialog shown. I'm confused… Clear Recent History is independent of a Refresh/Reset (which can be found in about:support among other places). See the attachment. Are you saying there is a general problem affecting multiple dialogs that you think has the same cause?

(In reply to Matthew N. [:MattN] from comment #15) > Are you saying there is a general problem affecting multiple dialogs that > you think has the same cause? Yes, see: (In reply to Peter Weilbacher from comment #11) > The History -> Clear Recent History... dialog also shows up empty. All other > dialogs that I found are either native ones (File -> Print...) or > implemented inside the content area (Help -> Submit Feedback...), and work. Dialogs from addons which were broken with that preference and ABP: e.g. the settings of Tab Mix Plus or the settings for a userscript of GreaseMonkey.

In that case the summary should have been changed and the platform should have been update to include Windows.

This doesn't occur with https://addons.mozilla.org/de/firefox/addon/adblock-plus/versions/?page=2#version-2.6.13.4084-beta (released 2015-11-29) but with https://addons.mozilla.org/de/firefox/addon/adblock-plus/versions/?page=2#version-2.6.13.4085-beta (release 2015-12-02) The latter version contains the merge of ABP's e10s branch: https://hg.adblockplus.org/adblockplus/rev/44bed2de3b2c Repository: https://hg.adblockplus.org/adblockplus/shortlog

(In reply to Sebastian H. [:aryx][:archaeopteryx] from comment #18) > Created attachment 8718037 [details] [diff] [review] > adblock.diff > > This doesn't occur with > https://addons.mozilla.org/de/firefox/addon/adblock-plus/versions/ > ?page=2#version-2.6.13.4084-beta (released 2015-11-29) > but with > https://addons.mozilla.org/de/firefox/addon/adblock-plus/versions/ > ?page=2#version-2.6.13.4085-beta (release 2015-12-02) > > The latter version contains the merge of ABP's e10s branch: > https://hg.adblockplus.org/adblockplus/rev/44bed2de3b2c > > Repository: https://hg.adblockplus.org/adblockplus/shortlog Wladimir, any idea what's going on here? :-)

Only slight idea. We've had multiple similar layout issues reported (e.g. https://issues.adblockplus.org/ticket/3541 and https://issues.adblockplus.org/ticket/3489). So far we could always trace it back to doing synchronous messaging from nsIContentPolicy.shouldLoad() - regardless of what message we sent and whether it has any effect. There seems to be some platform bug involved but so far we weren't successful narrowing it down.

Sorry, my bad - turned out that the DOMi issue is reproducible by simply accessing node.ownerDocument.documentElement from nsIContentPolicy.shouldLoad(), I suspect that it is the same here as well. I cannot reproduce the issue on OS X, so maybe somebody else can try reproducing it with the minimal extension attached and without Adblock Plus.

(In reply to Wladimir Palant from comment #21) > Created attachment 8718346 [details] > Minimal extension triggering the issue > > Sorry, my bad - turned out that the DOMi issue is reproducible by simply > accessing node.ownerDocument.documentElement from > nsIContentPolicy.shouldLoad(), I suspect that it is the same here as well. I > cannot reproduce the issue on OS X, so maybe somebody else can try > reproducing it with the minimal extension attached and without Adblock Plus. Mike, can I tempt you?

I filed bug 1247640 on the synchronous messaging issue as it appears to be unrelated.

(In reply to :Gijs Kruitbosch from comment #22) > (In reply to Wladimir Palant from comment #21) > > Created attachment 8718346 [details] > > Minimal extension triggering the issue > > > > Sorry, my bad - turned out that the DOMi issue is reproducible by simply > > accessing node.ownerDocument.documentElement from > > nsIContentPolicy.shouldLoad(), I suspect that it is the same here as well. I > > cannot reproduce the issue on OS X, so maybe somebody else can try > > reproducing it with the minimal extension attached and without Adblock Plus. > > Mike, can I tempt you? Sure, why not? :) I installed the add-on, and set nglayout.debug.disable_xul_cache to true. After restarting the browser, I can confirm that the "Clear Recent History" dialog is empty.

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #24) > (In reply to :Gijs Kruitbosch from comment #22) > > (In reply to Wladimir Palant from comment #21) > > > Created attachment 8718346 [details] > > > Minimal extension triggering the issue > > > > > > Sorry, my bad - turned out that the DOMi issue is reproducible by simply > > > accessing node.ownerDocument.documentElement from > > > nsIContentPolicy.shouldLoad(), I suspect that it is the same here as well. I > > > cannot reproduce the issue on OS X, so maybe somebody else can try > > > reproducing it with the minimal extension attached and without Adblock Plus. > > > > Mike, can I tempt you? > > Sure, why not? :) > > I installed the add-on, and set nglayout.debug.disable_xul_cache to true. > After restarting the browser, I can confirm that the "Clear Recent History" > dialog is empty. Right, I guess I asked you because of the synchronous messaging thing which comment #23 now says is likely unrelated... though I don't know *why* it would be unrelated. Just so we're clear, the access to documentElement, is that all CPOWs? Or not? Wladimir? I'm kind of assuming not in that DOMI is all parent process... While XUL can be unhappy about stuff being touched while it's still in the process of constructing a document, I'm not sure why just accessing the document element would break things in this case... :-\

(In reply to :Gijs Kruitbosch from comment #25) > Just so we're clear, the access to documentElement, is > that all CPOWs? Or not? Wladimir? I'm kind of assuming not in that DOMI is > all parent process... No CPOWs, it's a content policy running in all processes without any compatiblity shims. Both ABP and this test extension have <em:multiprocessCompatible>true</em:multiprocessCompatible> set. In fact, I realized that a simple work-around is bailing out early for chrome: and resource: URLs - that's what we did before the e10s branch was merged. This resolves both issues, so I'll get this change landed in the Adblock Plus development builds and release an update on February 23.

The work-around just landed (https://hg.adblockplus.org/adblockplus/rev/637c6ebb90c1) and will be part of the Adblock Plus 2.7.1.4137-beta development build as well as Adblock Plus 2.7.2 on February 23.

I'll try to look at whether there's a similar fix that could be applied to Ghostery next week. Needinfo so I don't forget. That said, I'm still worried about the fact that this is breaking things in Firefox to the extent that it does. :-\

I can't reproduce the issue with Ghostery 5.4.10 and Firefox 44.0.2 on Windows 8.1. The 'Clear Recent History' mentioned in comment 11 shows up normal. Peter, can you still reproduce the issue? If yes, do you have the preference nglayout.debug.disable_xul_cache set to true?

(In reply to Sebastian H. [:aryx][:archaeopteryx] from comment #29) > I can't reproduce the issue with Ghostery 5.4.10 and Firefox 44.0.2 on > Windows 8.1. The 'Clear Recent History' mentioned in comment 11 shows up > normal. > > Peter, can you still reproduce the issue? If yes, do you have the preference > nglayout.debug.disable_xul_cache set to true? Looks like 5.4.10 has "+ Fixes issues where the options page is blank in the old Ghostery panel" in the AMO release notes.

Though, hm, maybe that's a separate issue. They also listed having solved a conflict with abp, but I don't see any fixes in the diff with 5.4.9 that look related to what's been discussed in this bug so far.

(In reply to Sebastian H. [:aryx][:archaeopteryx] from comment #29) > Peter, can you still reproduce the issue? If yes, do you have the preference > nglayout.debug.disable_xul_cache set to true? Yes, I still see the same problem. With Ghostery 5.4.10 and Adblock Plus 2.7.1 (without the patch here, since I don't currently have time to figure out how to apply it) and nglayout.debug.disable_xul_cache=true (don't remember any more why I have that set, probably from a few years ago).

request validation if this is still and issue with latest version of Ghostery and AdBlock Plus and that one configuration. not common to set that outside of certain dev scenarios - but obviously not a desired result In general, the only time it’s useful to set this preference to true is during extension development, modification of chrome files, or developing other XUL applications in a flat-chrome environment. http://kb.mozillazine.org/Nglayout.debug.disable_xul_cache

I can't reproduce the issue anymore with both Firefox 48.0 and 51.0a1 20160810 and Ghostery 6.3.1 or Adblock Plus 2.7.3 (fixed in comment 27).

Yes, Adblock Plus worked around this issue a while ago. This doesn't mean that the issue doesn't exist any more - it might still be reproducible with the test extension attached here. Priority is a question of course.

valid bug - lower priority due to edge case though. can raise if it is hit frequently.

With Firefox 57 only WebExtensions are permitted and are, by default, e10s compatible.