AUTHORS
author Masayuki Nakano <masayuki@d-toybox.com>
Wed, 07 Nov 2018 08:38:15 +0000
changeset 444811 b631af71b7ba4ccdff840db112ec9c519382f161
parent 431355 a8e3b457c43d7686b915463c93ad9aeb5b737f82
permissions -rw-r--r--
Bug 1503231 - Make TextEditor::DeleteSelectionAsAction() removes removing range information from EditAction when Selection is NOT collapsed r=m_kato 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(). Differential Revision: https://phabricator.services.mozilla.com/D10992

For a full list of the people who are credited with making a
contribution to Mozilla, see https://www.mozilla.org/credits/ .