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)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
mozilla0.9.1

People

(Reporter: rich.burridge, Assigned: adamlock)

References

()

Details

Attachments

(1 file)

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.
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
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>
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?
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
Replacing  the history.go(0) call with a location.reload() should work fine 
without causing a infinite loop.
*** 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.

Attachment

General

Creator:
Created:
Updated:
Size: