Closed Bug 12713 Opened 21 years ago Closed 17 years ago
mouse over optimizations
Currently we call NS_MakeAbsoluteURL for each mouse over links (including clicks) and sometimes more than once... Think there might be value in caching the resolved absolute URL for each link instead of constructing it again each time? There may be situations when DOM changes the anchor tag or something when we can flush this.
Brendan suggests that this should be computed just once during the layout and not on each mouse overs. Seems like a good idea to me.
Component: other → Event Handling
Hardware: PC → All
Target Milestone: M14
change component to Event Handling; set to M14 (post-beta) based on priority
cc waterson since this is a performance issue
Taking this from Tom, at Tom's request
As stated above, knowing when to clear the cached value will be the trick. Do we override SetHTMLAttribute from the nsIHTMLContent interface?
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → LATER
I am adding HELP WANTED to the status whiteboard. This is not really a caching situation -- it's more a matter of not recomputing something unnecessarily. The DOM has property setters that run when an attribute is assigned to via JS. The MozillaClassic code did MakeAbsolute there too, as well as when seeding the HREF value while loading the document. How hard is this? /be
There's also nsIDOMElement::setAttribute() to worry about.
Updating QA Contact
Mass update: changing qacontact to firstname.lastname@example.org
QA Contact: janc → ckritzer
Updating QA Contact.
QA Contact: ckritzer → lorca
reopening and marking Future...
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Target Milestone: M14 → Future
reassigning to core layout
Assignee: rods → buster
Status: REOPENED → NEW
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
QA contact updated
QA Contact: gerardok → madhur
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
I think the performance problem here was solved by bug 25963, although by caching the visited state of the resolved URL rather than the resolved URL itself (much less memory). I'm going to mark this as a duplicate. (After all, there haven't been any substantive comments in the bug since 1999-10-14, and we've done a lot of performance analysis since then.) *** This bug has been marked as a duplicate of 25963 ***
Status: NEW → RESOLVED
Closed: 20 years ago → 17 years ago
Resolution: --- → DUPLICATE
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.