Closed Bug 227055 Opened 21 years ago Closed 21 years ago

throbber doesn't stop if i access this sample...

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 143398

People

(Reporter: bhaskarna, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 

I used following testcase to reproduce the problem in netscape 7 on windows, 
same can be reproduced in other platforms and mozilla also.

Have a html(throb.html) with framset and a single frame whose src should point 
to another html(mail.html). mail.html should have a framset and a frame whose 
src should point to dummy html (dummy.html). In mail.html, frameset's onload 
event should assign some response from some url to frame.window.href.
If I access mail.html browser will not loop. But if I access mail.html thru a 
frame (thru throb.html) then browser goes for infinite loop. 

Reproducible: Always

Steps to Reproduce:
Have the following html's in your docroot.
Here is the source code listing of all html's:
**********************************************
throb.html:
***********

<html>
<head>

<script>
function  close() {
 alert('Loaded');
}
</script>

<frameset onload="close()">
<frame src="http://duck:85/search/mail.html">
</frameset>
</head>
</html>

mail.html
*********
<html>
<head>
<script>
function load() {
 fr.location.href = "http://duck:85/search/advanced";
}
document.write('<frameset rows="0" onLoad="load()">' +
 '<frame name="fr" src="dummy.html">');

</script>
</head>
</html>

//note that: "http://duck:85/search/advanced" is a hello world kind of servlet 
for which i am not including any src code because it is just 1 line code in 
doGet method which does out.println("helloworld"). And people can try with any 
url(which gives back some html response instead of using the url which i am 
using here ex., http://www.sun.com) 

dummy.html:
***********
<html>
</html> 
Actual Results:  
throbber doesn't stop

Expected Results:  
throbber should stop when all documents are loaded

If my html syntax is correct then it looks like there is problem in mozilla 
browser if in rendering the nested frames
Severity: critical → normal
Please observe that the 1.0.2 code base is too old to report bugs on.

> same can be reproduced in other platforms and mozilla also.

Which platforms and which Mozilla versions?
Does the problem occur with Mozilla 1.6a?
other browsers where I am able reproduce:
1. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 
Netscape/7.1 (ax)

2. Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1) Gecko/20030711
Severity: normal → critical
Component: Browser-General → HTML: Parser
This is not a Parser problem and it is not critical (please don't change that
again).

It could be a duplicate of bug 227087
Severity: critical → normal
Component: HTML: Parser → Browser-General
Reproduced in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030
This bug should get higher priority and need a fix or workaround because Sun is 
recommending mozilla/netscape browser for the communication products like 
webmail calendar and addressbook and also sun ships netscape browser in SunOS. 
Now this problem is showstopper issue for the beta drop because it looks ugly 
if throbber keep rotating even when all documents downloaded.
We don't have this issue in IE.
This bug is there in latest mozilla browser(1.6a). If we don't get any 
workaround or fix for this in mozilla browser before our beta drop (8th Dec 
2003) then we are going to release note this bug. This biases 
endusers/customers to shift to IE.

So, request bugcouncil to increase the priority for this bug. 
I agree with Mats, there's a good chance that this is a duplicate of bug 227087
(or bug 143398, which may be the same thing).

Also, severity doesn't have a whole lot to do with how resources are devoted to
a bug. If you read http://bugzilla.mozilla.org/bug_status.html#severity, you can
see "critical" bugs are specifically reserved for crashes or dataloss issues.

*** This bug has been marked as a duplicate of 143398 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.