Closed Bug 55172 Opened 24 years ago Closed 20 years ago

davidrumsey.com - javascript does not seem to work

Categories

(Tech Evangelism Graveyard :: English US, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: jefu, Unassigned)

References

()

Details

(Whiteboard: TYPO IN NAME OF JS FILE BELOW; SEE COMMENT 9 [aok])

Attachments

(2 files)

The javascript on this page does not seem to be rendered by mozilla
in any useful way.  It seems to work in IE ok.  It looks like lots of
javascript to me and I'm not anywhere near qualified to evaluate it
and determine if the fault is the page authors or mozillas.
This Web page has a complicated structure. I will attach four of the files 
it uses. It is not a complete list, but enough to get an idea of what is 
going on: 


http://www.davidrumsey.com/launcher.asp


http://www.luna-imaging.com/browser2/start.asp?collection=4
&cname=Rumsey&browser=NS47&platform=Win32&d=0&w=1280


http://www.luna-imaging.com/browser2/js/utils.js


http://www.luna-imaging.com/browser2/asp/global.asp?collection=4
&cname=Rumsey&d=0

Summary: javascript does not seem to work → javascript does not seem to work
I will refer to the four files as:

launcher.asp 
start.asp
utils.js
global.asp.


Launcher.asp sniffs the OS and the browser, and constructs the URL arguments
for start.asp. The URL I gave above is what gets constructed on WinNT, as you 
can see in "platform=Win32". The browser parameter gets set to "NS47" 
regardless of whether you use NN4.7 or Mozilla/N6.



The onLoad event of Launcher.asp is a function "transfer()" : 

function transfer () {
   location.replace("javascript:Go(4, 'Rumsey', 0);void(0);");
}


The function Go(x, y, d) is what constructs the URL&arguments for start.asp.


Start.asp contains nested <FRAMSET> tags which lie outside of any <HMTL> tags.
Is this legal??? 


There are ten or so frames within these nested framesets, and they
get initially get populated by a blank dark backgound ("nothing.html").
The function Go(x) within start.asp populates these frames dynamically.
This function is initially called with x=0 from the frame named "menu".


You can see the HTML for this frame at

          http://www.luna-imaging.com/browser2/lnf/menu.asp

It contains this <BODY> tag:

          <BODY link=white vlink=white onLoad="top.Go(0)";>


The function Go(x) in start.asp contains a switch case statment beginning: 


switch (x)
{

case 0:
   top.global.location=pba + "asp/global.asp?collection=4&cname=Rumsey&d=0";
   break;

case 1:
   top.gwtop.location=pba +  etc. etc. 



So global.asp gets loaded by case 0 above. But global.asp contains this <BODY> 
tag:

          <BODY bgcolor=gold onLoad="top.Go(1);">


Go the Go(x) function in start.asp gets called again and again,
until all the frames are dynamically populated.



Because of the dynamic loading of frames within framesets, I believe
this bug may be a duplicate of bug 53708, "links loads wrong page into frame /
link doesn't load page.", which has recently been fixed on the 
MN6 branch and Mozilla trunk, I believe, as of 2000-10-11.  


Reassigning to HTML Frames component. Changing OS to "All"
Reporter, could you try the original URL with a pull after Oct.11
and see if the problem is still occurring? 


Note: it looks like on WinNT,the HTML at the site may have some problems 
with browser-sniffing. it told me that NN4.7 on my WinNT needed to be 
upgraded to NN4.0 or higher" (!) I had to break up the HTML as above to see 
the problem as originally reported.


Also, you may note an error in the JavaScript console, as follows:

          "LoadingWindow.document.li. has no properties"


I was not able to track that down. What it usually means is an invalid
reference to something on a Web page that has id="li". The proper way 
to access that in a W3C-compliant browser is NOT by document.li but
by document.getElementById("li"). That is a DOM issue, not JS Engine.
Compare bug 45940, comment 2000-07-20 20:14.


Anyway, I was never able to see where "li" was ever defined. But errors
like this are enough to stop the rest of the JavaScript from executing.
Mozilla and Nav6 differ from Nav4 and earlier because they catch syntax 
errors before binding functions, or even compiling code for them.  
This is within the ECMA-262 spec. 


If that is the ultimate cause of this bug, it should be sent to the 
Evangelism component so the Web author can be notified of the issue.
Assignee: rogerl → pollmann
Status: UNCONFIRMED → NEW
Component: Javascript Engine → HTMLFrames
Ever confirmed: true
OS: Linux → All
QA Contact: pschwartau → petersen
I guess I'm "reporter" - this bug recurred with yesterday's build (2000101609)
and worse - out of five visits to the page, three resulted in mozilla crashing.
 The other two just didnt work.

That's interesting that you crash. I have never crashed at the site. 
Jeff, what OS are you running on?
I'm running RedHat 6.2.

There may well have been other factors - each time it crashed I had been looking
at other sites, left my office for a while and came back - got reminded to look
at that site and went there.  I don't know what other sites I was visiting before
the crash occurred.

The times it did not crash, I started mozilla (usually right after a crash) and
checked the site.  
NOTE THERE IS A TYPO ABOVE! THE JS FILE I MENTIONED SHOULD HAVE BEEN :

     http://www.luna-imaging.com/browser2/js/utility.js

NOT "utils.js" !!! This JS file contains the Dialog() function 
that start.asp uses. Dialog() is just a wrapper for window.open(),
and it is used to bring up the splash screen of the web site.


I have located the HTML element 'li' referred to in the JavaScript 
error above. It is a <DIV> element in the splash screen,
 
      http://www.luna-imaging.com/browser2/lnf/loading.asp


This contains 11 <IMG> elements, corresponding to the x-values 0, 1, ..., 10  
in the Go(x) function above. Each time Go(x) is called as another frame loads, 
the next "box" in the splash screen gets filled.


Here is (most of) the HTML for the splash screen loading.asp:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>
<head>
        <title>Loading Insight...</title>
<style>
.loadingimages
{
        position:absolute;
        top:215px;
        left:10px;
}
.loadingtext
{
        position:absolute;
        color:silver;
        top:200px;
        left:10px;
        font-family:Arial,Helvetica,Geneva,Helv;
        font-size:10px;
}
</style>

</head>


<body bgcolor="#000000" background="">


<div id='li' class='loadingimages'>
     <img name="p0" src="" width=10 height=11 border=0><img name="p1"  ETC. ETC. 
</div>

<div id='lt' class='loadingtext'>Loading Insight...</div>

</body>
</html>



The <DIV> element 'li' gets called by the Go(x) function  as follows: 

      LoadingWindow.document.li.document.images[x].src=
      "http://www.luna-imaging.com/browser2/Lnf/images/rumsey/progresson.jpg";


However, as mentioned above, we no longer support the syntax "document.li" 
to access an HTML element with  id='li'. In a W3C-compliant browser like 
NN6/Mozilla, you have to use document.getElementByID('li') instead . 


So the HTML at this site needs to be upgraded to work in W3C browsers.
For references, see bugs mentioned above. Reassigning to Evangelism component -


Jeff's continuing problems with the site show it wasn't bug 53708.
Thank you for this report, and Jesse, thank you for the good idea above -
Assignee: pollmann → blakeross
Component: HTMLFrames → Evangelism
QA Contact: petersen → zach
Whiteboard: NOTE TYPO IN NAME OF JS FILE BELOW; SEE 2000-10-18 14:44
-> evangelism@telocity.com for my evangelism bugs.

removing the now-depreciated evangelism-related keywords.

setting platform to All.
Assignee: blakeross → evangelism
Hardware: PC → All
Reassigning evangelism bugs to bclary@netscape.com.
Assignee: evangelism → bclary
Summary: javascript does not seem to work → davidrumsey.com - javascript does not seem to work
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
details.
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified
Whiteboard: NOTE TYPO IN NAME OF JS FILE BELOW; SEE 2000-10-18 14:44 → NOTE TYPO IN NAME OF JS FILE BELOW; SEE 2000-10-18 14:44[aok]
Mass reassign of all tech-evangelism us general bugs assigned to bc to 
doron except bc's P1 bugs. You may search for this mass reassign (it is 
305 bugs) by searching for the keyword 'greeneggsandham'
Assignee: bclary → doronr
Whiteboard: NOTE TYPO IN NAME OF JS FILE BELOW; SEE 2000-10-18 14:44[aok] → TYPO IN NAME OF JS FILE BELOW; SEE COMMENT 9 [aok]
Depends on: 117933
tech evang june 2003 reorg
Assignee: doron → english-us
QA Contact: zach → english-us
No js error, no problem, site states that it supports Mozilla, marking WFM
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: