Closed Bug 429315 Opened 13 years ago Closed 13 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: 13 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: 13 years ago13 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
You need to log in before you can comment on or make changes to this bug.