Closed Bug 1503231 Opened Last year Closed Last year
Editor::Delete Selection As Action() should refer whether Selection is collapsed or not when deciding Edit Action
Bug 1503231 - Make TextEditor::DeleteSelectionAsAction() removes removing range information from EditAction when Selection is NOT collapsed
47 bytes, text/x-phabricator-request
|Details | Review|
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 firstname.lastname@example.org: 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
You need to log in before you can comment on or make changes to this bug.