Closed
Bug 12713
Opened 26 years ago
Closed 22 years ago
mouse over optimizations...
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P5)
Core
DOM: UI Events & Focus Handling
Tracking
()
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.
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.
Updated•26 years ago
|
Component: other → Event Handling
Hardware: PC → All
Target Milestone: M14
Comment 2•26 years ago
|
||
change component to Event Handling; set to M14 (post-beta) based on priority
Comment 3•26 years ago
|
||
cc waterson since this is a performance issue
Updated•26 years ago
|
Assignee: joki → rods
Comment 4•26 years ago
|
||
Taking this from Tom, at Tom's request
Comment 5•26 years ago
|
||
As stated above, knowing when to clear the cached value will be the trick. Do we override SetHTMLAttribute from the nsIHTMLContent interface?
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → LATER
Updated•25 years ago
|
Whiteboard: HELP WANTED
Comment 6•25 years ago
|
||
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
Comment 7•25 years ago
|
||
There's also nsIDOMElement::setAttribute() to worry about.
Comment 9•25 years ago
|
||
Mass update: changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
Comment 11•24 years ago
|
||
reopening and marking Future...
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Target Milestone: M14 → Future
Comment 13•24 years ago
|
||
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
Updated•24 years ago
|
Keywords: helpwanted
Whiteboard: HELP WANTED
Updated•23 years ago
|
QA Contact: madhur → rakeshmishra
Updated•22 years ago
|
QA Contact: rakeshmishra → trix
Comment 16•22 years ago
|
||
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 ago → 22 years ago
Resolution: --- → DUPLICATE
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•