Closed Bug 1503231 Opened Last year Closed Last year

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


(Core :: DOM: Editor, defect)

Not set



Tracking Status
firefox65 --- fixed


(Reporter: masayuki, Assigned: masayuki)




(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.

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

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:

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

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
Make TextEditor::DeleteSelectionAsAction() removes removing range information from EditAction when Selection is NOT collapsed r=m_kato
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in before you can comment on or make changes to this bug.