Closed Bug 950288 Opened 6 years ago Closed 6 years ago

Defect - After closing Metro Firefox, the tile launches desktop Firefox

Categories

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

x86_64
Windows 8.1
defect

Tracking

(firefox28 verified, firefox29 verified)

VERIFIED FIXED
Firefox 28
Tracking Status
firefox28 --- verified
firefox29 --- verified

People

(Reporter: mbrubeck, Assigned: jimm)

References

Details

(Whiteboard: [beta28] p=1)

Attachments

(1 file, 1 obsolete file)

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.
Blocks: 949590
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.
Attached patch fix (obsolete) — Splinter Review
Move setting the last browser type to app startup so it's always up to date.
Attached patch fixSplinter Review
added commenting, removed windows line endings and tabs.
Attachment #8348040 - Attachment is obsolete: true
Attachment #8348051 - Flags: review?(netzen)
Blocks: metrov1it21
No longer blocks: metrov1backlog
Status: NEW → ASSIGNED
Priority: -- → P2
QA Contact: jbecerra
Attachment #8348051 - Flags: review?(netzen) → review+
https://hg.mozilla.org/mozilla-central/rev/17e55676871a
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+
Target Milestone: Firefox 29 → Firefox 28
Matt since this was an issue reproducible locally for you can you please confirm this is working now with Firefox 28 and 29?
Flags: needinfo?(mbrubeck)
Tested and verified on the latest Aurora and Nightly builds on a Surface Pro 2.
Status: RESOLVED → VERIFIED
Flags: needinfo?(mbrubeck)
(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.