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.
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?
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 email@example.com
Updating QA Contact.
reopening and marking Future...
reassigning to core layout
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA contact updated
Build reassigning Buster's bugs to Marc.
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 ***