Closed Bug 841610 Opened 11 years ago Closed 11 years ago

Work - Shortcuts to other fx installs should not cause the default browser to open the target exe

Categories

(Firefox for Metro Graveyard :: Shell, defect, P5)

x86_64
Windows 8
defect

Tracking

(Not tracked)

VERIFIED FIXED
Firefox 26

People

(Reporter: jimm, Assigned: bbondy)

References

Details

(Keywords: qawanted, Whiteboard: feature=work)

STR:

1) pin firefox install a on the taskbar while running
2) set firefox install b as the default browser
3) click on the taskbar shortcut

result: install b will open and ask you what you would like to do with "firefox.exe", which is the exe from install a.
OS: Windows 7 → Windows 8 Metro
OS: Windows 8 Metro → Windows 8
ugh. that's funky. is this a new problem in windows 8?
(In reply to Asa Dotzler [:asa] from comment #1)
> ugh. that's funky. is this a new problem in windows 8?

yes, it has to do with the new way we launch on win8.
Whiteboard: [metro-mvp?]
Blocks: 831889
No longer blocks: metrov1triage
Whiteboard: feature=work c=Opening_and_closing u=metro_firefox_user
Blocks: metrov1it4
Summary: Shortcuts to other fx installs cause the default browser to open the target exe → Defect - Shortcuts to other fx installs cause the default browser to open the target exe
Whiteboard: feature=work c=Opening_and_closing u=metro_firefox_user → feature=defect c=Opening_and_closing u=metro_firefox_user p=0
Priority: -- → P1
Does this really need to be a P1? It's specific to people who have multiple firefox installs, which is mostly devs and testers.
Whiteboard: feature=defect c=Opening_and_closing u=metro_firefox_user p=0 → feature=defect c=Opening_and_closing u=metro_firefox_user p=3
Since most users don't have multi installs I think we should maybe make a multi install problem top level story (for v2) and assign a bunch of stuff to it, including this.  Kamil posted a bunch of different similar stories as well. I agree with jimm that we shouldn't do this in it4.
Also this problem will go away once all channels that people install are Metro.
Flags: needinfo?(mmucci)
Blocks: metrov1triage
No longer blocks: metrov1it4
Priority: P1 → P5
Flags: needinfo?(mmucci)
Blocks: 855311
No longer blocks: 831889
No longer blocks: metrov1triage
Summary: Defect - Shortcuts to other fx installs cause the default browser to open the target exe → Work - Shortcuts to other fx installs should not cause the default browser to open the target exe
Whiteboard: feature=defect c=Opening_and_closing u=metro_firefox_user p=3 → feature=work
I think this was fixed in bug 888363 as part of this changeset:
https://hg.mozilla.org/mozilla-central/rev/60bf438fa2f2
Changeset first landed in bug 888363.
Marking as resolved so QA can test this as normal using comment 0 steps.
Assignee: nobody → netzen
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Could this be added to the current iteration for testing as well?
Flags: needinfo?(manuela.muntean)
Keywords: qawanted
(In reply to Brian R. Bondy [:bbondy] from comment #6)
> Could this be added to the current iteration for testing as well?

Yes, I think it's ok. I will add it to the tracking doc and also verify it for this iteration, #13/
Flags: needinfo?(manuela.muntean)
Depends on: 888363
Target Milestone: --- → Firefox 26
I've tried 2 scenarios while testing this for iteration #13, and assuming

a = latest Aurora
b = latest Nightly
c = a Nightly from May 2013

here are my results (using Win 8 64bit):

- the STR from comment 0, work when using a and b
- the STR from comment 0 don't work anymore (I'm asked what I would like to do with "firefox.exe", while opening b from the taskbar, after I installed c and I opened it from the taskbar; but when I also open a from the taskbar, I don't get that dialog)

So this issue seems partially fixed. Does anyone have any suggestions/thoughts? Thanks!
Flags: needinfo?
You can't use a Nightly from May 2013 because that has the old CEH which has this bug in it. I think in c) you should be using the same build as b) just in a different location.
Flags: needinfo?
(In reply to Brian R. Bondy [:bbondy] from comment #10)
> You can't use a Nightly from May 2013 because that has the old CEH which has
> this bug in it. I think in c) you should be using the same build as b) just
> in a different location.

This works. Marking this verified, based on comment 9, comment 10 and comment 11, with latest Nightly -build ID: 20130905030206, for iteration #13.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.