Closed Bug 429315 Opened 12 years ago Closed 12 years ago
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
Version: unspecified → Trunk
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.
Confirmed by beltnzer on Vista, WFM on Mac.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Attached is the stacktrace of the offending thread. I was using ff 3.0 b5. 0:000> cdb: Reading initial command '~~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.
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.
12 years ago
Assignee: nobody → roc
rather trivial patch.
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?
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: 12 years ago
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]
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.