Closed Bug 906721 Opened 7 years ago Closed 7 years ago
UX Nightly: Default shortcut does not start the firefox
.exe, instead opens default Firefox browser
In the several latest UX builds, the default shortcut created by the installer will not open the browser. Instead, it will open the default Firefox installation which will start downloading the local firefox.exe executable file. Tested operating system: Windows 8 x64 Steps to reproduce: - Make sure you already have another Firefox installation. The bug may only work that is the default browser. - Install the UX nightly. - Try to open UX using desktop shortcut created by installer, ensuring that the other Firefox installation is already closed. OR - After succesfully launching UX, pin it to Windows' launchbar. - Close UX. - Try to open UX using that pin. Expected results: - The UX build starts normally. Obtained results: - The default Firefox installation opens and prompts to download the local "firefox.exe" executable of the UX installation.
This sounds like an existing problem that was fixed with bug 888363 which landed on m-c on 08-18. I think the UX branch is a bit behind though.
:bbondy : Well bug 888363 wasn't about the shortcut placed on the Desktop, so I feel there are major differences. You can pin UX and Nightly separately on the launchbar (to be clear, I'm referring the bottom bar in the Desktop view, to the left of the Windows clock) and it still won't work. Regarding bug 888363 specifically: - I personally haven't tested starting UX from the Metro's Start Menu. - :mconley confirmed my tests with a VM, but I don't think he tested that case either. As such, I don't think it is the same issue, I can't say they aren't related.
(In reply to Ricardo Maçãs [:Ricmacas] from comment #2) > :bbondy : Well bug 888363 wasn't about the shortcut placed on the Desktop, > so I feel there are major differences. And I know there are major similarities. Shortcuts have a property set on them specifying their app user model id. This gets routed to our Delegate execute handler on Window 8 which handles the activation. > You can pin UX and Nightly separately on the launchbar (to be clear, I'm > referring the bottom bar in the Desktop view, to the left of the Windows > clock) and it still won't work. > Regarding bug 888363 specifically: > - I personally haven't tested starting UX from the Metro's Start Menu. Bug 888363 was not about starting from Metro's start menu. > - :mconley confirmed my tests with a VM, but I don't think he tested that > case either. > > As such, I don't think it is the same issue, I can't say they aren't related. As mentioned we had this issue on m-c as well and it was recently fixed there. We should retest here when ux gets that changeset.
(In reply to Brian R. Bondy [:bbondy] from comment #3) > As mentioned we had this issue on m-c as well and it was recently fixed > there. We should retest here when ux gets that changeset. Both today's and yesterday's UX nightly will have / had that cset.
Anyone still getting this? If not, we should mark it as a dupe.
Latest UX starts with no problems. But I also couldn't reproduce the initial problem from comment 0 on UX 2013-08-15, 2013-08-19, Win 8 x64. Ricardo, could you please check this again in the latest UX build ?
Dropping qawanted since QA couldn't reproduce this.
Closing this out since it can't be repro'd, should be fixed, and haven't heard back from Ricardo. Also, this shouldn't really track Australis since it is a non-issue once we merge to m-c.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Whiteboard: [Australis:M?][Australis:P3] → [Australis:M-]
I'm very sorry for not answering, I've since begun college and left the original test machine in my other place, this one is running Linux and never had that issue. Clearing the needinfo request.
You need to log in before you can comment on or make changes to this bug.