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)
Tech Evangelism Graveyard
English US
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.
Comment 1•24 years ago
|
||
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
Comment 2•24 years ago
|
||
Comment 3•24 years ago
|
||
Comment 4•24 years ago
|
||
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
Reporter | ||
Comment 5•24 years ago
|
||
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.
Comment 6•24 years ago
|
||
That's interesting that you crash. I have never crashed at the site. Jeff, what OS are you running on?
Reporter | ||
Comment 7•24 years ago
|
||
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.
Comment 8•24 years ago
|
||
Check out attachment http://bugzilla.mozilla.org/showattachment.cgi?attach_id=17447 on bug 55240.
Comment 9•24 years ago
|
||
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
Updated•24 years ago
|
Whiteboard: NOTE TYPO IN NAME OF JS FILE BELOW; SEE 2000-10-18 14:44
Comment 10•24 years ago
|
||
-> evangelism@telocity.com for my evangelism bugs. removing the now-depreciated evangelism-related keywords. setting platform to All.
Assignee: blakeross → evangelism
Hardware: PC → All
Comment 11•23 years ago
|
||
Reassigning evangelism bugs to bclary@netscape.com.
Assignee: evangelism → bclary
Updated•23 years ago
|
Summary: javascript does not seem to work → davidrumsey.com - javascript does not seem to work
Comment 12•23 years ago
|
||
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
Updated•23 years ago
|
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]
Comment 13•23 years ago
|
||
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
Updated•22 years ago
|
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]
Comment 14•21 years ago
|
||
tech evang june 2003 reorg
Assignee: doron → english-us
QA Contact: zach → english-us
Comment 15•20 years ago
|
||
No js error, no problem, site states that it supports Mozilla, marking WFM
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Updated•9 years ago
|
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•