Closed Bug 968267 Opened 6 years ago Closed 6 years ago

Passive updates might not restart properly in metro mode

Categories

(Toolkit :: Application Update, defect, P1)

x86_64
Windows 8.1
defect

Tracking

()

VERIFIED FIXED
mozilla30
Tracking Status
firefox28 --- verified
firefox29 + verified
firefox30 + verified
b2g-v1.3 --- fixed

People

(Reporter: jimm, Assigned: jimm)

References

Details

(Whiteboard: p=1 s=it-30c-29a-28b.1 r=ff30)

Attachments

(1 file)

https://bugzilla.mozilla.org/attachment.cgi?id=8366662&action=diff

This introduced a bug where if we passively update the browser and the user never hits the restart button in the about flyout, on the next restart we will try to launch desktop.
Attached patch fixSplinter Review
Assignee: nobody → jmathies
Attachment #8370827 - Flags: review?(netzen)
We'll want to uplift this to aurora as well with the work in bug 950241.
Status: NEW → ASSIGNED
Priority: -- → P1
QA Contact: jbecerra
Whiteboard: [release28] [defect] p=0 s=it-30c-29a-28b.1
Target Milestone: --- → mozilla28
Hey Jim, can you provide a point value.
Flags: needinfo?(jmathies)
Flags: needinfo?(jmathies)
Whiteboard: [release28] [defect] p=0 s=it-30c-29a-28b.1 → [release28] [defect] p=0 s=it-30c-29a-28b.1 p=1
Whiteboard: [release28] [defect] p=0 s=it-30c-29a-28b.1 p=1 → [release28] [defect] p=1 s=it-30c-29a-28b.1
Attachment #8370827 - Flags: review?(netzen) → review+
Target Milestone: mozilla28 → mozilla30
https://hg.mozilla.org/mozilla-central/rev/5cdcde433fd6
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [release28] [defect] p=1 s=it-30c-29a-28b.1 → p=1 s=it-30c-29a-28b.1 r=ff30
Blocks: metrobacklog
No longer blocks: metrov1backlog
Comment on attachment 8370827 [details] [diff] [review]
fix

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 950241
User impact if declined: nothing major, sometimes the browser wont launch on the first attempt due to a pending update.
Testing completed (on m-c, etc.): mc and oak
Risk to taking this patch (and alternatives if risky): very low
String or IDL/UUID changes made by this patch: none
Attachment #8370827 - Flags: approval-mozilla-beta?
Attachment #8370827 - Flags: approval-mozilla-aurora?
Attachment #8370827 - Flags: approval-mozilla-beta?
Attachment #8370827 - Flags: approval-mozilla-beta+
Attachment #8370827 - Flags: approval-mozilla-aurora?
Attachment #8370827 - Flags: approval-mozilla-aurora+
For the following verification process, I used the following Nightly build and updated via the "Options" flyout:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-02-11-03-02-01-mozilla-central/

Went through the following test cases:

- Went through the original test case from comment #0 and made sure the issue wasn't occurring anymore
- Once fxmetro was updated and closed without restarting, ensured that clicking the shortcut under the Taskbar correctly launched fxmetro
- Once fxmetro was updated and closed without restarting, ensured that clicking the shortcut under the Desktop correctly launched fxmetro
- Once fxmetro was updated and closed without restarting, ensured that clicking the shortcut under Metro Start correctly launched fxmetro
- Ensured that that the previous session is restored without any issues (tried with different combinations of tabs, 1, 5, 8, 15)
- Ensured that once you've updated and re-launched fxmetro, you can switch between the desktop and metro environments without any issues
- Went through all of the above test cases using several other combinations of snapped view, ensured that fxmetro was launched in the correct views
- Made sure that if you updated from the desktop, re-launching the browser will correctly launch fxdesktop rather then fxmetro
- Ensured that once you've updated via the desktop, you can switch into fxmetro without any issues

The only issue that I've ran into was Bug # 967403 which is currently being worked on.
For the following verification process, I used the following Aurora build and updated via the "Options" flyout:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-02-12-00-40-02-mozilla-aurora/

- Went through all the test cases from comment #9 and ensured that the original issue wasn't occurring
- Ensured that closing the browser during "Applying Update" didn't cause any issues major issues and restarted in the correct environment
- Went through at least 25 updates using the variation of the test cases from comment #9 and never ran into the issue mentioned in comment #0
Because the current beta version doesn't have anything to update towards to, I'll wait till another beta comes out to complete verification for firefox29.
(In reply to Kamil Jozwiak [:kjozwiak] from comment #11)
> Because the current beta version doesn't have anything to update towards to,
> I'll wait till another beta comes out to complete verification for firefox29.

Kamil, we are getting Beta 4 builds this evening. Can you please retest this on Beta tomorrow?
Keywords: verifyme
For the following verification process, I used the following BETA build and updated via the "Options" flyout:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/28.0b3/ (Installed)
- http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/28.0b4/ (Updated to this version)

- Went through the original test case from comment #0 and made sure the issue wasn't occurring anymore
- Went through the test cases added in comment #9 without any issues
- Went through the test cases added in comment #10 without any issues

Anthony, it looks like this also needs to be verified against b2g-v1.3. I'm not sure who does the verifications for B2G.. Does that also need to be verified for the issue to be marked as "Verified"?
Flags: needinfo?(anthony.s.hughes)
Thanks Kamil. That's sufficient to call this verified fixed. I'll leave it to the B2G team to ensure this is verified there.
Status: RESOLVED → VERIFIED
Flags: needinfo?(anthony.s.hughes)
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.