607722 - Clicking the Windows 7 taskbar menu item "enter private browsing" affects the default installation instead of the current installation

Status: NEW

(Firefox :: Private Browsing, defect)

Description

[JK]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6) Gecko/20100101 Firefox/4.0b6
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6) Gecko/20100101 Firefox/4.0b6

Clicking the Windows 7 taskbar menu item "enter private browsing" affects the default installation instead of the current installation.

For example, if I click Minefield's (started with -no-remote -p "nightly") private browsing menu item, and the default Firefox 4 beta 6 (default profile) is running, FF4b6 with the default profile will be opened in private mode (with non-responding tab candy items), instead of Minefield with the nightly profile.

If FF4b6/default browser is not running, it will start checking plugin compatibility of the default profile, but Minefield will open in normal mode & nightly profile.

Reproducible: Always

Steps to Reproduce:
Click the Windows 7 right click menu item "enter private browsing" of Minefield.
Actual Results:  
The default browser will open in private mode with messed up tab candy.

The -no-remote and -p "profile" arguments are not (fully) obeyed.

Expected Results:  
Clicking the private browsing menu item of Minefield should open Minefield in private mode, instead of the default browser.

The -no-remote and -p "profile" arguments should be obeyed.

Comment 1

[JK]

Here's the correct build identifier:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101027 Firefox/4.0b8pre

Comment 2

[JK]

This is a bad bug since the non-default browser opens in normal mode when private mode is expected. (If the default browser is not already running.)

Comment 3

[Shawn Collier]

I've noticed this for a while since I have it setup so I can run Firefox and Minefield at the same time.

Comment 4

[Alice0775 White]

And the problem happen since first attempt:
47b733ac1c7e	Jim Mathies — Bug 519985 - Add privacy mode task item to win7 jump list. r=dao.

Comment 5

[(no longer active)]

Jim, this happens because remoting is disabled in the first instance, right?

Comment 6

[(no longer active)]

FWIW, I don't think that this should block, since it's a non-typical use case, but I will defer the decision to drivers.

Comment 7

[Jim Mathies [:jimm]]

(In reply to comment #0)
> For example, if I click Minefield's (started with -no-remote -p "nightly")
> private browsing menu item, and the default Firefox 4 beta 6 (default profile)
> is running, FF4b6 with the default profile will be opened in private mode (with
> non-responding tab candy items), instead of Minefield with the nightly profile.

so -

version #1 running with no-remote

version #2 running without no-remote

you select private browsing from the jump list of #1 (no-remote), and #2 (no-remote) acts on the command?

sounds like a bug in our no-remote code since #1 is remoting the command to #2. Maybe no-remote only blocks one way or something.

Regardless, no-remote is a developer feature, this shouldn't block release.

Comment 8

[Jim Mathies [:jimm]]

lets try that again with some clarity:

version #1 running with no-remote

version #2 running normally

you select private browsing from the jump list of #1 (no-remote), and #2
(normal) acts on the command.

Comment 9

[Jim Mathies [:jimm]]

(In reply to comment #2)
> This is a bad bug since the non-default browser opens in normal mode when
> private mode is expected. (If the default browser is not already running.)

This may be a valid bug, but it has little to do with jump lists. you should be able to reproduce this via the command line.

Comment 10

[(no longer active)]

(In reply to comment #8)
> lets try that again with some clarity:
> 
> version #1 running with no-remote
> 
> version #2 running normally
> 
> you select private browsing from the jump list of #1 (no-remote), and #2
> (normal) acts on the command.

We don't really execute anything under #1, we just run a new instance of Firefox, which remotes the command to #2, since #1 has remoting disabled.  Or at least, that's my understanding of the problem.

That being said, I'm not sure how this could be addressed...

Comment 11

[JK]

(In reply to comment #8)
> lets try that again with some clarity:
> 
> version #1 running with no-remote
> 
> version #2 running normally
> 
> you select private browsing from the jump list of #1 (no-remote), and #2
> (normal) acts on the command.

Yes.

I haven't tested what happens when you run the default browser with no remote and non-default normally.

Comment 12

[(no longer active)]

This is not a critical bug, please refrain from modifying the Severity field needlessly.

Comment 13

[JK]

Also, #2 doesn't need to run.

From the bug description:

"If FF4b6/default browser is not running, it will start checking plugin
compatibility of the default profile, but Minefield will open in normal mode &
nightly profile."

I think this is about the defaultness, not no-remote.

Comment 14

[JK]

(In reply to comment #12)
> This is not a critical bug, please refrain from modifying the Severity field
> needlessly.

There is a problem that the fields, like severity, don't update without bypassing the cache. Sorry.

Comment 15

[(no longer active)]

(In reply to comment #13)
> Also, #2 doesn't need to run.
> 
> From the bug description:
> 
> "If FF4b6/default browser is not running, it will start checking plugin
> compatibility of the default profile, but Minefield will open in normal mode &
> nightly profile."
> 
> I think this is about the defaultness, not no-remote.

When you click that menu entry, we launch Firefox in the background like this:

firefox.exe -private-toggle

Firefox will go ahead and try to see if there's a remotable instance running already.  If it can find one, it will remote the private-toggle command to it (which is the case Jim was talking about).  Otherwise, it will launch a new instance (which is the case in comment 13).

Comment 16

[Jim Mathies [:jimm]]

(In reply to comment #15)
> (In reply to comment #13)
> > Also, #2 doesn't need to run.
> > 
> > From the bug description:
> > 
> > "If FF4b6/default browser is not running, it will start checking plugin
> > compatibility of the default profile, but Minefield will open in normal mode &
> > nightly profile."
> > 
> > I think this is about the defaultness, not no-remote.
> 
> When you click that menu entry, we launch Firefox in the background like this:
> 
> firefox.exe -private-toggle
> 
> Firefox will go ahead and try to see if there's a remotable instance running
> already.  If it can find one, it will remote the private-toggle command to it
> (which is the case Jim was talking about).  Otherwise, it will launch a new
> instance (which is the case in comment 13).

I wonder though why the new instance doesn't get the privacy mode set right? If the add-in checker came up, it sounds like it opened a profile that was being upgraded from a previous rev.. Which is odd.

Comment 17

[(no longer active)]

(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #13)
> > > Also, #2 doesn't need to run.
> > > 
> > > From the bug description:
> > > 
> > > "If FF4b6/default browser is not running, it will start checking plugin
> > > compatibility of the default profile, but Minefield will open in normal mode &
> > > nightly profile."
> > > 
> > > I think this is about the defaultness, not no-remote.
> > 
> > When you click that menu entry, we launch Firefox in the background like this:
> > 
> > firefox.exe -private-toggle
> > 
> > Firefox will go ahead and try to see if there's a remotable instance running
> > already.  If it can find one, it will remote the private-toggle command to it
> > (which is the case Jim was talking about).  Otherwise, it will launch a new
> > instance (which is the case in comment 13).
> 
> I wonder though why the new instance doesn't get the privacy mode set right? If
> the add-in checker came up, it sounds like it opened a profile that was being
> upgraded from a previous rev.. Which is odd.

Why is it odd?  All the initialization steps should still happen, right?

Comment 18

[Jim Mathies [:jimm]]

(In reply to comment #17)
> Why is it odd?  All the initialization steps should still happen, right?

I just wonder if this was in fact the case, that this was first run. If it was, then it's not an issue. [e-mail], can you confirm?

Comment 19

[[not reading bugmail]]

I'm confused if comment 0 starts with running firefox.exe and trying to execute another instance from another shortcut which only obeys the current running version of firefox.exe regardless.

Comment 20

[Jim Mathies [:jimm]]

(In reply to comment #19)
> I'm confused if comment 0 starts with running firefox.exe and trying to execute
> another instance from another shortcut which only obeys the current running
> version of firefox.exe regardless.

only obeys? not sure what you mean there. if an instance of firefox.exe is running, and another copy of firefox.exe is executed, process 2 communicates with process one about the action requested and then shuts down. (That's assuming the first instance isn't running with the -no-remote option sent)

Comment 21

[[not reading bugmail]]

(In reply to comment #20)
> (In reply to comment #19)
> > I'm confused if comment 0 starts with running firefox.exe and trying to execute
> > another instance from another shortcut which only obeys the current running
> > version of firefox.exe regardless.
> 
> only obeys? not sure what you mean there. if an instance of firefox.exe is
> running, and another copy of firefox.exe is executed, process 2 communicates
> with process one about the action requested and then shuts down. (That's
> assuming the first instance isn't running with the -no-remote option sent)

I think part of this is just bug 601391.  The other thing I was thinking is that using the terminology in comment 0 for default install and current installation sounds like trying to use 2 shortcuts assuming Windows will let the user run two version of firefox.exe, which it doesn't or never did.

Comment 22

[JK]

(In reply to comment #18)
> (In reply to comment #17)
> > Why is it odd?  All the initialization steps should still happen, right?
> 
> I just wonder if this was in fact the case, that this was first run. If it was,
> then it's not an issue. [e-mail], can you confirm?

It was not the first run of the version on the nightly profile. Minefield accessed the default profile (but still opened with the nightly profile), which I didn't want it to do.

> I think this is about the defaultness, not no-remote.

The no-remote switch is the cause, just tested. It works fine without no remote.

Comment 23

[JK]

This could be used as a security hole.

-Attacker makes a Firefox shortcut with -no-remote
-Victim opens Firefox and selects the private mode from the jumplist
-Firefox is opened in normal mode
-Private information is leaked

No admin rights needed, unlike when installing spyware. Also, no special spy hardware needed.

Comment 24

[Jim Mathies [:jimm]]

(In reply to comment #22)
> (In reply to comment #18)
> > (In reply to comment #17)
> > > Why is it odd?  All the initialization steps should still happen, right?
> > 
> > I just wonder if this was in fact the case, that this was first run. If it was,
> > then it's not an issue. [e-mail], can you confirm?
> 
> It was not the first run of the version on the nightly profile. Minefield
> accessed the default profile (but still opened with the nightly profile), which
> I didn't want it to do.
> 
> > I think this is about the defaultness, not no-remote.
> 
> The no-remote switch is the cause, just tested. It works fine without no
> remote.

Can you give some detail on how you have your profiles set up? I'd like to try and reproduce.

Comment 25

[JK]

-A default profile
-A nightly profile

-Start Minefield with -no-remote -p "nightly" (don't have any other browsers running)
-Click "private browsing" (jumplist)

-> Minefield accesses the default profile (checks addons)
-> Minefield opens with the nightly profile, in normal mode

It's strange that it first accesses the default profile, but opens with the nightly profile.

The no remote switch makes the jumplist item hiddenly useless.

It's hiddenly useless unless the user knows that the private mode is active only if the Firefox/Minefield button is purple.

Comment 26

[(no longer active)]

(In reply to comment #23)
> This could be used as a security hole.
> 
> -Attacker makes a Firefox shortcut with -no-remote
> -Victim opens Firefox and selects the private mode from the jumplist
> -Firefox is opened in normal mode
> -Private information is leaked
> 
> No admin rights needed, unlike when installing spyware. Also, no special spy
> hardware needed.

There's no security problem there.  If the attacker has enough access to your machine to install a shortcut, they can also install whatever spying software they want on your computer (admin rights is not required for that).

Comment 27

[[not reading bugmail]]

I tried this a bit.

I have setup a 'FF3.6' profile and 'FF4' profile with profile manager.  I created the FF3.6 profile with Firefox 3.6 and FF4 profile with Minefield.
I created these two Firefox 3.6 shortcut and Minefield shortcuts for testing purposes: (also the profile names are case-sensitive, otherwise it wont work right)

my Firefox 3.6 shortcut consists of: firefox.exe -no-remote -P "FF3.6"
my Minefield shortcut consists of: firefox.exe -no-remote -P "FF4"

Launch Firefox 3.6 shortcut.  You get the correct profile.
Now launch Minefield shortcut using jumplist enter private browsing. It probably is loading FF3.6 profile (which will then checks addons, because I justed use FF3.6 on it) and die.  

It checks addons on the profile because of switching Firefox versions.

or

Launch Firefox 3.6 shortcut.  You get the correct profile.
Now Launch Minefield shortcut.  You get the correct profile, click on jumplist enter private browsing and the PB does not start.

Launch Firefox 3.6 shortcut.  It checks addons, and you get the correct profile.
ReLaunch Firefox 3.6 shortcut.  You get the correct profile with no addon checking.

Either way, the check addons part only occurs when different versions of firefox are run on the same profile back to back.

As far as I can tell, the real problem seems to be just the jumplist item for enter private browsing is confused under multiple different scenarios, include the case of using quit PB from the jumplist after using -no-remote -P "FF4" will actually check for addons rather than update the current browser window.

Comment 28

[[not reading bugmail]]

PB items off the jumplist does not appear to know which profile its using.

Comment 29

[[not reading bugmail]]

(In reply to comment #28)
> PB items off the jumplist does not appear to know which profile its using.

So bringing this back around, jumplist PB items get confused when paired with -no-remote.

So confirming without -no-remote, after you just launch Minefield using firefox.exe -P "FF4", the jumplist item PB works after you have the browser window running, then selecting the jumplist items enter or quit private browsing it knows which window is running and updates properly.

Else it is the other bug when using the jumplist item on startup without -no-remote.

Comment 30

[Johnathan Nightingale [:johnath]]

A bug worth understanding and fixing, but Ehsan's correct, it doesn't block.