841197 - Upgrading from older nightly that has been set as default browser does not show nightly for metro tile after upgrade

Status: VERIFIED FIXED

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

Description

[juan becerra [:juanb]]

If you install an older nightly on Windows 8 and set it up as your default browser at the prompt, and then upgrade to the latest (which supports Firefox for Metro), the nightly tile for Metro does not appear in the Start page.

Resetting all defaults for the program didn't show the Nightly tile.

Installing the latest nightly (pave-over) on top of the version resulting from the upgrade works.

Comment 1

[juan becerra [:juanb]]

Please bear with me for a few bugs while I get used to the flow.

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Manual workaround: Go into the desktop Control Panel, Programs, set Default Programs. Select Internet Explorer, and set that as the default. Then restart Firefox, it will ask whether to make itself the default - do that.

Comment 4

[Brian R. Bondy [:bbondy]]

Attachment: Patch v1.

This wasn't really triaged, but it's completely apparent that this is an important task so I went ahead with doing this fix now.

Comment 5

[Brian R. Bondy [:bbondy]]

https://hg.mozilla.org/mozilla-central/rev/2902b3e73b92

Comment 6

[Brian R. Bondy [:bbondy]]

Kamil would you mind testing this one?

Comment 7

[Kamil Jozwiak [:kjozwiak]]

This mostly passes but there is still an issue.
The Nightly Metro browser now works after upgrading but if you don't have the Metro tile in your cache the user won't see the Metro tile until rebooting your computer.  The user can use the Metro browser from the Firefox icon on the start screen though even before the reboot.

To clear your Tile cache:
- Go to the settings charm from the Windows 8 Start Screen and select Tiles and then click the Clear button.
- Delete this folder: C:\ProgramData\PRICache
- Reboot if you previously had Nightly Metro installed

This issue still happens intermittently even if you have no cache, but clearing the tile may help.

System Used:
Windows 8 x86 (Completely Updated) in a VM hosted in Virtual Box

Downloaded the following build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-02-08-03-10-53-mozilla-central/firefox-21.0a1.en-US.win32.installer.exe

- Installed the above build, selected "Launch Nightly now" and then selected "Finish"
- Once Firefox has launched, selected "Yes" to set Firefox as the default browser
- Selected the "Nighty" icon when prompted by Windows 8 on how to open http links
- Completely closed Firefox and switched to Windows Metro mode
- Selected the Firefox Nightly tile and the application ran in windows mode (in the Desktop)
- Back on Desktop, selected Help -> About Nightly and updated to the latest version of Firefox Nightly (21.0a1 2013-02-15)
- Once the update has been completed, selected "Restart to Update"
- Once Firefox relaunched, closed the application and switched into Windows Metro mode
- Selected the Firefox tile and Firefox opened in Windows Metro mode (**Note: the icon appears the same as before, using the nightly icon)
- Ran Firefox several times in Windows Metro mode and the icon still appeared the same as before (Firefox Nightly icon not Win8 tile)
- Restarted the Windows 8 x86
- Once the machine has been restarted, the Firefox tile has changed to the "Blue Firefox Win 8 Tile"
- Launched Firefox once again using the new icon to ensure that the application still launches in Windows Metro mode without any

Comment 8

[Asa Dotzler [:asa]]

Let me see if I understand this. You're saying that if a user ignores the restart warning on the Firefox update, that she won't see the Metro tile for Metro Firefox until after a restart? If so, that's expected behavior.

Comment 9

[Brian R. Bondy [:bbondy]]

I was able to reproduce what Kamil said. 
The fix I did allows you to launch the metro browser after update, but the icon *sometimes* doesn't update to a metro tile until you physically reboot your machine.  

i.e. after upgrading and restarting the browser, when you go to the start screen you still see a nightly icon instead of a metro Firefox tile.  But if you click it you go into the metro browser.

There's a shell notification call that is documented in the "Developing a Metro style enabled Desktop browser" doc that may help this that I'll try calling after updating.  Unfortunately I can only reproduce what Kamil said about 1 out of 10 times so it'll be hard for me to tell if the change actually does fix it.

Comment 10

[Kamil Jozwiak [:kjozwiak]]

You should be able to reproduce this consistently 100% of the time if you use a fresh install that has never had Firefox Metro on it before. Just use a VM and take a snapshot after installing the OS, then revert back to it each time you need to test.

Comment 11

[Brian R. Bondy [:bbondy]]

Attachment: Patch v1 - Fix for no cache re-creating tile

Changes:
- Removed the delete of the start menu tile.  It isn't needed and it causes problems like in bug 842039 (we can close that bug after this lands too)

- Now only set the start menu appusermodel ID on PostUpdate if the browser being updated is the default.  This is for multiple installs we don't want to keep flipping the app user model id for the last browser updated.

- I was able to reproduce the Metro tile not showing until the computer was physically rebooted consistently by using a fresh VM like Kamil suggested. I was hoping for a fix without a Sleep but it just simply won't work without it.  It's like Windows doesn't actually do the appusermodelid change right away.  The RegisterCEH stuff makes the tile refresh but if it's done too close to the appusermodelid change it won't show the tile. I can always reproduce without this patch with a fresh VM and I can always confirm this patch works with a fresh VM showing the tile right away.

Comment 12

[Jim Mathies [:jimm]]

Comment on attachment 715497 [details] [diff] [review]
Patch v1 - Fix for no cache re-creating tile

Review of attachment 715497 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/installer/windows/nsis/shared.nsh
@@ +190,5 @@
>  !endif
>  
> +  ; If RegisterCEH is called too close to changing the shortcut AppUserModelID
> +  ; and if the tile image is not already in cache.  Then Windows won't refresh
> +  ; the tile image on the start screen.  So wait before calling RegisterCEH.

Are we sure there isn't something here we can just delete from the reg, like we do for the splash?

http://mxr.mozilla.org/mozilla-central/source/browser/installer/windows/nsis/shared.nsh#728

@@ +193,5 @@
> +  ; and if the tile image is not already in cache.  Then Windows won't refresh
> +  ; the tile image on the start screen.  So wait before calling RegisterCEH.
> +!ifdef MOZ_METRO
> +  ${If} ${AtLeastWin8}
> +    Sleep 3000

Does this mean that little progress dialog that sometimes shows up will be visible for at least three seconds?

Comment 13

[Brian R. Bondy [:bbondy]]

> Does this mean that little progress dialog that sometimes shows up 
> will be visible for at least three seconds?

No the progress dialog is before this code. This code runs in the background after an update and the user doesn't know. 


> Are we sure there isn't something here we can just delete from the reg, 
> like we do for the splash?

The problems seems to be that the setting of the app user model id doesn't happen right away even know it is called. Then the code that actually does the refresh at the end refreshes the tile fine, but it happens before the appusermodel id is actually set by windows.

Comment 14

[Brian R. Bondy [:bbondy]]

The update doesn't wait for this to finish either by the way.

Comment 15

[Brian R. Bondy [:bbondy]]

I could add code to make sure it only happens exactly once maybe?

Comment 16

[Brian R. Bondy [:bbondy]]

Attachment: Patch v2 - Fix for no cache re-creating tile

I only do the sleep now if the user doesn't have have a DEH. 
I think this has to do with when the shortcut changes dual mode but I'm not sure exactly. 

I think we should land this and pass it back through testing to see if it works in both cases of i) fresh computer and ii) has had metro on it before to see if it works.  Works for me locally but this changed v2 patch I'm worried about case ii) intermittently.

Comment 17

[Brian R. Bondy [:bbondy]]

Using procmon by the way shows that explorer.exe changes nightly.lnk.  So what probably happens is that the COM call passes the work of setting the appusermodelID and dualmode bit to explorer.exe, and then it's a race condition to see if we refresh the icon first or explorer.exe finishes its work first.  The sleep 3000 makes it so explorer.exe will finish first and then the refresh happens after.

Comment 18

[Brian R. Bondy [:bbondy]]

https://hg.mozilla.org/mozilla-central/rev/71e84eb9db9f

Kamil you'll have to wait until tomorrow's nightly build is built to test this.
When testing please test both a fresh machine that hasn't had metro firefox on it, and also a machine that has had it on it.

Also if you could verify that bug 842039 no longer happens that would be awesome. Just mark it as Resolved / Works for me if you can no longer reproduce that one.

Comment 19

[Kamil Jozwiak [:kjozwiak]]

Downloaded and installed the following build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-02-08-03-10-53-mozilla-central/firefox-21.0a1.en-US.win32.installer.exe

Updated to the following build using "Help -> About Nightly": 22.0a1 (2013-02-20)

Works:
- Update fresh computer WITHOUT the maintenance service DOES give a metro tile.

Doesn't work:
- Update fresh computer WITH the maintenance service DOES NOT give a metro tile.

Will create a new bug regarding maintenance service and the metro tile.

Comment 20

[Kamil Jozwiak [:kjozwiak]]

marking as verified

Comment 21

[Brian R. Bondy [:bbondy]]

Interesting about the maintenance service.

helper.exe is run from both the system account and user account with the maintenance service.

So I think what's happening is that there's a file in use error when the user helper.exe process runs and tries to set the appusermodelid on the shortcut.