nsSelectionState::IsEqual compares only first range

VERIFIED FIXED in mozilla0.9.2

Status

()

P3
critical
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: hjtoi-bugzilla, Assigned: mozeditor)

Tracking

Trunk
mozilla0.9.2
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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));

Comment 1

18 years ago
assigning to jfrancis, he is the culprit
Assignee: beppe → jfrancis
Target Milestone: --- → M19
(Assignee)

Comment 2

18 years ago
doh
Status: NEW → ASSIGNED

Comment 3

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

Comment 4

18 years ago
PDT would like to know how this is impacts users before agreeing with the P2
priority.

Comment 5

18 years ago
any update?
Whiteboard: [nsbeta3+][p:2] → [nsbeta3+][p:2][need info]

Comment 6

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

Comment 7

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

Comment 8

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

Comment 11

18 years ago
moz 0.9
Whiteboard: [nsbeta3-][p:2][PDTP3]
Target Milestone: Future → mozilla0.9
(Assignee)

Comment 12

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

Updated

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

Comment 16

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

Comment 18

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

Comment 19

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