mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-10 11:55:49 +00:00
834ab00aaa
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 --HG-- extra : moz-landing-system : lando |
||
---|---|---|
.. | ||
composer | ||
libeditor | ||
reftests | ||
spellchecker | ||
txmgr | ||
AsyncSpellCheckTestHelper.jsm | ||
moz.build | ||
nsIDocumentStateListener.idl | ||
nsIEditActionListener.idl | ||
nsIEditor.idl | ||
nsIEditorMailSupport.idl | ||
nsIEditorObserver.idl | ||
nsIEditorSpellCheck.idl | ||
nsIEditorStyleSheets.idl | ||
nsIHTMLAbsPosEditor.idl | ||
nsIHTMLEditor.idl | ||
nsIHTMLInlineTableEditor.idl | ||
nsIHTMLObjectResizer.idl | ||
nsIPlaintextEditor.idl | ||
nsITableEditor.idl | ||
nsIURIRefObject.idl |