Selection changed notifications get fired on every mouse move, even when selection does not change

RESOLVED FIXED in M16

Status

()

Core
Selection
P3
normal
RESOLVED FIXED
18 years ago
18 years ago

People

(Reporter: Simon Fraser, Assigned: mjudge)

Tracking

({perf})

Trunk
All
Mac System 8.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
We appear to be firing selection changed notifications on every mouse move, even 
when the actual selection has not changed. I think we might be collapsing/
reexpanding the selection to the same place. This is inefficient.
(Reporter)

Comment 1

18 years ago
Perf.
Keywords: perf
Target Milestone: ---

Comment 2

18 years ago
M16 for now
Target Milestone: --- → M16
(Reporter)

Comment 3

18 years ago
We also call NotifySelectionListeners() way too often. It's called from 
nsDOMSelection::Extend(), and from nsRangeList::TakeFocus(), which itself calls 
nsDOMSelection::Extend().
(Assignee)

Comment 4

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

Comment 5

18 years ago
sfraser, is this fix to your satisfaction? I don't think this can be verified via 
black box means. Thanks! 
(Reporter)

Comment 6

18 years ago
Yes, I can tell this is fixed.

Comment 7

18 years ago
*SPAM*: Changing the QA contact of all open/resolved Selection bugs from 
elig@netscape.com to BlakeR1234@aol.com.  After the many great years of service 
Eli has given to Mozilla, it's time for him to move on; he has accepted a 
position at Eazel.  We'll be sad to see him go, and I'll do my best to fill his 
spot...
QA Contact: elig → BlakeR1234
You need to log in before you can comment on or make changes to this bug.