зеркало из https://github.com/mozilla/gecko-dev.git
90cd2122dd
`AutoEditActionDataSetter` is created in the stack when editor's public method is called and that guarantees lifetime of global objects in editor such as editor itself, selection controller, etc. The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED` if an event is actually dispatched but canceled. The reason why it's an error is, editor code must stop handling anything when any methods return error. So, returning an error code is reasonable in editor module. But when it's filtered by `EditorBase::ToGenericNSResult()` at return statement of public methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing new exception, but editor class users in C++ can distinguish whether each edit action is canceled or handled. The reason why we should not throw new exception from XPCOM API is, without taking care of each caller may break some our UI (especially for avoiding to break comm-central). Therefore, this patch does not make XPCOM methods return error code when `beforeinput` event is canceled. In most cases, immediately after creating `AutoEditActionDataSetter` is good timing to dispatch `beforeinput` event since editor has not touched the DOM yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to dispatch `beforeinput` event after that. Alhtough this is not a good thing from point of view of consistency of the code. However, I have no better idea. Note 1: Our implementation does NOT conform to the spec about event order between `keypress` and `beforeinput` (dispatching `beforeinput` event after `keypress` event). However, we follow all other browsers' behavior so that it must be safe and the spec should be updated for backward compatibility. Spec issue: https://github.com/w3c/uievents/issues/220 Note 2: Our implementation does NOT conform to the spec about event order between `compositionupdate` and `beforeinput`. Our behavior is same as Safari, but different from Chrome. This might cause web-compat issues. However, our behavior does make sense from point of view of consistency of event spec. Additionally, at both `compositionupdate` and `beforeinput`, composition string in editor has not been modified yet. Therefore, this may not cause web-compat issues (and I hope so). Spec issue: https://github.com/w3c/input-events/issues/49 Note that this patch makes editor detect bugs that `beforeinput` event hasn't been handled yet when it dispatches `input` event or modifying `data` and `dataTransfer` value are modified after dispatching `beforeinput` event with `MOZ_ASSERT`s. Differential Revision: https://phabricator.services.mozilla.com/D58127 --HG-- extra : moz-landing-system : lando |
||
|---|---|---|
| .. | ||
| doh-rollout | ||
| formautofill | ||
| pdfjs | ||
| report-site-issue | ||
| screenshots | ||
| webcompat | ||
| moz.build | ||