Closed
Bug 143398
Opened 23 years ago
Closed 18 years ago
Throbber does not stop when inner frame sets img src or iframe src via JS
Categories
(Core :: Layout: Images, Video, and HTML Frames, defect, P3)
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: a.garcia.urzainki, Assigned: john)
References
()
Details
(Keywords: testcase)
Attachments
(5 files)
With a frameset embedded within another frameset, if the onload method of the
embedded frameset attempts to change the location of one of its frames, the
browser doesn't stop loading the page. This bug doesn't allow to store the page
at the back button history.
Comment 1•23 years ago
|
||
Browser, not engine ---> HTML Frames
Assignee: rogerl → jkeiser
Component: JavaScript Engine → HTMLFrames
QA Contact: pschwartau → amar
Comment 2•23 years ago
|
||
After un-zip, run FramesetTop. This will open a trace window. Note two things,
one: the page loading indicator for this page never stops loading (the trace
window never stops loading, but that is done on purpose), two: the trace for
FramesetTop never is processed.
This is caused by using replace() in the middle frameset. To verify: go to
FramesetMiddle and comment out this line:
window.frames["middle02"].location.replace(url);.
Run again, and you will see that it all behaves correctly. In this example the
new page (page12.htm) is simple. In the actual application the page(asp) is set
with a number of parameters which could not easily be done any other way.
The actual application is a health entry system for the state of Washington. We
are finishing it up and attempting to get it to work under Netscape
6.2/Mozilla. For us, this is a biggie.
Thank you,
Chris Emerson
Comment 3•23 years ago
|
||
This doc should have been part of the html files uploaded by Emerson.
This doc merges the middle frameset and the top frameset. Each one has an onload
action. Note that when this is run only the lower level onload action occurs.
The onload event for the first frameset does not fire. (This is the same
behaviour seen in IE).
This implies one possible reason for this bug: the browser "sees" all of the
framesets as combined. In this case once it processed the lower level onload it
ignores any higher level onloads. Since the pages all load (the loading
indicator clears) this maybe a different issue.
Chris Emerson
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Frameset: top</title>
<script language=javascript src="test.js"></script>
<script type="text/javascript">
<!--
function loadPage ()
{
Trace("** ONLOAD: FramesetMiddle");
var url;
url = "page12.htm"
Trace("--replace page3 with page12--");
window.frames["middle02"].location.replace(url);
}
// -->
</script>
</head>
<frameset rows="100,*" onload="Trace('** ONLOAD: FramesetTopCombined');">
<frame src="page1.htm">
<frameset rows="100,*" onload="loadPage();">
<frame name = "middle01" src="page11.htm">
<frame name = "middle02" src="page3.htm">
</frameset>
</frameset>
</html>
Assignee | ||
Comment 4•23 years ago
|
||
Assignee | ||
Comment 5•23 years ago
|
||
This happens when the outer frame is an iframe as well. The problem is that
whenever you have a document-within-a-document and the inner one changes its
location during load, the loading throbber does not stop even though loading
has. This is not a problem with frameset-within-frameset; as was just pointed
out, if you put them in the same document everything works. The DocShell
boundary is the thing.
You can test the behavior it *should* have by clicking on "Testcase
innerframe". Since there is no outer document, the frame is replaced and the
throbber stops. But clicking on "Testcase", which has an iframe pointing to
"Testcase innerframe", fails the test.
One strange (but probably unrelated) thing is that the inner frameset does not
receive an onLoad event when the location of the inner frame is replaced. This
occurs, for example, when an iframe.src is set, making onLoad='this.src="..."'
a recursive event.
Is this causing functional problems with your application or is it just the
throbber? (I understand that's a real problem, just wondering if this is
having any deleterious effects on you data-wise.)
The functional problem is that it doesn't stop loading, and no pages are stored
as part of the history array. So no back button is working (Neither browser's
back button nor history.back() )
Could bug 139769 be related to this? If so, it's a problem -- it shows a
big-time memory leak on the current builds. If not, well, maybe not. :-)
Assignee | ||
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 153566 has been marked as a duplicate of this bug. ***
*** Bug 151600 has been marked as a duplicate of this bug. ***
Comment 10•23 years ago
|
||
*** Bug 152057 has been marked as a duplicate of this bug. ***
Comment 11•23 years ago
|
||
Please add any two pages as Page1.htm and Page2.htm. MainPage.html displays
alert message in Netscape Navigator 4.7 and IE 5.5. But it does not display the
message in Netscape Navigator 6.2.3.
Any workaround?
Comment 12•22 years ago
|
||
I can confirm the behavior reported by Comment #3 From Christopher Emerson.
In its example the onload-handler of the outer frameset will not
be invoked (this is also with InternetExplorer). But i could not reproduce
the endless loading problem. Thus i have made another test with
frames and onload-handler. The components are:
An outer frameset fs1.html:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>fs1</title>
<script type="text/javascript">
<!--
function init () {
alert("fs1:frameset:loading done!");
}
// -->
</script>
</head>
<frameset rows="*,*" onload="init();">
<frame src="page1.html">
<frame src="fs2.html">
</frameset>
</html>
An inner frameset fs2.html:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>fs2</title>
<script type="text/javascript">
<!--
function loadPage (){
var url;
url = "page3.html"
alert("replace page2 with page 3!");
window.frames["fs2_doc"].location.replace(url);
}
function init () {
alert("fs2:frameset:loading done!");
}
// -->
</script>
</head>
<frameset rows="*" onload="loadPage();init();">
<frame src="page2.html" name="fs2_doc">
</frameset>
</html>
And page1-4.html like:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>page1</title>
</head>
<body>
page 1
</body>
</html>
If you load the URL http://www.ep.haufe.de/~jiranek/test_frameset/fs1.html
the onload-handler of the inner frameset fs2.html will be invoked
and the page2 is replaced with page3 and the the handler is
finished. The onload-handler of the outer frameset will not be
invoked and Mozilla is loading endless. If you want to get the sources,
just use http://www.ep.haufe.de/~jiranek/test_frameset . My testing environment
is Win2000/Mozilla1.0.1. This expample works fine with InternetExplorer!
Comment 13•22 years ago
|
||
*** Bug 165962 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 14•22 years ago
|
||
OK. This also happens when the inner doc is a normal document that contains an
image, and the image's src gets set. The general problem is that the outer
document gets confused about whether it's done loading if JavaScript loads
resources in the inner document while loading.
Summary: Frameset and onload → Throbber does not stop when inner frame sets img src or iframe src via JS
Assignee | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Updated•22 years ago
|
Target Milestone: --- → Future
Comment 15•21 years ago
|
||
Below is the testcase from bug 166328, which now bug 217000 has been fixed,
seems to be displaying this problem. Yes?
<head><title>Testcase for bug 166328</title><meta http-equiv=Content-Type
content=text/html; charset=UTF-8></head>
<SCRIPT language=JavaScript>
function output_top_frame() {
top.title.document.writeln("Top Frame<BR>");
}
function output_bottom_frames() {
top.bottom.document.writeln("Bottom Frame<BR>");
}
</script>
<frameset rows="60,1*" border=1 framespacing=0 frameborder=0 framepadding=0
marginwidth=0 marginheight=0>
<frame src="javascript:top.output_top_frame();" marginheight=0 marginwidth=0
scrolling=no noresize frameborder=no name=title>
<frame src="javascript:top.output_bottom_frames();" marginheight=0 marginwidth=0
scrolling="no" name=bottom>
</frameset>
Comment 16•21 years ago
|
||
*** Bug 227055 has been marked as a duplicate of this bug. ***
Comment 17•21 years ago
|
||
*** Bug 235675 has been marked as a duplicate of this bug. ***
Comment 18•21 years ago
|
||
*** Bug 251655 has been marked as a duplicate of this bug. ***
Comment 19•21 years ago
|
||
*** Bug 178366 has been marked as a duplicate of this bug. ***
Comment 20•20 years ago
|
||
I've just encountered this problem too! Reproducible even in Mozilla 1.8a6. I
found that it seems only location.replace is affected. When I use location.href
= "" or src = "", there is no problem.
In fact, any kind of frames are affected. No matter it is a <frame>, <iframe> or
<object type="any text/XML MIME type">.
I'll put my simple test case here which involves two nested iframes.
Comment 21•20 years ago
|
||
After unzipping the file, open a.html.
a.html includes an iframe that points to b.html
b.html includes an iframe pointing to Yahoo, and will be "location.replace"d to
Google.
See how the throbber rolls like crazy when it finished loading. The stop button
doesn't work too. But apparently it has stopped loading any more file. Just
that the throbber goes crazy.
Comment 22•19 years ago
|
||
Is this what I'm seeing?
URL:
http://money.cnn.com/2005/09/28/pf/debt/delinquencies/index.htm?cnn=yes
iframe URL, according to Adblock:
http://cl.cnn.com/ctxtlink/jsp/money-story.jsp?domId=contextualLinks&time=1127923725394&origin=money&site=cnn_moncredit_dyn_ctxt&category=moneycredit&url=http://robots.cnnfn.com/2005/09/28/pf/debt/delinquencies/index.htm
Build:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20050928
Firefox/1.4 ID:2005092806
The tab's throbber never stops spinning even though the main throbber does and
the loading statusbar disappears from the bottom right corner of the window.
Having Adblock block "http://*.cnn.com/ctxtlink/*&url=*" to try to stop the
iframe from loading doesn't fix it.
Comment 23•18 years ago
|
||
This bug still exists in both XHTML and HTML framed pages.
The only solution i've found can be achieved with the following JavaScript code AFTER the occurred event (any event that modified the DOM tree).
self.document.close(); // the modified DOM
top.document.close(); // the parent frameset page
NOTE: this will NOT work for XHTML pages that include the application/xhtml+xml since the DOM has no such thing as document.close() (write to document)
Comment 24•18 years ago
|
||
Here's one that also works with XHTML, use at own risk though.
try { // firefox frameset bug
top.document.close();
self.document.close();
} catch (e) { // self. fails using xhtml
setTimeout(function(){ top.stop(); }, 5000);
}
Comment 25•18 years ago
|
||
Fixed by checkin for bug 315056.
Comment 26•17 years ago
|
||
Is this bug supposed to be fixed in Firefox 2.x? I still have it in Firefox 2.0.0.9 but not in Firefox 3.0b1.
Comment 27•17 years ago
|
||
This was fixed by the patch from bug 315056, which was checked in at 2006-10-18.
That means it went into the trunk, not on branch.
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•