Closed Bug 51923 Opened 24 years ago Closed 23 years ago

nsSelectionState::IsEqual compares only first range

Categories

(Core :: DOM: Editor, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.2

People

(Reporter: hjtoi-bugzilla, Assigned: mozeditor)

Details

Attachments

(1 file)

We have a for loop for the ranges, but we only compare the items at index 0!

257   for (i=0; i<myCount; i++)
258   {
259     myItem = (nsRangeStore*)mArray.ElementAt(0);
260     itsItem = (nsRangeStore*)(aSelState->mArray.ElementAt(0));
assigning to jfrancis, he is the culprit
Assignee: beppe → jfrancis
Target Milestone: --- → M19
doh
Status: NEW → ASSIGNED
ranges are based on when the user makes a selection in determining 'range' of
the selection, must be fixed
Severity: normal → critical
Keywords: nsbeta3, perf
Priority: P3 → P2
Whiteboard: [nsbeta3+][p:2]
PDT would like to know how this is impacts users before agreeing with the P2
priority.
any update?
Whiteboard: [nsbeta3+][p:2] → [nsbeta3+][p:2][need info]
It sure looks like a bug in the code... but without an UI impact listed in the
bug, it is not a P2.
Adding PDTP3 and lowering priority to P3.
Priority: P2 → P3
Whiteboard: [nsbeta3+][p:2][need info] → [nsbeta3+][p:2][PDTP3]
marking nsbeta3-, setting to future. PDT marked this as p4, which is below the
nsbeta3/rtm cutoff. if you disagree with this decision, then appeal to
pdt@netscape.com, giving the bug #, your compelling agrument and request to
reconsider.
Whiteboard: [nsbeta3+][p:2][PDTP3] → [nsbeta3-][p:2][PDTP3]
someone moved this back to m19, moving back to future
Target Milestone: M19 → Future
What are the performance effects of this, exactly?  It's not clear to me from
reading the bug, or the code.
It looks like beppe added the perf keyword. I think it is bogus, removing.
Keywords: perf
moz 0.9
Whiteboard: [nsbeta3-][p:2][PDTP3]
Target Milestone: Future → mozilla0.9
moving a bunch of 0.9 bugs to 0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
By the way, this bug is only about changing "0" to "i" in two places... ;) 
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Argh! This isn't too difficult, is it? I have provided a fix, could I get
reviews? I can even check it in for you once I get reviews, if you want (just
reassign...)
Keywords: approval, review
don't pay attention to the milestone.  I just had to dump my bugs into .92 to 
appease the gods.  It has no relation to the checkin date at all.
jfrancis: who is forcing you to dump your bugs into a particular milestone?  Why
not leave the ones you aren't planning to fix in the next milestone untargeted
(---)? In this case, of course, heikki wants to see a 0.9.1, since he's provided
a patch already.

/be
fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Heikki, please verify fix and mark VERIFIED-FIXED...thanks.
I looked at LXR and saw that it was fixed. Verifying. Thanks.
Status: RESOLVED → VERIFIED
Keywords: approval, review
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: