Closed
Bug 54892
Opened 24 years ago
Closed 24 years ago
browser hangs when loading reuters.com
Categories
(Core :: DOM: Core & HTML, defect, P1)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
mozilla0.6
People
(Reporter: blizzard, Assigned: jst)
References
()
Details
(Keywords: crash, regression, top100, Whiteboard: [rtm++][HAVE FIX]sr=vidur)
Attachments
(5 files)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20001001
BuildID: 2000100121
Mozilla will hang when loading www.reuters.com. The window does not refresh and
the CPU it pegs the CPU up to 100%.
Reproducible: Always
Steps to Reproduce:
Load http://www.reuters.com.
Actual Results: Browser hangs.
Expected Results: Page should load.
|
||
Comment 4•24 years ago
|
||
|
|
||
Comment 5•24 years ago
|
||
...seems like we're running into the HTTP stream or server listener bug here.
At least that's what my MacsBug log suggests.
Mozilla build 2000100208-M18, iMac DV, Mac OS 9.0.4.
|
||
Comment 6•24 years ago
|
||
cc: gagan. Gagan, is this a networking issue?
|
||
Comment 7•24 years ago
|
||
nsGenericHTMLElement::GetOffsetRect layout maybe.
Assignee: asa → clayton
Component: Browser-General → Layout
QA Contact: doronr → petersen
|
||
Comment 8•24 years ago
|
||
The page contains a script based on the Layer tag that is no longer supported
but, I agree, we shouldn't hang because of that.
Look at the reduced testcase below. When we have an image called "myImage", we
fall into an infinite loop in getRealLeft() because 'tempEl' first contains
"HTMLBodyElement" but then 'tempEl.offsetParent' keeps returning
"HTMLHtmlElement". Apparently the script expects 'tempEl.offsetParent' to return
'null' when there is no parent (ie when we are in the HTMLHtmlElement).
Reassigned to DOM Level 1.
Note: I patched the script to break the loop after a few iterations but then I
got a crash in HTMLContentSink::ProcessSCRIPTTag(). I'm going to attach a log
file. I did not investigate any further but it means that after fixing
'offsetParent', you may encounter the same crash.
------------------------------------------------------------------------------
<!doctype html public "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Reuters</title>
<script language="JavaScript">
<!-- //Position Layers
var strmyimage = "myImage"
function getRealLeft(imgElem) {
xPos = eval(imgElem).offsetLeft
tempEl = eval(imgElem).offsetParent
while (tempEl != null) {
xPos += tempEl.offsetLeft
tempEl = tempEl.offsetParent
}
return xPos
}
function getCoordinateX(){
theXpos=getRealLeft(document.images[strmyimage])
return theXpos
}
//-->
</script>
</head>
<body bgcolor="#FFFFFF">
<p>Hello World Wide Web</p>
<img src="foo.gif" name="myImage">
<img src="foo.gif">
<script language="JavaScript">
<!--
getCoordinateX()
//-->
</script>
</body>
</html>
Assignee: clayton → jst
Component: Layout → DOM Level 1
QA Contact: petersen → janc
|
|
||
Comment 9•24 years ago
|
||
|
|
||
Comment 10•24 years ago
|
||
|
||
Comment 11•24 years ago
|
||
*** Bug 55370 has been marked as a duplicate of this bug. ***
|
|
||
Comment 13•24 years ago
|
||
|
|
||
Updated•24 years ago
|
Priority: P3 → P1
|
Assignee | |
Comment 14•24 years ago
|
||
|
|
Assignee | |
Comment 15•24 years ago
|
||
The attahced fix fixes the problem, the fix is a lowrisk fix that makes the
.offsetParent work as it does in IE 5.
PDT, this is a lowrisk fix that fixes a highly traficed site, this is IMO worth
any possible risk involved in fixing this.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.6
|
|
||
Comment 16•24 years ago
|
||
r=pierre
|
||
Comment 17•24 years ago
|
||
Marking rtm need info. Johnny, can you get a super-reviewer for this patch,
please? Please ping me once that happens and I'll mark this rtm+.
Whiteboard: [rtm need info]
|
||
Comment 18•24 years ago
|
||
sr=vidur. The point of this feature in the first place was to exactly match IE
behavior. This is a safe, localized fix that should go in.
|
|
Assignee | |
Updated•24 years ago
|
Whiteboard: [rtm need info] → [rtm+][HAVE FIX]sr=vidur
|
||
Comment 19•24 years ago
|
||
marking rtm++
Whiteboard: [rtm+][HAVE FIX]sr=vidur → [rtm++][HAVE FIX]sr=vidur
|
|
Assignee | |
Comment 20•24 years ago
|
||
*** Bug 54151 has been marked as a duplicate of this bug. ***
|
|
Assignee | |
Comment 21•24 years ago
|
||
I just landed the fix for this on both the trunk and the branch. Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Verified fixed on branch with today's Linux and NT debug builds.
Keywords: vtrunk
|
|
||
Comment 23•24 years ago
|
||
Verified Fixed on Mozilla trunk builds, Bothee the URL and the 10/05 testcase work.
linux 102608 RedHat 6.2
win32 102604 NT 4
mac 102608 Mac OS9
Setting bug to Verified and removing vtrunk keyword
Status: RESOLVED → VERIFIED
Keywords: vtrunk
|
||
Comment 24•11 years ago
|
||
Can someone verify if the freeze when visiting following page is connected to this bug or should I open a new one?
http://www.reuters.com/article/2011/06/03/us-paypal-china-idUSTRE75225520110603
Flags: needinfo?(jst)
|
|
Assignee | |
Comment 25•10 years ago
|
||
If you're still seeing a freeze on that page (I don't) I would file a new bug. Thanks.
Flags: needinfo?(jst)
|
||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•