Closed
Bug 51923
Opened 24 years ago
Closed 23 years ago
nsSelectionState::IsEqual compares only first range
Categories
(Core :: DOM: Editor, defect, P3)
Core
DOM: Editor
Tracking
()
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: hjtoi-bugzilla, Assigned: mozeditor)
Details
Attachments
(1 file)
714 bytes,
patch
|
Details | Diff | Splinter Review |
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•24 years ago
|
||
assigning to jfrancis, he is the culprit
Assignee: beppe → jfrancis
Target Milestone: --- → M19
Comment 3•24 years ago
|
||
ranges are based on when the user makes a selection in determining 'range' of the selection, must be fixed
Comment 4•24 years ago
|
||
PDT would like to know how this is impacts users before agreeing with the P2 priority.
Comment 6•24 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•24 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•24 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.
Reporter | ||
Comment 10•24 years ago
|
||
It looks like beppe added the perf keyword. I think it is bogus, removing.
Keywords: perf
Assignee | ||
Comment 11•24 years ago
|
||
moz 0.9
Whiteboard: [nsbeta3-][p:2][PDTP3]
Target Milestone: Future → mozilla0.9
Assignee | ||
Comment 12•24 years ago
|
||
moving a bunch of 0.9 bugs to 0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Reporter | ||
Comment 13•24 years ago
|
||
By the way, this bug is only about changing "0" to "i" in two places... ;)
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Reporter | ||
Comment 14•23 years ago
|
||
Reporter | ||
Comment 15•23 years ago
|
||
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...)
Assignee | ||
Comment 16•23 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.
Comment 17•23 years ago
|
||
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•23 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 19•23 years ago
|
||
Heikki, please verify fix and mark VERIFIED-FIXED...thanks.
Reporter | ||
Comment 20•23 years ago
|
||
I looked at LXR and saw that it was fixed. Verifying. Thanks.
You need to log in
before you can comment on or make changes to this bug.
Description
•