Closed Bug 950288 Opened 6 years ago Closed 6 years ago
Defect - After closing Metro Firefox, the tile launches desktop Firefox
I'm seeing a problem where launching my local build from the "Nightly" tile on the Windows Start screen always launches on desktop, even if I was previously running in Metro and have no desktop Firefox processes running. Examining the registry, I can see that launching desktop Firefox correctly sets the MetroLastAHE key to 0, whether I launch it from the Start screen tile or with the "Relaunch in desktop" command in Metro Firefox. However, relaunching in Metro does *not* set MetroLastAHE to 1 as it is supposed to. Setting the value manually to 1 will cause the tile to launch in Metro, but it gets set back if I relaunch in desktop. Tim Abraldes found the same thing when he reported the same symptoms on IRC. I can reproduce this reliably with a local build on my laptop, but I can *not* reproduce it at all using an up-to-date "official" Nightly build on my tablet. Everything works perfectly there. I'm not sure what the relevant difference is between the two builds or machines.
Matt I'm seeing this too, I've had to modify my registry manually to 1 to get it to work when debugging another bug. A quick fix would be to set this registry key from within widget/winrt code that is run everytime the browser starts in metro. Another possible fix is to figure out why it's not getting set correctly in the CEH in all cases. There may be a case that bypasses the CEH completely, so it might be a good idea to set it in widget/winrt.
I'm now seeing this in an official mozilla-central Nightly build.
Summary: Defect - After closing Metro Firefox, the tile launches desktop Firefox (in a local development build) → Defect - After closing Metro Firefox, the tile launches desktop Firefox
Whiteboard: [triage] → [beta28] p=1
I'm not certain it's related, but I started seeing this consistently around the time bug 949590 landed.
Bug 949590 altered the timing of the relaunch a bit, but really didn't mess with the value in the registry. Will take a look.
Assignee: nobody → jmathies
(In reply to Brian R. Bondy [:bbondy] from comment #1) > Another possible fix is to figure out why it's not getting set correctly in > the CEH in all cases. There may be a case that bypasses the CEH completely, > so it might be a good idea to set it in widget/winrt. Looks like this is the case, the LaunchDefaultMetroBrowser() function in the update code doesn't trigger the use of the CEH. So that reg value never gets updated.
Move setting the last browser type to app startup so it's always up to date.
added commenting, removed windows line endings and tabs.
Attachment #8348051 - Flags: review?(netzen) → review+
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
Comment on attachment 8348051 [details] [diff] [review] fix [Approval Request Comment] Bug caused by (feature/regressing bug #): profile sharing work User impact if declined: buggy browser switch functionality. Testing completed (on m-c, etc.): yes. Risk to taking this patch (and alternatives if risky): low. String or IDL/UUID changes made by this patch: none.
Attachment #8348051 - Flags: approval-mozilla-aurora?
Attachment #8348051 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Matt since this was an issue reproducible locally for you can you please confirm this is working now with Firefox 28 and 29?
Tested and verified on the latest Aurora and Nightly builds on a Surface Pro 2.
(In reply to Matt Brubeck (:mbrubeck) from comment #14) > Tested and verified on the latest Aurora and Nightly builds on a Surface Pro > 2. Thanks for the help Matt.
You need to log in before you can comment on or make changes to this bug.