Closed Bug 843248 Opened 11 years ago Closed 11 years ago

Upgrading with maintenance service from a non metro build to a metro build does not show tile


(Firefox for Metro Graveyard :: Shell, defect)

Windows 8.1
Not set


(Not tracked)

Firefox 22


(Reporter: kjozwiak, Assigned: bbondy)




(2 files)

1. Install a fresh Windows 8 installation
2. Install this build which does not have Metro enabled.
3. Set the browser as your default.
4. Open your about box and perform an update. 

Actual results:
Start screen has a firefox icon until you reboot

Expected results:
Firefox tile shows right away

If you don't use the maintenance service for the upgrade everything works like it should.

This bug only happens if you are upgrading with the maintenance service.
Blocks: metrov1triage
No longer blocks: 841197
Reproduced as you said only when the maintenance service is used.  Since updates are hard to test before it lands I was previously only testing by running helper.exe /PostUpdate once. 

My best guess is that it's caused by helper.exe being run twice for maintenance service upgrades. 

I verified this with 2 small test programs. 

The first opens up the property store for the shortcut with:
And leaves it open.

The second tries to open up the property store again but fails because it's already opened.

I think the fix is to not run this code when helper.exe is being run from the service I.e. when the session ID is 0.
Blocks: 841197
No longer blocks: metrov1triage
Blocking the story Marco since upgrading with the service is the default. What we'd end up with is a ton of users who should get the metro browser when we finally release it, but they'd have to wait an additional 6 weeks to see the browser.
Blocks: 831590
Ran procmon and did confirm helper.exe is running under session 1.  So race condition is likely.
Hi Brian.  Thanks for the clarification.
Attached patch Patch v1.Splinter Review
Assignee: nobody → netzen
Attachment #716221 - Flags: review?(jmathies)
Attachment #716221 - Flags: review?(jmathies) → review+
Pushed here:

Hard to test this without a build though so may need to be re-opened. Took a guess at what I thought the problem was.
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 22
I'm still getting this on a fresh VM so unfortunately it wasn't because of a race condition on ApplicationID::Set.  I'll try to find a better way to test this other than running helper.exe /PostUpdate
Resolution: FIXED → ---
OK I found a better way to test this by replacing the helper.exe after the update is staged inside the <installdir>/updated.  

I found out the cause of the failure. 
The problem is that with session 0 $9 is never set to the session ID, so it remains its default value which is "".

The check below does "${If} $9 != 0 then install the CEH" and "" != 0 with NSIS so it goes in there with session 0 when it shouldn't.

I verified that always calculating $9 fixes the problem.
Attachment #716632 - Flags: review?(jmathies)
By the way I tried removing the previous fixes but they are all still needed.
Attachment #716632 - Flags: review?(jmathies) → review+
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Went through the following on a fresh Windows 8 x86 VM created in VirtualBox

Downloaded the following build:

- Checked and ensured that the Firefox Nightly icon was being used
- Selected Help -> About Nightly and updated to the latest version of Firefox Nightly (21.0a1 2013-02-22)
- Checked and ensured that the Firefox Metro tile was being used (without needing to restart as before)
- Double checked and made sure Firefox launches in Metro and in Desktop mode

Finally worked :) Thanks!
Works for me too on my VM with the same build.
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.