Closed Bug 791571 Opened 7 years ago Closed 7 years ago

Session restore is never completed

Categories

(Core :: DOM: Core & HTML, defect)

17 Branch
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla19
Tracking Status
firefox16 --- unaffected
firefox17 + verified
firefox18 + verified
firefox19 --- verified

People

(Reporter: alice0775, Assigned: khuey)

References

Details

(Keywords: regression, reproducible)

Attachments

(1 file)

Build Identifier:
http://hg.mozilla.org/mozilla-central/rev/f7c89de3ab43
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120916030607

Session restore is never completed.
ie. Loading forever (tab throbber do not stop)

This happens in Aurora17.0a2 and Nightly18.0a1 with clean profile

Steps to reproduce:
1. Open 
    1st tab http://www.mozilla.org/projects/firefox/prerelease.html?oldversion=17.0a1
    2nd tab http://www.mozilla.org/en-US/firefox/central/
    3rd tab https://www.google.co.jp/
    4th tab http://www.youtube.com/watch?v=55s3T7VRQSc

2. Select 2nd tab
3. Exit Firefox (File > Exit)
4. Start Firefox and Restore Previous Session

Actual results:
  Loading forever (tab throbber do not stop)

Expected results:
  Restoreiong should be performed properly.

Regression window:
Good:
http://hg.mozilla.org/mozilla-central/rev/3b46b03dff5c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120815053101
Bad:
http://hg.mozilla.org/mozilla-central/rev/d67c02074ced
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120815065301
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3b46b03dff5c&tochange=d67c02074ced

Last Good: 5c730c1f2274 +d5e42dcb36fd+d67c02074ced
First bad: 55b5cab554b5 +d5e42dcb36fd+d67c02074ced

Triggered by:
55b5cab554b5	Kyle Huey — Bug 697230: Part 2 - Push onload blocking logic down into imagelib. r=joe sr=bz
Assignee: nobody → khuey
Keywords: reproducible
Kyle can you reproduce this?  Any sense of where this work will be fitting into your next 6 weeks?
I haven't tried to reproduce this, but I strongly suspect this is a duplicate of Bug 789846.
Bug 789846 did not fix this problem...
I can still reproduce.
http://hg.mozilla.org/mozilla-central/rev/ec10630b1a54
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121010030605
I don't think session restore is required; it looks like http://www.mozilla.org/en-US/firefox/central/ never finishes loading.  I'll dig in.
I think I've figured this out.
Status: NEW → ASSIGNED
Component: Style System (CSS) → DOM: Core & HTML
OS: Windows 7 → All
Hardware: x86 → All
Attached patch PatchSplinter Review
Unfortunately we need to continue tracking whether or not the request is blocking onload in nsImageLoadingContent.  Otherwise we can run into a situation where when BlockOnload is called the <img> is in the document but when UnblockOnload is called it has been removed.  I considered using the owner document instead of the current document, and not tracking the load-blocking status, but that would make <imgs> that aren't in the document block onload, which seems undesirable.  We'd also still have to handle adoptNode ...
Attachment #670065 - Flags: review?(bzbarsky)
Comment on attachment 670065 [details] [diff] [review]
Patch

r=me
Attachment #670065 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/mozilla-central/rev/5b26e3ffe80d
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Comment on attachment 670065 [details] [diff] [review]
Patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 697230
User impact if declined: Some pages will fail to load properly (because the onload event will never fire)
Testing completed (on m-c, etc.): Manual testing on the regressed site, landed on m-c.
Risk to taking this patch (and alternatives if risky): Low risk.  The patch is pretty straightforward.
String or UUID changes made by this patch: none
Attachment #670065 - Flags: approval-mozilla-beta?
Attachment #670065 - Flags: approval-mozilla-aurora?
Attachment #670065 - Flags: approval-mozilla-beta?
Attachment #670065 - Flags: approval-mozilla-beta+
Attachment #670065 - Flags: approval-mozilla-aurora?
Attachment #670065 - Flags: approval-mozilla-aurora+
this should go into Beta 2, it's reproducible so let's get some verification in the next couple weeks.
Keywords: qawanted, verifyme
Ioana, can you please have someone on your team at Softvision do some regression testing around this? We want to make sure it is fixed in Firefox 18.0a2 and 19.0a1. Thanks.
Keywords: qawanted
QA Contact: ioana.budnar
Verified on Firefox 17 beta 5, Aurora 18.0a2 and Nightly 19.0a1 that the session restore completes properly (if is closed unexpectedly or intentionally).

Verified on Windows 7, Ubuntu 12.04 and Mac OS X 10.7

Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Firefox/17.0 BuidId: 20121106195758
Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/18.0 Firefox/18.0 BuidId: 20121107042011
Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/19.0 Firefox/19.0 BuidId: 20121108030652

Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Firefox/17.0 BuildId: 20121106195758
Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/18.0 Firefox/18.0 BuildId: 20121108042012
Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/19.0 Firefox/19.0 BuildId: 20121107045842


Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Firefox/17.0 BuildId: 20121106195758
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/18.0 Firefox/18.0 BuildId: 20121108042012
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/19.0 Firefox/19.0 BuildId: 20121108030652
Depends on: 822104
Depends on: 824631
Depends on: 826881
Depends on: 843213
You need to log in before you can comment on or make changes to this bug.