Closed
Bug 73023
Opened 23 years ago
Closed 23 years ago
Trying to display the given URL doesn't work.
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
RESOLVED
WONTFIX
mozilla0.9.1
People
(Reporter: rich.burridge, Assigned: adamlock)
References
()
Details
Attachments
(1 file)
2.56 KB,
text/plain
|
Details |
With tip-of-the-trunk Mozilla, trying to display: http://infobase.informit.com/linux/content/bookframe.html?0789719274 doesn't work. It will loop on it and will never display the contents. Netscape 4.76 is slow but manages to show the page. Note that the single main frame (http://infobase.informit.com/linux/content/0789719274/) will display correctly. Disabling JavaScript in the browser, will allow the stuff at the bottom of the page to be fully drawn.
Comment 1•23 years ago
|
||
Browser, not engine. Reassigning to Embedding:Docshell for further triage. Confirming on WinNT, Linux with 2001-03-22 debug builds. OS Solaris --> All. On WinNT, I get this dialog over and over: ###!!! ASSERTION: The DocLoader is still busy... There is a bug in End Document notifications: '0';, file d:\mozilla\xpfe\browser\src\nsBrowserInstance.cpp, line 998
Assignee: rogerl → adamlock
Component: Javascript Engine → Embedding: Docshell
OS: Solaris → All
QA Contact: pschwartau → adamlock
Hardware: Sun → All
Comment 2•23 years ago
|
||
Probably the line that says "searchbar.history.go(0)" in the page source has something to do with it. CC'ing Radha.
Target Milestone: --- → mozilla0.9.1
I'm guessing that we should change session history so calling history.go(0) does nothing at all since it appears to be triggering an infinite loop - everytime history.go(0) is called which fires an onLoad event to the frameset which and calls open_book() which calls history.go(0) and so on. Full page source follows: <HTML> <HEAD> <TITLE>Linux Infobase</TITLE> <META http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <SCRIPT LANGUAGE="Javascript"> var curr_isbn = ""; function upd_isbn(new_isbn) { if (new_isbn.length > 10) { curr_isbn = new_isbn.substring(0, 10); } else { curr_isbn = new_isbn; } searchbar.history.go(0); bookcontent.location.replace(new_isbn); } function open_book() { calling_url = "" + location.href; incoming_url = calling_url.substring(calling_url.indexOf("?")+1, calling_url.length); if (incoming_url.charAt(0) == "/") { incoming_url = incoming_url.substring(1, incoming_url.length); } upd_isbn(incoming_url); } </SCRIPT> </HEAD> <FRAMESET border=0 frameborder="no" framespacing="0" rows="*,40" onLoad="open_book()"> <FRAME src="/linux/content/blank.html" marginwidth="0" marginheight="0" noresize name="bookcontent"> <FRAME src="/linux/content/searchbar.html" marginwidth="2" marginheight="2" noresize scrolling="NO" name="searchbar"> </FRAMESET> <NOFRAMES><BODY bgcolor="#FFFFFF"> </BODY></NOFRAMES> </HTML>
Comment 5•23 years ago
|
||
This bug displays the JS history mechanism that was changed for the 6.0 release. In the previous releases, each frame had its own history and anything like <framename>.history.go() would exercise only the local frame history. But for Netscape 6, for modularity reasons, we decided to let go of the frame specific history (which I guess was introduced in 3.0 release) and tie all history transactions in subframes to the main SH of the browser window. Therefore the search.history.go(0) which in the previous release would have affected just that frame now does a reload on the whole page and therefore the infinite loop. I think changing searchbar.history.go(0) to a searchbar.location.reload() which will trigger a reload only in that frame will fix the problem.
So what's the answer for this? Should this bug be marked WONTFIX, or do we need to consider making go(0) a no-op?
Comment 7•23 years ago
|
||
This should be a won't fix. Changing history.go(0) to a no-op will have bad side-effects
Marking WONTFIX. Remove the history.go(0) in the code to avoid reloads.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Comment 9•23 years ago
|
||
Replacing the history.go(0) call with a location.reload() should work fine without causing a infinite loop.
Comment 10•23 years ago
|
||
*** Bug 122811 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•