author Masayuki Nakano <masayuki@d-toybox.com>
Wed, 07 Nov 2018 08:38:15 +0000
changeset 444811 b631af71b7ba4ccdff840db112ec9c519382f161
parent 274867 e03b93cbb64d4996a9f170d76a69801b9a708d84
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

# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.

# This file is necessary to "bootstrap" the test case for the test_build
# test, because of the requirement of the top-level directory containing
# config/*.mk.
DIRS += [