Opened 15 years ago
Closed 12 years ago
#5007 closed Bug (expired)
IE Standards Mode: Incorrect selection & range produced when clicking to the right of a <br />
Reported by: | Scott McNaught | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | General | Version: | |
Keywords: | Cc: |
Description
For the first 500ms after clicking to the right of a <br />, IE produces a range at the wrong spot.
To see the problem, edit plugins/selection/plugin.js. In IEs getNative(), add: this.document.$.selection.createRange().select(); so it looks like:
CKEDITOR.env.ie ? function() { this.document.$.selection.createRange().select(); return this._.cache.nativeSel || ( this._.cache.nativeSel = this.document.$.selection ); }
Then open ckeditor, and set the HTML to:
<p>Line 1<br /> Line 2</p>
Click to the right of the Line 1 / the <br />. The caret will move to the start of Line 2, thus proving that the IE range created is wrong.
Some notes:
- 500ms after the click, calling getRange() code will produce the range at the correct position.
- The range produced is definately wrong and at Line 2. In getBoundaryInformation(), the compareEndPoints() check will show that the selection is after the <br />
- The issue is also present after the editor loses focus, and regains it (ie - when using a RichCombo).
- This issue doesnt happen when focussing using right click / context menu.
- The issue flows through and makes the w3 range wrong too
Change History (5)
comment:1 Changed 15 years ago by
Milestone: | → CKEditor 3.3 |
---|
comment:2 Changed 15 years ago by
Keywords: | Pending added |
---|---|
Milestone: | CKEditor 3.3 → CKEditor 3.x |
comment:3 Changed 15 years ago by
Hi Garry,
Its not really noticed in normal CKEditor.. Its mainly a problem when you start developing custom stuff.
An example though in CKEditor... Set the source to:
<p>Line 1][<br /> </p>
... where the users selection is at ][
Then change the font colour or font background/highlight colour. You will notice that the caret moves to the start of the next line.
See back to my "Notes" section above where I say "- The issue is also present after the editor loses focus, and regains it (ie - when using a RichCombo)." When interacting with the toolbar and changing the focus (i assume for accessibility), the refocus suffers the "500ms problem".
Im not sure what you meant by "As we would just follow the 'final decision' of IE since other browsers agreed with that also, and most importantly, it's in expectation."
Cheers,
Scott
comment:5 Changed 12 years ago by
Resolution: | → expired |
---|---|
Status: | pending → closed |
I was not able to reproduce this in latest CKEditor 3.6.4.
@Scott:Did you see any usability issue with this? As we would just follow the 'final decision' of IE since other browsers agreed with that also, and most importantly, it's in expectation.