1001610 - getSelection should be null after tabbing out of a selection

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P5)

Description

[ejsanders]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.132 Safari/537.36

Steps to reproduce:

http://jsfiddle.net/edg2s/4MPMV/3/


Actual results:

Tabbing out of a content editable div results in the selection being visually killed (no cursor or highlighted text), yet window.getSelection() still tells you where the selection used to be. 


Expected results:

window.getSelection() should be nullified.

Comment 1

[(no longer active)]

The selection being hidden doesn't mean that it has gone away, we show the selection under a number of circumstances, and I don't think it makes sense to lie to content about where the selection is just because it's not visually visible.

Comment 2

[ejsanders]

If the selection hasn't gone away then why is it shown as having gone away? You have a conflict between the model and the view here. Also under what circumstances is it shown?

Comment 3

[ejsanders]

It's also impossible for the user to access that selection again, shift-tabbing resets the selection to [0,0]. I appreciate you can have a non-focused selection (e.g. placing the cursor in an iframe) but there is a visual styling for that (grey-background selection with no cursor). In this instance the selection is dead for all sensible purposes yet we still make it available programmatically.

Comment 4

[ejsanders]

See also Chromium, which behaves more sensibly.

Comment 5

[(no longer active)]

(In reply to ejsanders from comment #3)
> It's also impossible for the user to access that selection again,
> shift-tabbing resets the selection to [0,0].

That's because of the focus change from the input box back to the content editable field which does modify the active selection.  Try selecting something in your test case, Shift+Tab to move the focus before the contenteditable field, and then press Tab to move it back in.  And try the same thing in Chromium!

> I appreciate you can have a
> non-focused selection (e.g. placing the cursor in an iframe) but there is a
> visual styling for that (grey-background selection with no cursor). In this
> instance the selection is dead for all sensible purposes yet we still make
> it available programmatically.

Looking at your test case again, I can't even reproduce comment 0 (and I swear I could the last time!), I get a null selection anchor node in the log when I tab from the contenteditable field to the input box...

Also, note that the selection is not yet properly spec'ed and different UAs basically do whatever they want here.  Ryosuke Niwa is working on a spec IIRC, so if you care enough about this, please file a spec bug here: <https://www.w3.org/Bugs/Public/enter_bug.cgi>  That would be a great way to ensure that a sane behavior will be spec'ed and hopefully implementations can converge on their behavior about selection in the future.

Comment 6

[ejsanders]

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #5)
> That's because of the focus change from the input box back to the content
> editable field which does modify the active selection.  Try selecting
> something in your test case, Shift+Tab to move the focus before the
> contenteditable field, and then press Tab to move it back in.  And try the
> same thing in Chromium!
Yes, but in that case the selection is still rendered, so the model and view are consistent. So when I say "the selection should be nulled", the other fix would be to keep the selection rendered but greyed out (like Chromium with shift+tab).

> Looking at your test case again, I can't even reproduce comment 0 (and I
> swear I could the last time!), I get a null selection anchor node in the log
> when I tab from the contenteditable field to the input box...

I briefly saw this behaviour too but can't consistently reproduce it. I'm still seeing the CE keeping the selection if I hard refresh the page.

> Also, note that the selection is not yet properly spec'ed and different UAs
> basically do whatever they want here.  Ryosuke Niwa is working on a spec
> IIRC, so if you care enough about this, please file a spec bug here:
> <https://www.w3.org/Bugs/Public/enter_bug.cgi>  That would be a great way to
> ensure that a sane behavior will be spec'ed and hopefully implementations
> can converge on their behavior about selection in the future.

Agreed, although regardless of what happens, the model matching needs to match the view.

Comment 7

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.