Closed Bug 47872 Opened 26 years ago Closed 25 years ago

Clicking on JS links which call selectTrim() and nextPage() has no effect

Categories

(Core :: DOM: Core & HTML, defect, P3)

x86
Linux
defect

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: vanbalen, Assigned: jst)

References

()

Details

Bug found with Build 2000080404/Linux On http://www.honda.com, an attempt to "customize" a car will cause mozilla to exponentially increase its memory useage (goes from ~14 to above 30 according to top). The only thing out of the ordinary that I can see on the Jscript on that page is a call to setTimeout which is present in the offending JS functions: E.g. var timer = null; ... ... timer = setTimeout("selectTrim('"+trimID+"')", 100); To reproduce, go to http://www.honda2000.com/models/accord_coupe/customize.html. Just loading the page will probably substantially increase mozilla's memory useage. Clicking on the links that call selectTrim (the LX, EX, etc links) or clicking on the "color" links, which calls the nextPage function will fail (you will only see a message like "Document: Done (0.043 secs)" but won't get the intended page) and will also substantially increase mem useage if clicked enough times. Note: NS 4.7 also has some trouble with this page. It usually works but is often very slow, causing system to come almost to a halt. It also caused NS to crash once. Appears to work fine with IE. I'll keep on looking at this and see if I can come up with a testcase but my JS experience is limited so that may take a while.
The URL http://www.honda2000.com/models/insight/customize.html exhibits the same increase in memory useage when it loads but doesn't seem to have any JS links with the same effect as on the other page. Moving on the another page (hitting the back button) appears to cause the extra memory to be freed. I also tried saving the pages and images and loading them from my maching and didn't experience the memory increase (the only thing that I didn't get the page to do on my local machine was the mouseovers on the colors)
Ok, sorry about the spam... The memory bloat on page-load is caused by the page http://www.honda2000.com/models/insight/top_customize.html which is the standard header the for problematic pages. I'm assuming that it's caused by the following code, but could be wrong: // load menu images //================== if (document.images) { menuImages = new Array(); menuImages_on = new Array(); for (i=1; i<numOfSections+1; i++) { menuImages[i] = new Image(); menuImages_on[i] = new Image(); menuImages[i].src = "/shared_images/menu"+i+".gif" menuImages_on[i].src = "/shared_images/menu"+i+"-stat.gif" } }
the problem with functions selectTrim and nextPage appear to be unrelated to the memory problem when loading top_customize.html. Should I split this bug?
Yes, please split bugs once symptoms seem to split according to different apparent causes. Feel free to cc: me on any new bugs split from this one. Thanks, /be
Changing summary since the bug description may be a little confusing. The memory usage problem is no longer a part of this bug...
Summary: JS doesn't work (possibly related to setTimeout) → Clicking on JS links which call selectTrim() and nextPage() has no effect
The only problem with selectTrim() and nextPage() I can see in PR2 is that they're never called, cliking on the javascript: URL never actually loads the javascript: URL, for some unknown reason... The good news is that after jokis huge "event-fixes-all-in-one" patch landed (a few days ago) the selectTrim() and nextPage() are called and the code works as expected AFAIK. So cusimizing a car is now closer to possible, the remaining problems ARAIK is that honda.com relies on document.layers and because of that the site doesn't work properly (check the JavaScript console)... Marking this FIXED.
Status: UNCONFIRMED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
This still doesn't work *at all* on 2000081105/Linux. Is this due to the layers problem?
Hmm, seems like this broke again, I swear it worked, I was able to select what type of Honda Accord Coupe I wanted, and it took me to the next stage in the customization, looks like the javascript: links aren't evecuted any more... Reopening....
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Page was updated on site and URL became "obsolete." Updating URL.
The bug also appears to have been fixed because the functions that were giving trouble are no longer there. Go figure... Changing URL, yet again, to CR-V customizations page which still uses those functions (for now, anyway).
setting bug status to New.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This bug has been marked "future" because the original netscape engineer workingon this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Testcasae is gone, again. Markign WORKSFORME since I can't find a page that shows this problem any more, unfortunately.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → WORKSFORME
Just stumbled across the code for this... apparently I saved it and then forgot. As far as I can tell, this bug no longer exists but I could only test the nextPage() function since I don't have honda's car.cgi program. If you would like to see the page, I've changed the URL to where I found it. The links for the nextPage() function are the broken images in the middle of the page which, when I click on them, cause browser activity.
You need to log in before you can comment on or make changes to this bug.