Moving mouse over links at abcnews.com freezes browser

VERIFIED FIXED in M14

Status

()

Core
Event Handling
P3
critical
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: shrirang khanzode, Assigned: joki (gone))

Tracking

({crash, top100})

Trunk
crash, top100
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] w/b minus on 3/10, URL)

Attachments

(4 attachments)

(Reporter)

Description

18 years ago
Pls reassign to correct component if incorrect. Thnx !

I see this on today's commercial build on all platforms (2000022808m15)

To recreate the problem, please do the following:

1. Install and launch hte browser
2. Type the url 'www.abcnews.com' in the Locationbox and press ENTER
3. Observe the page loads up
4. Now just move the mouse over the links in the left frame( with blue    		  
background). 
5. Observe that the browser freezes and no links work.

Comment 1

18 years ago
Same here - with: 2000022908, win98
A cut from the code of this page in the area of the problem:
http://www.geckonnection.com/testcases/testlinks.html
- start moving the mouse slowly over the links
- then, move DeSpErAtElY! over the links and see that performance goes down...


Comment 2

18 years ago
New testcase -->
http://www.geckonnection.com/testcases/testlinks1.html

Note: NOT FREEZING anymore here (2000022908), I cut the <font....> tags from the 
file. 
(Reporter)

Comment 3

18 years ago
Yup, I see this too..
Marking crash and top100 and beta1 and m14. Setting severity critical. 
Freezing/crashing on home page of a top100 site is serious.
Severity: major → critical
Keywords: beta1, crash, top100
Summary: Moving mouse over links freezes browser → Moving mouse over links at abcnews.com freezes browser
Target Milestone: M14

Comment 5

18 years ago
[PDT+] w/b minus on 3/10
Whiteboard: [PDT+] w/b minus on 3/10
(Assignee)

Comment 6

18 years ago
Hmm.  Trying to decide if this is a dupe of 18539 that we closed a long time 
ago.  Its still abcnews but that test case still seems to work.  Useful info 
though.
Status: NEW → ASSIGNED
(Assignee)

Comment 7

18 years ago
Created attachment 6298 [details]
somewhat narrowed down testcase

Comment 8

18 years ago
Created attachment 6307 [details]
A clearer test case...

Comment 9

18 years ago
Created attachment 6308 [details]
Yet another one...
(Assignee)

Comment 10

18 years ago
Okay weird, the test case at the bottom works (as in fails) for me on the server 
but no locally.  Fun.  Gonna put up a smaller testcase to check this out.
(Assignee)

Comment 11

18 years ago
Created attachment 6313 [details]
Test case 6308 with 3 instead of 10 elements for easier study
(Assignee)

Comment 12

18 years ago
Okay, got a fix.  Need to get a review and checkin authorization
Whiteboard: [PDT+] w/b minus on 3/10 → [PDT+] fix in hand, w/b minus on 3/10
(Assignee)

Comment 13

18 years ago
Harish, by the way.  I found that the parser is most definitely not to blame 
here.  It's definitely a lower level frame issue.  I managed to create identical 
content trees, both of which recursively nested the content nodes, one of which 
showed the freezing problem, one of which did not.
If you're curious, this seems to work OK on my current tree (with all my event
targetting changes that I'm waiting until after beta1 to check in).  Not that
that will help much...
(Assignee)

Comment 15

18 years ago
*** Bug 24352 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 16

18 years ago
Okay, this should be much better now.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] fix in hand, w/b minus on 3/10 → [PDT+] w/b minus on 3/10

Comment 17

18 years ago
Verified
WinNT, Win98:  2000-03-13-18-M15-nb1b
Mac: 2000-03-13-17-M15-nb1b

Linux: build not working - will verify later

Updated

18 years ago
Keywords: verifyme

Comment 18

18 years ago
verified on linux too
Status: RESOLVED → VERIFIED

Updated

9 years ago
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.