If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

mouse over optimizations...

RESOLVED DUPLICATE of bug 25963

Status

()

Core
Event Handling
P5
minor
RESOLVED DUPLICATE of bug 25963
18 years ago
15 years ago

People

(Reporter: Gagan, Assigned: Marc Attinasi)

Tracking

({helpwanted, verifyme})

Trunk
Future
helpwanted, verifyme
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
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.
(Reporter)

Updated

18 years ago
Severity: normal → minor
Priority: P3 → P5
(Reporter)

Comment 1

18 years ago
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

18 years ago
Component: other → Event Handling
Hardware: PC → All
Target Milestone: M14

Comment 2

18 years ago
change component to Event Handling; set to M14 (post-beta) based on priority

Comment 3

18 years ago
cc waterson since this is a performance issue

Updated

18 years ago
Assignee: joki → rods

Comment 4

18 years ago
Taking this from Tom, at Tom's request

Comment 5

18 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

18 years ago
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → LATER

Updated

18 years ago
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

Comment 7

18 years ago
There's also nsIDOMElement::setAttribute() to worry about.

Updated

18 years ago
QA Contact: leger → janc

Comment 8

18 years ago
Updating QA Contact

Updated

18 years ago
Keywords: verifyme

Comment 9

17 years ago
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer

Comment 10

17 years ago
Updating QA Contact.
QA Contact: ckritzer → lorca

Comment 11

17 years ago
reopening and marking Future...
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Target Milestone: M14 → Future

Comment 12

17 years ago
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

Updated

17 years ago
Keywords: helpwanted
Whiteboard: HELP WANTED

Comment 14

17 years ago
QA contact updated
QA Contact: gerardok → madhur
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi

Updated

16 years ago
QA Contact: madhur → rakeshmishra

Updated

15 years ago
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
Last Resolved: 18 years ago15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.