InputEvent.inputType should be "deleteContent" when removing non-collapsed selection with pressing Backspace or Delete with modifier keys
Reported by
dtoybo...@gmail.com,
Oct 29
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce the problem: 1. Load https://d-toybox.com/studio/lib/input_event_viewer.html 2. Choose "<div contenteditable>" from the radio buttons. 3. Type some words into the editor which is below the toolbars (blue solid border area). 4. Select some characters with mouse or keyboard. 5. Type Backspace or Delete key with modifier keys to delete text until word or visual line break boundary. What is the expected behavior? InputEvent.inputType value shown in the table which is at bottom of the page should be "deleteContent". What went wrong? Even when removing selected content (i.e., with non-collapsed selection), Chrome sets inputType value to specific value for the key or key combination. I.e., the value becomes "deleteWordBackward", "deleteWordForward", "deleteSoftLineBackward" or "deleteSoftLineForward". This is different from the definition of the specs: Level 1: https://rawgit.com/w3c/input-events/v1/index.html#interface-InputEvent-Attributes Level 2: https://w3c.github.io/input-events/#interface-InputEvent-Attributes # "deleteContentBackward" and "deleteContentForward" are defined as non-collapsed selection case, but I guess that this is typo of the spec. Safari uses "deleteContent" when selection is not collapsed. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 69.0.3497.100 Channel: stable OS Version: OS X 10.14.0 Flash Version:
,
Oct 29
Filed spec issue for "deleteContentBackward" and "deleteContentForward": https://github.com/w3c/input-events/issues/82
,
Oct 29
,
Oct 30
,
Oct 30
,
Oct 30
Hmm, the declared behavior does not make sense for web apps (i.e., Chrome's behavior might be better than Safari and the Spec). See spec issue: <https://github.com/w3c/input-events/issues/82>
,
Oct 30
Tested the issue on reported chrome version #69.0.3497.100 on Mac OS 10.14 by following below steps. Steps: ===== 1.Launched chrome. 2.Navigated to " https://d-toybox.com/studio/lib/input_event_viewer.html". 3.Selected radio button "<div contenteditable> " (6th option in the list). 4.Typed some words in the text editor. 5.Selected the text with keyboard and mouse. 6.Deleted the selected content using backspace until the solid blue border. 7.Observed that "deleteWordBackward" is seen in the table displayed below. 8.Tested the same issue on safari and the same behavior is observed by following the above steps. Attached screenshots for reference. @reporter: Could you please review the attached screenshots and let us know if anything is being missed here. Also Requesting you to confirm if this is the issue you are pointing to. Thanks.!
,
Oct 30
You missed "with modifier keys". E.g., Ctrl + Backspace on Windows is "delete from caret to start of current word". So, when I press Ctrl + Backspace, Chrome sets "deleteWordBackward" correctly. However, if I select a character, and press Ctrl + Backspace, Chrome also sets "deleteWordBackward", but it should be "deleteContentBackword" or "deleteContent". See the spec issue. We're discussing which is better result for web apps. Similar issue also happens with "deleteSoftLineBackward" and "*Forward" of each of them.
,
Nov 1
We've discussed about inputType value when selection is NOT collapsed in <https://github.com/w3c/input-events/issues/82>. The conclusion is, when selection is not collapsed but if selection is collapsed case has direction, it should be exposed. For example, if a key combination causes delete between caret and start of current word, deleteWordBackward should be set if selection is collapsed, but deleteContentBackward should be used if selection is NOT collapsed. Similarly, if a key combination causes delete between caret and start of current visual line, deleteSoftLineBackward should be set if selection is collapse, but deleteContentBackward should be used if selection is NOT collapsed. Same for Forward cases. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by dtoybo...@gmail.com
, Oct 29