gen-mozilla Reporter
	Description • 8 years ago

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.

	daja
	Comment 1 • 8 years ago

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 [1] 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

[1] https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

	daja
	Comment 2 • 8 years ago

In fact, it seems that restarting to the normal mode solved the problem (after desactivating and reactivating one addon)

	Kamil Jozwiak [:kjozwiak]
	Comment 3 • 8 years ago

(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?

	daja
	Comment 4 • 8 years ago

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.

	daja
	Comment 5 • 8 years ago

In my configuration, it was also the last added addon

	Craig
	Comment 7 • 7 years ago

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.

	Craig
	Comment 8 • 7 years ago

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.

	Craig
	Comment 9 • 7 years ago

(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.

	JA
	Comment 10 • 7 years ago

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.

	JA
	Comment 11 • 7 years ago

(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.

	Craig
	Comment 12 • 7 years ago

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.

	gen-mozilla Reporter
	Comment 13 • 7 years ago

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

	Scott Macpherson
	Comment 14 • 7 years ago

Confirmed with 54.0.1 in MacOS 10.12.5.

	henryneu
	Comment 15 • 7 years ago

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.

	Tracy Walker [:tracy]
	Comment 16 • 7 years ago

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)

	Scott Macpherson
	Comment 17 • 7 years ago

(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.

	Mehmet
	Comment 19 • 7 years ago

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.

	Liz Henry (:lizzard) (relman/hg->git project)
	Comment 21 • 6 years ago

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!)

	Alexandru Simonca [:asimonca], Release Desktop QA
	Comment 22 • 6 years ago

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.

	Andreas Tolfsen ❲:ato❳
	Comment 23 • 6 years ago

asimonca: I can confirm your findings.  Spectacular work finding this!

	Mehmet
	Comment 24 • 6 years ago

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.

	Liz Henry (:lizzard) (relman/hg->git project)
	Comment 25 • 6 years ago

Too late to fix in 59, but we can still take a patch in Nightly if 61 is affected.

	Mehmet
	Comment 26 • 6 years ago

Yes, 61 is affected. I can reproduce it in 61.0a1 (2018-03-13) (64-Bit) on macOS 10.12.6. Thanks.

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed) Assignee
	Comment 27 • 5 years ago

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.

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed) Assignee
	Comment 28 • 5 years ago

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?

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed) Assignee
	Comment 29 • 5 years ago

For whatever it's worth, I did a try push of just commenting out that line [1], 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? 


[1] https://treeherder.mozilla.org/#/jobs?repo=try&author=wkocher%40mozilla.com&fromchange=62a4062e3bc6f715c3f0752849c367a34529175e&tochange=4078c1a39ae4d691dd01cdb9c4a0c04c38c9baf8&group_state=expanded

	Pulsebot
	Comment 31 • 5 years ago

Pushed by wkocher@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4fdf3fd34bfc
Only release the reference to the mac dockmenu when the hidden window is shutdown r=peterv

	Mike de Boer [:mikedeboer]
	Comment 34 • 5 years ago

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