1503231 - TextEditor::DeleteSelectionAsAction() should refer whether Selection is collapsed or not when deciding EditAction

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I realized that there is incompatible issues between Chrome and Safari.
Input Events declares that "deleteWordBackward", "deleteWordForward", "deleteSoftLineBackward", "deleteSoftLineForward", "deleteEntireSoftLine", "deleteHardLineBackward" and "deleteHardLineForward" should be set only when Selection is collapsed.
https://rawgit.com/w3c/input-events/v1/index.html#interface-InputEvent-Attributes
https://w3c.github.io/input-events/#interface-InputEvent-Attributes

Safari refers Selection state for conforming to the spec. However, Chrome uses them even when Selection is not collapsed. I filed issue for Chromium:
https://crbug.com/899624

On the other hand, declaration of "deleteContentBackward" and "deleteContentForward" is odd. They should be used by only when Selection is NOT collapsed. However, they are useful for Backspace key and Delete key. So, at least, they should be declared "Any", but for consistency with the other input types, they should be "Collapsed". I filed spec bug:
https://github.com/w3c/input-events/issues/82

Currently, we always ignore the Selection state, but shouldn't do so, perhaps.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=805355bb70183a123d4ff722b8969039a204cc7a

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1503231 - Make TextEditor::DeleteSelectionAsAction() removes removing range information from EditAction when Selection is NOT collapsed

When Selection is NOT collapsed, we remove selected content.  Therefore,
web apps don't need to know range information of user operation.  However, web
apps may want to know direction of the operation (backward or forward).  E.g.,
web apps may just mark selected range as "deleted" and move caret before or
after the range.

Therefore, when computed EditAction is eDeleteWordBackward or
eDeleteToBeginningOfSoftLine, we should use eDeleteBackward instead.  When it
is eDeleteWordForward or eDeleteToEndOfSoftLine, we should use eDeleteForward
instead.

Note that only on Windows, we follow behavior of richtext control (and Word).
That is, Ctrl + Backspace/Delete collapse from start of selected range to
start/end of current word.  I.e., collapsing Selection to start first and
removing to start or end of current word is Windows's standard behavior.
Currently, we do this in DeleteSelectionAsSubAction() but every caller
specifies eNone to aDirection except DeleteSelectionAsAction().  So, we can
move this before re-computing EditAction in DeleteSelectionAsAction().

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b631af71b7ba
Make TextEditor::DeleteSelectionAsAction() removes removing range information from EditAction when Selection is NOT collapsed r=m_kato

Comment 4

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/b631af71b7ba