Closed Bug 1294933 Opened 3 years ago Closed 10 months ago
‘New Window’ and ‘New Private Window’ options disappear from mac
OS dock context menu when switching to non-tabbrowser top-level window
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160726073904 Steps to reproduce: Update FF from 46.x or 47.x to 48.0 Restart FF Actual results: Options to open new and new private windows by long/right/ctrl-clicking on FF icon have disappeared. Expected results: Options to open new window and new private window still ought to be there.
Component: Untriaged → Menus
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86
Hi, I think this bug is related to a latter one : https://bugzilla.mozilla.org/show_bug.cgi?id=1297839 I've experienced the same problem after my update to FF 48.x The Safe Mode  makes things work correctly again so it may come from an addon My activated plugin list: Easy Copy Modify Headers Print Edit Saved Password Editor Scrapbook X Tab Mix Plus The desactivated list is quite longer but i'm not sure it will help  https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
In fact, it seems that restarting to the normal mode solved the problem (after desactivating and reactivating one addon)
(In reply to daja from comment #2) > In fact, it seems that restarting to the normal mode solved the problem > (after desactivating and reactivating one addon) Would you happen to know which exact add-on caused the issue and restored functionality once it was disabled?
My test was with Easy Copy but I can't conclude that this addon caused the issue. To be more precise: I disabled it while in Safe Mode, restarted in normal mode (and dock menu was ok) and enabled it back, restarted in Safe Mode (things still ok of course) and restarted in normal mode (things still ok) From my point of view, it comes from the update process (mainly because of the other (rude) bug report) and the activated addon list of other users may help to confirm this perception.
In my configuration, it was also the last added addon
The dock menu worked properly after I disabled and re-enabled the Saved Password Editor add-on. However, Firefox itself became much less stable. It started crashing frequently. And now (a week later), the dock menu is not working properly again (New Window entries disappear). Seems to me that something is probably corrupted, likely because of a bug in FF.
Update to previous comment: I am not on v50.1.0. After the previously noted instabilities, I started up again in Safe Mode and disabled all the add-ons (there were only 4) other than the Add-on Compatibility Reporter and restarted. Then I re-enabled my 4 add-ons (CookieExFilter,Permit Cookies 2,Saved Password Editor,and The Camelizer) and restarted. It has been stable and the dock menu has been working properly for over a day now.
(In reply to Craig from comment #8) > Update to previous comment: > > I am not on v50.1.0. After the previously noted instabilities, I started up > again in Safe Mode and disabled all the add-ons (there were only 4) other > than the Add-on Compatibility Reporter and restarted. Then I re-enabled my > 4 add-ons (CookieExFilter,Permit Cookies 2,Saved Password Editor,and The > Camelizer) and restarted. It has been stable and the dock menu has been > working properly for over a day now. Spoke too soon. Of course just after writing comment, the New Window entries disappeared from the dock icon. At least FF still seems stable for the moment.
For me it happened while editing bookmarks today morning. I was able to reproduce the issue once more while playing around with bookmarks. I remember facing this 1 or 2 times before today too, perhaps a few weeks back. But that I time I just killed Firefox and started it again. This time I did the same but I am more interested in finding a solution. Sharing my experience in case it gives any clue.
(In reply to JA from comment #10) > For me it happened while editing bookmarks today morning. I was able to > reproduce the issue once more while playing around with bookmarks. > > I remember facing this 1 or 2 times before today too, perhaps a few weeks > back. But that I time I just killed Firefox and started it again. This time > I did the same but I am more interested in finding a solution. Sharing my > experience in case it gives any clue. Just to confirm, I reproduced it once more just now. All I had to do was- Click on Bookmarks->Show All Bookmarks, then just close the bookmarks pop-up. Hope this helps.
I was going to say that the latest version (51.0.1) was working better - it had gone almost 2 days without losing the New Window dock menu items. But sure enough, 'Bookmarks->Show All Bookmarks, close' causes the dock items to disappear for me too. As an aside (and possibly related), I also notice that when I click on the Firefox icon in the dock to go to an existing window, the focus always moves to the screen containing the Firefox window (I use Spaces or whatever it is currently called), but Firefox only sometimes becomes the active application.
Thanks for your observation JA - indeed my experience also shows that the right-click menus for new windows disappear after viewing bookmarks & history and not apparently otherwise, that should help narrow it down. Still happening with 52.0.2. FF otherwise reliable. Cheers
Confirmed with 54.0.1 in MacOS 10.12.5.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 48 Branch → 54 Branch
Also observed with 54.0.1 in MacOS 10.12.6. Only one add-on present, no apparent difference between it being enabled or disabled. The number of open windows does not seem to have an effect.
Opening any of these windows, then closing it, seems to trigger this bug; Bookmarks > Show all Bookmarks, History > Show all History, Tools > Downloads each open the Library, close it, then the Dock icon no longer shows options for New Window nor New Private Window. It also happens with Tools > Page Info. I can reproduce on Fx 54.0.1. Cannot reproduce the bug on latest Nightly 56.0a1 (20170728)
(In reply to Tracy Walker [:tracy] from comment #16) > I can reproduce on Fx 54.0.1. Cannot reproduce the bug on latest Nightly > 56.0a1 (20170728) Nice find. I've used mozregression --find-fix to narrow the fix down: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e323bc846da065850b8b755fcced8c6da9b3669e&tochange=680e1321476c3c58df4a53cf118a40b23b8a7f3b As well as opening then closing the library, I've discovered that opening Help > About breaks the dock menu, and this is *not* fixed by the above changesets.
Summary: "Open New Window" options no longer in OSX 10.11 dock icon → "Open New Window" options disappear from MacOS dock icon
Today I noticed this too in FF57 Stable, FF58 Beta and FF59 Nightly on macOS 10.12.6: The right-click options on the Dock icon to open a new Window / new Private Window disappear after opening the "About Firefox/Nightly" window. Attached a screencast.
Andrei, can your team try to reproduce from the details here or in the duplicate bug? I think it may depend on there being a new update for Nightly pending. Thanks (and happy new year!)
Hi, I've been looking at this issue today and what I've found is that the steps in comment #19 are reproducible 100% of the times with Firefox Nightly (latest) on every macOS 10.x. What I did was: - open the build - open "About firefox" - close "About firefox" - right click on the icon to see that the menu entries are gone. This has nothing to do with pending updates for Nightly. As long as you open "about firefox" then close it the menu entries will be gone, regardless of the state of the update, just like in the attachment from comment #19.
asimonca: I can confirm your findings. Spectacular work finding this!
Hi. Just one more information: It also happens, if you select "Show All History" and close this window again. So it seems, that it always happens, when a separate window like the Library-Window or the About-Window was in use.
Hardware: x86 → x86_64
Summary: "Open New Window" options disappear from MacOS dock icon → ‘New Window’ and ‘New Private Window’ options disappear from macOS dock context menu when switching to non-tabbrowser top-level window
Too late to fix in 59, but we can still take a patch in Nightly if 61 is affected.
Yes, 61 is affected. I can reproduce it in 61.0a1 (2018-03-13) (64-Bit) on macOS 10.12.6. Thanks.
This is from bug 1262110, right? That code was shuffled around a bit in bug 1473160, but is otherwise intact from its original landing. If I'm reading it right, whenever a non-browser window is closed, it nulls out the dockmenu object where the new window and new private window items are housed, and the quick search I did doesn't seem to show anywhere we regenerate it when a different window is given focus. If I comment out that `dockSupport.dockMenu = null;` line and re-build, the menu items don't disappear when I close the About window, but this likely reintroduces whatever leaks bug 1262110 plugged.
Depends on: 1262110
Is there a better place than nonBrowserWindowShutdown to null out dockmenu that still plugs the leak from bug 1262110? Or can/should nonBrowserWindowShutdown check *which* non-browser window is being shutdown and only null out dockmenu for the final hidden window shutting down?
For whatever it's worth, I did a try push of just commenting out that line , and none of the Mac debug bc chunks are failing. The logs from the failure that prompted bug 1262110's creation have long since expired, so I can't tell what test was leaking back then. Maybe we don't need that line after all?  https://treeherder.mozilla.org/#/jobs?repo=try&author=wkocher%40mozilla.com&fromchange=62a4062e3bc6f715c3f0752849c367a34529175e&tochange=4078c1a39ae4d691dd01cdb9c4a0c04c38c9baf8&group_state=expanded
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/4fdf3fd34bfc Only release the reference to the mac dockmenu when the hidden window is shutdown r=peterv
https://hg.mozilla.org/projects/cedar/rev/4fdf3fd34bfc816a68fe4e34ad116626807bb022 Bug 1294933 - Only release the reference to the mac dockmenu when the hidden window is shutdown r=peterv
You need to log in before you can comment on or make changes to this bug.