Closed Bug 940168 Opened 11 years ago Closed 7 years ago

Running firefox.exe from installation path doesn't switch to metro environment when running

Categories

(Firefox for Metro Graveyard :: Browser, defect, P4)

x86_64
Windows 8.1
defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: kjozwiak, Unassigned)

References

Details

(Whiteboard: [completed-oak] [defect] p=0)

If you attempt to launch firefox.exe through the installation path while Firefox Metro is running in the background, nothing will happen. You'll see the "loading" cursor appear briefly and then disappear without anything occurring. If you launch Firefox Desktop through any of the shortcuts while Firefox Metro is running, it will correctly switch environments.

This is relating to shared profiles using the oak build provided from Bug 924860 Comment 7

Steps to reproduce the issue:

1) Ensure you have the oak build installed mentioned above
2) Once installed, launch Firefox Metro and leave it running in the background
3) Once running, go into the Firefox Nightly installation directory and attempt to launch Firefox using the "firefox.exe" executable

Current Behavior:

- When double clicking firefox.exe executable in the installation directory and Firefox Metro is running, nothing will occur.

Expected Behavior:

- When a user double clicks on firefox.exe it should switch over to Firefox Metro if its currently running. If it's not running, open Firefox Desktop.
Yep this is a great find. When you go direct to the EXE it doesn't go to the CEH and so it doesn't open the browser. We need to add code to detect if the Metro browser is open within startup code.
Whiteboard: [block28][completed-oak] feature=defect c=tbd u=tbd p=0 → [release28][completed-oak] feature=defect c=tbd u=tbd p=0
Took 2 points from contingency for this.
Whiteboard: [release28][completed-oak] feature=defect c=tbd u=tbd p=0 → [release28][completed-oak] feature=defect c=tbd u=tbd p=2
Assignee: nobody → msamuel
Blocks: metrov1it20
No longer blocks: metrov1backlog
Status: NEW → ASSIGNED
Priority: -- → P2
QA Contact: jbecerra
Whiteboard: [release28][completed-oak] feature=defect c=tbd u=tbd p=2 → [block28][completed-oak] feature=defect c=tbd u=tbd p=2
Whiteboard: [block28][completed-oak] feature=defect c=tbd u=tbd p=2 → [release28][completed-oak] feature=defect c=tbd u=tbd p=2
Blocks: metrov1it21
No longer blocks: metrov1it20
Whiteboard: [release28][completed-oak] feature=defect c=tbd u=tbd p=2 → [beta28] [completed-oak] feature=defect c=tbd u=tbd p=2
Blocks: metrov1it22
No longer blocks: metrov1it21
Whiteboard: [beta28] [completed-oak] feature=defect c=tbd u=tbd p=2 → [beta28] [completed-oak] [defect] p=2
Blocks: metrov1backlog
No longer blocks: metrov1it22
Assignee: msamuel → nobody
Status: ASSIGNED → NEW
QA Contact: jbecerra
Summary: Defect - Running firefox.exe from installation path doesn't switch to metro environment when running → Running firefox.exe from installation path doesn't switch to metro environment when running
Should this block release? Seems like a dev centric corner case.
Flags: needinfo?(netzen)
I don't think too much can block release :) But I think this is pretty important. If a user happens to launch directly from the installation path, which I'm sure happens on the Release channel, and the metro browser is open, they will basically think that Firefox isn't starting and they can't start it.  They'd probably result to task manager, kill the browser, and then curse it, not realizing it was from Metro Firefox.
Flags: needinfo?(netzen)
I don't understand why a user would ever browser into program files to launch the exe directly though. (This seems 'corner case' to me based on my own Windows usage - I never do this.)
One other note unrelated to whether we block on this, if we do try to fix this we'll have to be careful about breaking automated testing, which does launch the exe directly via the command line.
Blocks: metrobacklog
No longer blocks: metrov1backlog
Whiteboard: [beta28] [completed-oak] [defect] p=2 → [completed-oak] [defect] p=0
Priority: P2 → P4
Mass close of bugs in obsolete product https://bugzilla.mozilla.org/show_bug.cgi?id=1350354
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.