Trying to display the given URL doesn't work.

RESOLVED WONTFIX

Status

()

Core
Document Navigation
RESOLVED WONTFIX
17 years ago
17 years ago

People

(Reporter: Rich Burridge, Assigned: Adam Lock)

Tracking

Trunk
mozilla0.9.1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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

17 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

17 years ago
Created attachment 28604 [details]
Linux stack trace after interrupting the page load
(Assignee)

Comment 3

17 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
(Assignee)

Comment 4

17 years ago
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. 
(Assignee)

Comment 6

17 years ago
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
(Assignee)

Comment 8

17 years ago
Marking WONTFIX. Remove the history.go(0) in the code to avoid reloads.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
Replacing  the history.go(0) call with a location.reload() should work fine 
without causing a infinite loop.

Comment 10

17 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.