-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How browsers should handle default action of beforeinput
event if it's NOT canceled by modified editor contents
#106
Comments
The spec does not specify what dom change the browser is to do if the event is not canceled. Notice that the browser should emit the event even when the action is not possible in the view of the browser (for example: user hits shortcut keys for bold, but the selection is collapsed).
Given that we do not specify how the browser should modify the DOM is not changed by an event listener, I think it would be consistent to also not specify the behavior if it has been modified. Alternatively, if consistency is desired and it is not too difficult to program, I would say that the DOM should not be modified in this case. |
…vent if there is no `TextEditor` r=smaug If `TextControlState` does not have `TextEditor` and its `SetValue()` is called from `SetUserInput()`, `TextControlState` itself needs to dispatch `beforeinput` event. If the value is modified by `beforeinput` event listener, it's intended that `preventDefault()` is called by the web apps. However, the behavior in this case is not mentioned by UI Events nor Input Events spec. We should just file a spec issue instead of emulating Chrome's behavior for now because it requires more changes, but this case must be an edge case. The spec issue is: w3c/input-events#106 Differential Revision: https://phabricator.services.mozilla.com/D58126
…vent if there is no `TextEditor` r=smaug If `TextControlState` does not have `TextEditor` and its `SetValue()` is called from `SetUserInput()`, `TextControlState` itself needs to dispatch `beforeinput` event. If the value is modified by `beforeinput` event listener, it's intended that `preventDefault()` is called by the web apps. However, the behavior in this case is not mentioned by UI Events nor Input Events spec. We should just file a spec issue instead of emulating Chrome's behavior for now because it requires more changes, but this case must be an edge case. The spec issue is: w3c/input-events#106 Differential Revision: https://phabricator.services.mozilla.com/D58126 --HG-- extra : moz-landing-system : lando
…vent if there is no `TextEditor` r=smaug If `TextControlState` does not have `TextEditor` and its `SetValue()` is called from `SetUserInput()`, `TextControlState` itself needs to dispatch `beforeinput` event. If the value is modified by `beforeinput` event listener, it's intended that `preventDefault()` is called by the web apps. However, the behavior in this case is not mentioned by UI Events nor Input Events spec. We should just file a spec issue instead of emulating Chrome's behavior for now because it requires more changes, but this case must be an edge case. The spec issue is: w3c/input-events#106 Differential Revision: https://phabricator.services.mozilla.com/D58126
…vent if there is no `TextEditor` r=smaug If `TextControlState` does not have `TextEditor` and its `SetValue()` is called from `SetUserInput()`, `TextControlState` itself needs to dispatch `beforeinput` event. If the value is modified by `beforeinput` event listener, it's intended that `preventDefault()` is called by the web apps. However, the behavior in this case is not mentioned by UI Events nor Input Events spec. We should just file a spec issue instead of emulating Chrome's behavior for now because it requires more changes, but this case must be an edge case. The spec issue is: w3c/input-events#106 Differential Revision: https://phabricator.services.mozilla.com/D58126 --HG-- extra : moz-landing-system : lando
…vent if there is no `TextEditor` r=smaug If `TextControlState` does not have `TextEditor` and its `SetValue()` is called from `SetUserInput()`, `TextControlState` itself needs to dispatch `beforeinput` event. If the value is modified by `beforeinput` event listener, it's intended that `preventDefault()` is called by the web apps. However, the behavior in this case is not mentioned by UI Events nor Input Events spec. We should just file a spec issue instead of emulating Chrome's behavior for now because it requires more changes, but this case must be an edge case. The spec issue is: w3c/input-events#106 Differential Revision: https://phabricator.services.mozilla.com/D58126 UltraBlame original commit: 1fb9cf2264b668a76d3671a5a3b06f67c587c0c0
…vent if there is no `TextEditor` r=smaug If `TextControlState` does not have `TextEditor` and its `SetValue()` is called from `SetUserInput()`, `TextControlState` itself needs to dispatch `beforeinput` event. If the value is modified by `beforeinput` event listener, it's intended that `preventDefault()` is called by the web apps. However, the behavior in this case is not mentioned by UI Events nor Input Events spec. We should just file a spec issue instead of emulating Chrome's behavior for now because it requires more changes, but this case must be an edge case. The spec issue is: w3c/input-events#106 Differential Revision: https://phabricator.services.mozilla.com/D58126 UltraBlame original commit: 2dbb6572374cd021f7727c3ffdd0c4251b3731fb
…vent if there is no `TextEditor` r=smaug If `TextControlState` does not have `TextEditor` and its `SetValue()` is called from `SetUserInput()`, `TextControlState` itself needs to dispatch `beforeinput` event. If the value is modified by `beforeinput` event listener, it's intended that `preventDefault()` is called by the web apps. However, the behavior in this case is not mentioned by UI Events nor Input Events spec. We should just file a spec issue instead of emulating Chrome's behavior for now because it requires more changes, but this case must be an edge case. The spec issue is: w3c/input-events#106 Differential Revision: https://phabricator.services.mozilla.com/D58126 UltraBlame original commit: 1fb9cf2264b668a76d3671a5a3b06f67c587c0c0
…vent if there is no `TextEditor` r=smaug If `TextControlState` does not have `TextEditor` and its `SetValue()` is called from `SetUserInput()`, `TextControlState` itself needs to dispatch `beforeinput` event. If the value is modified by `beforeinput` event listener, it's intended that `preventDefault()` is called by the web apps. However, the behavior in this case is not mentioned by UI Events nor Input Events spec. We should just file a spec issue instead of emulating Chrome's behavior for now because it requires more changes, but this case must be an edge case. The spec issue is: w3c/input-events#106 Differential Revision: https://phabricator.services.mozilla.com/D58126 UltraBlame original commit: 2dbb6572374cd021f7727c3ffdd0c4251b3731fb
For example,
insertReplacementText
indicates modifying all or partial text in editor. If the replacing text is modified by abeforeinput
event listener, but it's not canceled, what should browsers do? Keep inserting new value at selection afterbeforeinput
event?Similarly, if selection is changed by
beforeinput
event listener when itsinputType
isdelete*
, browsers should keep deleting something with new selection?Currently, nothing is declared by the specs.
The text was updated successfully, but these errors were encountered: