Closed Bug 12713 Opened 26 years ago Closed 22 years ago

mouse over optimizations...

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P5)

defect

Tracking

()

RESOLVED DUPLICATE of bug 25963
Future

People

(Reporter: gagan, Assigned: attinasi)

Details

(Keywords: helpwanted, verifyme)

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.
Severity: normal → minor
Priority: P3 → P5
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
Assignee: joki → rods
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: 25 years ago
Resolution: --- → LATER
Whiteboard: HELP WANTED
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.
QA Contact: leger → janc
Updating QA Contact
Keywords: verifyme
Mass update:  changing qacontact to ckritzer@netscape.com
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
Keywords: helpwanted
Whiteboard: HELP WANTED
QA contact updated
QA Contact: gerardok → madhur
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
QA Contact: madhur → rakeshmishra
QA Contact: rakeshmishra → trix
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: 25 years ago22 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.