Closed Bug 429315 Opened 17 years ago Closed 17 years ago

Firefox freezes on loading large clickable map with lots of mouseover images and javascript

Categories

(Core :: Layout, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: casalod, Assigned: roc)

References

()

Details

(Keywords: hang, regression)

Attachments

(3 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5 On loading all the images/mouseover images of a clickable map (html) firefox freezes while loading these images. Reproducible: Always Steps to Reproduce: 1. Go to URL http://www.hotelbenchmark.com/AboutUs/MarketCoverage/Europe-EN.aspx 2. Wait for the map to load Actual Results: Half way loading the map firefox freezes. Expected Results: not freezing
Total freeze up on an early hourly from today Vista HP SP1 - had to force kill. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008041602 Minefield/3.0pre Firefox/3.0 ID:2008041602
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: hang
Version: unspecified → Trunk
Attached file Simplified test case
Total freeze on: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9pre) Gecko/2008041506 Minefield/3.0pre ID:2008041506 I've been using trial and error, by stripped away large portions of the code and have come up with a simplified test case.
Making this one so people don't freeze their Firefox. Very odd, going to nominate for blocking to at least get triage.
Flags: blocking-firefox3?
Confirmed by beltnzer on Vista, WFM on Mac.
Component: General → Layout
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → layout
Doesn't happen in Firefox 2 on the same system. Worth nominating for blocking 1.9? Also someone needs to think of a more relevant title, the problem isn't related to the Javascript at all.
Keywords: regression
Attached is the stacktrace of the offending thread. I was using ff 3.0 b5. 0:000> cdb: Reading initial command '~~[984]kf;q' Memory ChildEBP RetAddr 0012f994 605246ef xul!ViewWrapper::QueryInterface+0x48 118 0012faac 6052481f xul!nsViewManager::UpdateWidgetArea+0x19f 118 0012fbc4 60496693 xul!nsViewManager::UpdateWidgetArea+0x2cf 28 0012fbec 605b2045 xul!nsViewManager::ProcessPendingUpdates+0x83 14 0012fc00 605b209b xul!nsViewManager::FlushPendingInvalidates+0x71 8 0012fc08 605b20d9 xul!nsViewManager::EnableRefresh+0x39 10 0012fc18 606b75b1 xul!nsViewManager::EndUpdateViewBatch+0x28 14 0012fc2c 6049e151 xul!nsIViewManager::UpdateViewBatch::EndUpdateViewBatch+0x14 24 0012fc50 605785e8 xul!PresShell::DoFlushPendingNotifications+0xe1 14 0012fc64 604ddd5d xul!PresShell::ReflowEvent::Run+0x36 24 0012fc88 604af56a xul!nsThread::ProcessNextEvent+0x29d 18 0012fca0 6063e990 xul!nsBaseAppShell::Run+0x4a c 0012fcac 6057a06a xul!nsAppStartup::Run+0x1e c 0012fcb8 00000000 xul!XRE_main+0xdac quit:
Given this just reduces down to a few HTML elements and a single CSS element, seems pretty serious enough to ask for blocking 1.9. Developers know best obviously, but may as well try.
Flags: blocking1.9?
This has the same regression range as bug 412623, so likely related. I noticed that this bug's testcase doesn't show the assertions like in that bug, though. In any case, this is probably a regression from bug 408656.
Blocks: 408656
Assignee: nobody → roc
Attached patch fixSplinter Review
rather trivial patch.
Attachment #316150 - Flags: superreview?(bzbarsky)
Attachment #316150 - Flags: review?(bzbarsky)
I'm going to make this block since it's a crash regression affecting a real site, and we have a fairly safe patch here.
Flags: blocking1.9? → blocking1.9+
Whiteboard: [needs review]
Comment on attachment 316150 [details] [diff] [review] fix If possible, add a crashtest?
Attachment #316150 - Flags: superreview?(bzbarsky)
Attachment #316150 - Flags: superreview+
Attachment #316150 - Flags: review?(bzbarsky)
Attachment #316150 - Flags: review+
Sure, attachment 316000 [details] is a fine crashtest.
Whiteboard: [needs review] → [needs approval]
Comment on attachment 316150 [details] [diff] [review] fix Simple safe fix for a crash regression on a real site.
Attachment #316150 - Flags: approval1.9?
Comment on attachment 316150 [details] [diff] [review] fix a=beltzner, please also checkin the crashtest
Attachment #316150 - Flags: approval1.9? → approval1.9+
checked in with crashtest.
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs approval]
I backed this out to try to fix test failures.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
It wasn't the fault of this bug. I'll reland later.
Whiteboard: [needs landing]
relanded
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: