Closed Bug 791571 Opened 13 years ago Closed 13 years ago

Session restore is never completed

Categories

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

17 Branch
defect
Not set
normal

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)
Attachment #670065 - Flags: review?(bzbarsky) → review+
Status: ASSIGNED → RESOLVED
Closed: 13 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.

Attachment

General

Created:
Updated:
Size: