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)
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?
Comment 4•26 years ago
|
||
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
| Assignee | ||
Comment 6•26 years ago
|
||
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?
| Assignee | ||
Comment 8•26 years ago
|
||
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.
| Reporter | ||
Comment 10•26 years ago
|
||
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).
| Assignee | ||
Comment 12•26 years ago
|
||
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
| Assignee | ||
Comment 13•25 years ago
|
||
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
| Reporter | ||
Comment 14•25 years ago
|
||
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.
| Reporter | ||
Comment 15•25 years ago
|
||
oops... screwed up URL.
You need to log in
before you can comment on or make changes to this bug.
Description
•