Closed Bug 982462 Opened 10 years ago Closed 10 years ago

Blank metro splash screen appears when launching firefox after the rc update is applied by the metro browser

Categories

(Firefox :: General, defect)

28 Branch
x86_64
Windows 8.1
defect
Not set
normal

Tracking

()

VERIFIED WONTFIX
Tracking Status
firefox28 - affected

People

(Reporter: kjozwiak, Unassigned)

References

Details

Attachments

(1 file)

Attached image blank blue spash screen
When a user attempts to update the browser using fxmetro rather than fxdesktop, they'll receive a completely blank blue splash screen that appears like it has stalled or crashed.

I'm not sure how many users will actually update using fxmetro, but anyone that does will be affected by this problem. We should probably make it a smoother experience and transition into fxdesktop once the update has been completed.

- Attached a screenshot of the issue

Steps to reproduce the issue:

1) Download Firefox Setup 28.0b9.exe
2) Go to C:\Program Files (x86)\Mozilla Firefox\defaults\pref\channel-prefs.js and change the following:
- pref("app.update.channel", "beta"); --> pref("app.update.channel", "releasetest"); currently holding the BETA RC with metro removed
3) Switch over to fxmetro by selecting the Firefox Menu and select "Relaunch in Firefox for Windows 8 Touch"
4) Once you've switch over to fxmetro, swipe in the Windows Charm and select "Settings -> About"
5) Let the update process complete and select "Restart to Update"
This only occurs if Firefox is not set as the default browser. Nominating for tracking.
Summary: updating through fxmetro produces a blank splash screen that doesn't automatically dismiss → Blank splash screen appears when updating fxmetro if it's not the default browser
Jim, can you please comment as to how this impacts shipping Firefox 28?
Flags: needinfo?(jmathies)
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #1)
> This only occurs if Firefox is not set as the default browser. Nominating
> for tracking.

This isn't correct, we wouldn't be launching the metro front end if we weren't the default. This is probably a dupe of bug 982478.
Flags: needinfo?(jmathies)
(In reply to Jim Mathies [:jimm] (away 4/1-4/21) from comment #3)
> (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #1)
> > This only occurs if Firefox is not set as the default browser. Nominating
> > for tracking.
> 
> This isn't correct, we wouldn't be launching the metro front end if we
> weren't the default. This is probably a dupe of bug 982478.

Let me clarify this. There are two separate prompts to set Firefox as default, a Firefox prompt (default browser) and a Windows prompt (default HTTP handler). This bug only reproduces for me if I set Firefox as the "default browser".

In other words...

A blank splash screen appears if I:
1. Install Firefox 28.0b9
2. Set the update channel to releasetest in channel-prefs.js
3. Start Firefox from the Desktop
4. Firefox prompt asks me to set it as default browser
> Opt-in to setting Firefox as the default
5. Windows prompt asks me to choose a default handler for HTTP
> Select Firefox as the handler
6. Switch to touch mode from the Firefox menu
7. Swipe on the right and touch settings
8. Touch About and let the update download
9. Restart Firefox when prompted
> Blank splash screen appears

A blank splash screen DOES NOT appear if I
1. Install Firefox 28.0b9
2. Set the update channel to releasetest in channel-prefs.js
3. Start Firefox from the Desktop
4. Firefox prompt asks me to set it as default browser
> DO NOT set Firefox as the default
5. Windows prompt asks me to choose a default handler for HTTP
> Select Firefox as the handler
6. Switch to touch mode from the Firefox menu
7. Swipe on the right and touch settings
8. Touch About and let the update download
9. Restart Firefox when prompted
> Firefox does not relaunch -- I have to switch back to Desktop to open Firefox, in doing so it opens in Desktop mode
long winded, but accurate I think.
Summary: Blank splash screen appears when updating fxmetro if it's not the default browser → Blank metro splash screen appears when launching firefox after the rc update is applied by the metro browser
Just to clarify, this screen appears and then disappears?  The browser is still usable in both modes?  Is this not a dupe then?  If it's not breaking the use of the browser but is just a visual glitch, we won't block on this.
I won't be able to say if this is a dupe or not until I have a try build to test the steps to reproduce.

As for the UX, the blank screen appears initially on restart then disappears after a couple minutes. If you quit or let this time out and try to launch Firefox again it opens in Desktop mode. It doesn't open in touch mode. In other words I think this is just a one-time visual glitch.

That said I'd like to see if the patch in the other bug fixes this. If it does we can dupe it. If it doesn't we can decide whether or not to fix this separately but I'd argue this doesn't need to block release in this case.
The cause of this is that when we do the update, the updater.exe doing the relaunch is the old one, and it has specialized code in it to launch the metro front end vs. the desktop. So this isn't a dupe, it's a separate issue. We haven't looked at this much yet since we're still trying to diagnose the the shortcuts problem post update. It may not be solvable.
(In reply to Jim Mathies [:jimm] (away 4/1-4/21) from comment #8)
> The cause of this is that when we do the update, the updater.exe doing the
> relaunch is the old one, and it has specialized code in it to launch the
> metro front end vs. the desktop. So this isn't a dupe, it's a separate
> issue. We haven't looked at this much yet since we're still trying to
> diagnose the the shortcuts problem post update. It may not be solvable.

I should clarify, this may not be solvable through a single update. If we rolled people through multiple updates we could smooth this over.
(In reply to Jim Mathies [:jimm] (away 4/1-4/21) from comment #9)
> I should clarify, this may not be solvable through a single update. If we
> rolled people through multiple updates we could smooth this over.

The pain putting users through multiple updates which *might* clean this up is probably greater than the pain of just asking our Touch users to download a new build. Also considering the Touch user base is probably a considerable order of magnitude less than what we'd typically worry about "fixing" if this was an issue affecting Desktop users.
See comment in https://bugzilla.mozilla.org/show_bug.cgi?id=982478#c10 as for why we will not be blocking 28 release on this issue.  It's unfortunate, but it's also a small segment of users who should be able to re-install manually to continue to run FF.
Keywords: verifyme
Group: mozilla-employee-confidential
I don't think this is something we should fix.
If anyone disagrees please re-open.

The affects of this bug changes so that it doesn't display the screen anymore with the fix in bug 981166.
The only left over fallout is an item listed in the apps menu on the left, which you can close. And it's one time, and only if you update from metro.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
I agree with Brian. I've been testing the fixes that have been applied in bug #981166 and never ran into any issues with the splash screen.

As Brian mentioned above, updating from metrofx will leave the splash screen under the apps menu but will never appear on the screen or in front of users. This only happens once and the splash screen will disappear forever once a user restarts or closes the splash screen manually.

- Closing the splash screen manually via the apps menu doesn't cause any issues
- Leaving the splash screen open while using desktopfx doesn't cause any issues
- Launching desktopfx over and over while the splash screen is opened doesn't cause any issues
- Restarting the machine removes the splash screen

I'm going to mark this as verified and remove the "verifeyeme" flag. If Anthony or anyone else from QA disagrees, please re-open.
Status: RESOLVED → VERIFIED
Keywords: verifyme
I went through this using FF 29.0b4 as the changes have been been pushed into the BETA channel. I also double checked using both Nightly/Aurora and made sure everything was still working without any noticeable regressions or other issues. Used the following cases:

- Installed FF 29.0b4 and ensured that the splash screen wasn't appearing when launching the browser
- Installed FF 29.0b3 and updated to 29.0b4, ensured that the browser launches even though the splash screen is listed under the "App list"
- Ensured that restarting the machine dismisses the splash screen and is never run again when launching FF 29.0b4
- Ensured that manually closing the splash screen in the "app list" dismisses it and never appears again when launching FF 29.0b4
- Ensured that selecting the splash screen under the "app list" doesn't launch metrofx or produces any other noticeable issues
- Ensured that logging off the user and than logging back closes the splash screen and never appears again when launching FF 29.0b4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: