601391 - Using Enter Private Browsing from Windows 7 Jumplist doesn't open a browser window after selecting a profile with profile manager

Status: RESOLVED WORKSFORME

(Firefox :: Private Browsing, defect)

Description

[[not reading bugmail]]

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

It doesn't load a browser window. 

Reproducible: Always

Steps to Reproduce:
1. Don't have browser open
2. Select Enter Private Browsing from Jumplist
3. Select Profile
4. Click start browser
Actual Results:  
Browser window doesn't come up

Expected Results:  
a PB window opens

Comment 1

[(no longer active)]

Is this regression new in the October 2 nightly?  If so, this could be a regression from bug 568816.

Comment 2

[[not reading bugmail]]

Confirmed by the backout, though PB wasn't invoked.

Comment 3

[[not reading bugmail]]

So what happens is that instead of a PB window opening after selecting a profile the whole browser just dies.

Comment 4

[Dietrich Ayala (:dietrich)]

I don't think we would block on something that requires the Profile Manager to trigger, and even then it also requires private browsing, so it's a very narrow scenario. So blocking- for now. However, the "whole browser just dies" is pretty scary.

Ehsan, do you know what's happening here?

Re-request blocking if information comes to light that indicates this is a more serious problem.

Comment 5

[[not reading bugmail]]

Well, since it has worked since Jim added the feature to jumplists, the way it is, you can no longer start in PB mode from the jumplist.  So its now broken.

Either way it doesn't matter about profile manager though see bug 603272. Its just that I noticed that startup gets that far before it dies.  And its a regression from changes in bug 568816.

Comment 6

[(no longer active)]

(In reply to comment #4)
> Ehsan, do you know what's happening here?

I think this happens because when you launch the browser from the profile manager, remoting gets disabled, which means that we can't send the -private-toggle command to the running instance.  Another instance of this problem is bug 607722.

> Re-request blocking if information comes to light that indicates this is a more
> serious problem.

Well, I think we should block on this, except if a fix is not feasible.  This is basically a piece of our secondary UI which is broken in some cases.

Whether or not this is something which can be easily fixed is something which someone who knows our remoting code can tell better than me.  CCing Gavin and bsmedberg to see if they know who.

Comment 7

[Benjamin Smedberg]

No, the profile manager is not exposed UI and we don't block on it. And the profile manager doesn't *automatically* imply -no-remote.

Comment 8

[(no longer active)]

(In reply to comment #7)
> No, the profile manager is not exposed UI and we don't block on it.

I was talking about the jumplist menu entry when I talked about the secondary UI, not the profile manager...

> And the profile manager doesn't *automatically* imply -no-remote.

Hmm, but when I launch ./firefox -P, I get the same behavior as when I would launch Firefox with -no-remote.  Am I missing something?

Comment 9

[[not reading bugmail]]

Looks like bug 568816 bypassed the profile manager completely now on startup and only loads the last profile that was used, this is still a problem, since profile manager doesn't load first.

Comment 10

[[not reading bugmail]]

(In reply to comment #9)
> Looks like bug 568816 bypassed the profile manager completely now on startup
> and only loads the last profile that was used, this is still a problem, since
> profile manager doesn't load first.

Er, with bug 603272 fixed it I think I mean to say...

Comment 11

[Christian Ascheberg]

(In reply to comment #10)

I can confirm that a browser window opens now. Also, the profile manager is triggered when there is more than one profile available (and "Don't ask at startup" is unchecked).

Comment 12

[[not reading bugmail]]

Confirming as well, not sure when it got fixed or by which bug, though it might be nice to know here.

Mozilla/5.0 (Windows NT 6.1; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre ID:20110303122446