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

Status: VERIFIED FIXED

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

Description

[Matt Brubeck (:mbrubeck)]

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.

Comment 1

[Brian R. Bondy [:bbondy]]

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.

Comment 2

[Brian R. Bondy [:bbondy]]

p=1

Comment 3

[Matt Brubeck (:mbrubeck)]

I'm now seeing this in an official mozilla-central Nightly build.

Comment 4

[Matt Brubeck (:mbrubeck)]

I'm not certain it's related, but I started seeing this consistently around the time bug 949590 landed.

Comment 5

[Jim Mathies [:jimm]]

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.

Comment 6

[Jim Mathies [:jimm]]

(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.

Comment 7

[Jim Mathies [:jimm]]

Attachment: fix

Move setting the last browser type to app startup so it's always up to date.

Comment 8

[Jim Mathies [:jimm]]

Attachment: fix

added commenting, removed windows line endings and tabs.

Comment 9

[Jim Mathies [:jimm]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/17e55676871a

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/17e55676871a

Comment 11

[Jim Mathies [:jimm]]

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.

Comment 12

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/14d5fa456121

Comment 13

[u279076]

Matt since this was an issue reproducible locally for you can you please confirm this is working now with Firefox 28 and 29?

Comment 14

[Matt Brubeck (:mbrubeck)]

Tested and verified on the latest Aurora and Nightly builds on a Surface Pro 2.

Comment 15

[u279076]

(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.