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.
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.
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
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.
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
Last Resolved: 5 years ago
Resolution: --- → FIXED
Could this be added to the current iteration for testing as well?
(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/
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!
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.
(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.