Closed Bug 1503231 Opened Last year Closed Last year

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

Categories

(Core :: DOM: Editor, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla65
Tracking Status
firefox65 --- fixed

People

(Reporter: masayuki, Assigned: masayuki)

References

Details

Attachments

(1 file)

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.
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().
Pushed by masayuki@d-toybox.com:
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
https://hg.mozilla.org/mozilla-central/rev/b631af71b7ba
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in before you can comment on or make changes to this bug.