1171877 - [Windows 10] Taskbar context menu is not working properly when Firefox is launched with -no-remote

Status: RESOLVED WONTFIX

(Firefox :: General, defect, P2)

Description

[Catalin Varga [QA][:VarCat]]

Environment:

FF 39
Build Id:20150604030205
OS: Win 10 x86

STR:

1. Start Firefox.
2. Right Click on the Firefox icon from taskbar.
3. Press new window or new tab in the context menu from the taskbar

Issue:
"Firefox is already running, but is not responding. The old Firefox process must be closed to open a new window." error is prompted.

Note:
The taskbar context menu options are missing for FF 41 and FF 38.0.5

Comment 1

[Robert Kaiser]

[Tracking Requested - why for this release]:
Sounds like something we really want to get fixed before Win10 ships widely.

Comment 2

[Robert Kaiser]

Jim, is this on our list to fix before the Win10 launch?

Comment 3

[Jim Mathies [:jimm]]

I'm over on e10s and not working on this currently, ni'ing dolske since I think the fx team is working on win10 issues.

Comment 4

[:Gijs (he/him)]

I can't reproduce this on current 39 beta or nightly. I do see a context menu, and it works as expected. Catalin, can you recheck?

Comment 5

[Catalin Varga [QA][:VarCat]]

Hi Gij,
I've updated Windows 10 and retested with FF 39.0b4 and the bug is still reproducible for me.

Comment 6

[:Gijs (he/him)]

(In reply to Catalin Varga [QA][:VarCat] from comment #5)
> Hi Gij,
> I've updated Windows 10 and retested with FF 39.0b4 and the bug is still
> reproducible for me.

What build of Windows 10 are you running? Does this just happen in tablet mode, or only in normal mode, or in both? Are you running on a VM or on a "real" machine? Have you checked in safe mode? Do you have any other ideas as to why I can't reproduce?

Comment 7

[Catalin Varga [QA][:VarCat]]

I'm running build 10130 Windows 10 a real machine and I've tested in normal mode with a real machine. 
Now after the 3rd retesting I've noticed that on one of the tries the bug did not reproduces, as in, new tab, new window were missing from the taskbar context menu. 
I don't know what triggers the bug. 
The bug is reproducing even in safe mode.

Comment 8

[:Gijs (he/him)]

(In reply to Catalin Varga [QA][:VarCat] from comment #7)
> I'm running build 10130 Windows 10 a real machine and I've tested in normal
> mode with a real machine. 
> Now after the 3rd retesting I've noticed that on one of the tries the bug
> did not reproduces, as in, new tab, new window were missing from the taskbar
> context menu. 
> I don't know what triggers the bug. 
> The bug is reproducing even in safe mode.

There was already a note in comment #0 about this. I also don't know what would trigger this... I haven't seen it. :-\

Comment 9

[Liz Henry (:lizzard) (relman/hg->git project)]

It's too late for 39 but we can keep the bug open for 40 in case it pops up again in testing.

Comment 10

[:Gijs (he/him)]

Catalin, if you are still able to reproduce, can you do a screencast with a clean profile and recent Nightly? How do you run Nightly?

Comment 11

[Catalin Varga [QA][:VarCat]]

Hi Gij,

This is a screencast for Nightly 41 that shows that New Tab and New Window options are missing:
https://youtu.be/hIKSDgG9pPs

This is a screencast for Beta 39 that shows the bug from Description :
https://youtu.be/VdYIMbk9t50

Comment 12

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #10)
> Catalin, if you are still able to reproduce, can you do a screencast with a
> clean profile and recent Nightly? 

Is that screencast really a clean profile, as it has history in the context menu?

> How do you run Nightly?

I'm still interested in this question. Do you use the profile manager? Is "use this profile automatically on startup" turned on? Do you run from a commandline with custom options or not?

I continue to not be able to reproduce this. :-\

Comment 13

[Catalin Varga [QA][:VarCat]]

I'm using a clean profile on both Beta and Nightly I'm creating the profiles from Profile Manager, to open the Profile Manager I've added  -no-remote -p to the target of the firefox shortcut. "Use Selected Profile without asking at startup" is checked.

Comment 14

[:Gijs (he/him)]

(In reply to Catalin Varga [QA][:VarCat] from comment #13)
> I'm using a clean profile on both Beta and Nightly I'm creating the profiles
> from Profile Manager, to open the Profile Manager I've added  -no-remote -p
> to the target of the firefox shortcut. "Use Selected Profile without asking
> at startup" is checked.

How do you end up running the instance that has this issue? You open the shortcut and then select the profile anyway? Or some other way? Does removing your changes to the shortcut fix any of these issues?

Comment 15

[Catalin Varga [QA][:VarCat]]

I doesn't matter if I select the profile anyway or I create/choose another one.
Removing the -no-remote -p from the shortcut seems to fix the issue.

Comment 16

[:Gijs (he/him)]

(In reply to Catalin Varga [QA][:VarCat] from comment #15)
> Removing the -no-remote -p from the shortcut seems to fix the issue.

This is interesting. Can you reproduce the same issue on win8 if you do the same thing to the shortcut?

Comment 17

[Jared Wein [:jaws] (please needinfo? me)]

Dropping the priority of this bug due to comment #15 since it requires extra command-line parameters. I can't reproduce this issue with a default profile (no extra profiles created) on Nightly 41.01a 06-16-2015 on Windows 10158 in a VM.

Comment 18

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

(In reply to :Gijs Kruitbosch from comment #16)
> This is interesting. Can you reproduce the same issue on win8 if you do the
> same thing to the shortcut?

Since Catalin is on vacation, I've tried this today and was able to reproduce the issue on both Windows 8.1 x86 and Windows 7 x64 using the following steps:
1. Install Firefox.
2. Create a shortcut to the .exe of the installed version.
3. Right-click the shortcut -> Properties, and add "-no-remote -p" to the "Target" path.
4. Double click the shortcut => the Profile Manager comes up.
5. Create a new profile (or select an existing one), make sure "Use the selected profile without asking at startup" is checked, then choose to Start Firefox with the selected profile.
6. Right-click the icon from the taskbar to get the jumplist, then click on basically any option that would open a new window or page (pretty much anything other than Close or Pin).

Expected results:
New window/tab/page is correctly opened within the same profile.

Actual results: 
"Firefox is already running, but is not responding. The old Firefox process must be closed to open a new window." error is prompted.

Steps 3 & 5 are critical to reproduce this. Note though that this is no new issue as I can easily reproduce back to Firefox 4.0, nor is Windows 10 specific. 

From what I've seen the reasoning for this is quite simple:
- when Firefox is opened from the shortcut, the "-no-remote -p" command overrides the "start without asking" option so you can choose a profile
- when accessing an option from the taskbar jumplist, the "-no-remote -p" command no longer applies while "start without asking" does... so Firefox tries to launch a new instance (not sure why) with the default profile... the default profile is however already open so you get the error that you need to close Firefox

The theory above is easily tested using Firefox DevEdition. Just start DevEdition normally so you get the "dev-edition-default" profile created. Then open one or more pages and close DevEdition. Then do the steps to reproduce from above, but make sure you create/select a profile other than "dev-edition-default". At step 6, you should get a new window and no error... if you restore the session you should see that it's the one for "dev-edition-default" (basically a new window was opened with the "dev-edition-default" profile, which is what DevEdition tries to use on each new start).

I think this is just a very rare edge case that has always been around. I'm clearing the needinfo from Catalin.

Comment 19

[:Gijs (he/him)]

Let's not track this for Windows 10 or for specific releases, considering it is very old.

It sounds like the "no-remote" option also means that the process doesn't talk to new processes. Benjamin, is that intentional? Is this essentially wontfix, or can we improve the behaviour here in some way?

Comment 20

[Benjamin Smedberg]

Yes, -no-remote is the flag whose whole purpose is disabling the remoting feature. The taskbar menu relies on remoting to work correctly. I don't expect us to fix this as a bug independent of getting rid of or fixing profile handling.