User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.73.11 (KHTML, like Gecko) Version/7.0.1 Safari/537.73.11 Steps to reproduce: http://www.w3.org/TR/DOM-Level-3-Events/#event-type-beforeinput
That specification is obsolete (and doesn't define the event clearly enough to be implementable anyway). The current specifications covering that area are http://www.whatwg.org/specs/web-apps/current-work/multipage/ and http://dom.spec.whatwg.org/ and neither one mentions this event at all.
Can you point me to something that says the spec is obsolete? That draft I linked to is only a few months old. If it is obsolete, then where are the events that were being specified there going to be specified now? There is absolutely no mention of the keyboard events (e.g. keydown, keyup, input, beforeinput), and even the other events in that spec I linked to. Are these just not specified at all anymore? I find this hard to believe.
> That draft I linked to is only a few months old. Hrm. I didn't realize they were still working on that one. Olli?
"input" events are specified in the HTML specification, for what it's worth.
Masayuki, you might know the current status with this event.
beforeinput event hasn't been stable yet. We don't discuss about this deeply.
Summary: implement beforeInput event → implement beforeinput event
The DOM3 Events spec is still trying to go to CR last I heard. In theory it's being replaced by the UI Events spec: https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm. I'm not sure what the current progress on either is though. As far as I know, the only controversial issue with beforeinput is https://www.w3.org/Bugs/Public/show_bug.cgi?id=23913. Masayuki and I have hit a bit of an impasse there. I agree it'd be nice to have a spec that was actually implementable and to have it in one place instead of in a DOM spec and the HTML spec.
Implemented in Chrome 52 https://crrev.com/232c62972c919927922d08050749280f11ce4f2b
Whiteboard: btpp-followup-2016-03-10, [tw-dom] → [tw-dom]
This won't be exactly a simple bug to fix and while implementing this need to review the spec and file spec bugs and also test other implementations (which are also guaranteed to have some unusual behavior given the complexity here). Filed one spec bug https://github.com/w3c/uievents/issues/87
Johannes thinks this is the #1 priority bug for editing <https://github.com/w3c/editing/pull/146#issuecomment-242434100>. Masayuki, do you think it makes sense for me to look at taking this, including spec review and testing? Where should I look in our code to fire a beforeinput event on user actions? Since Chrome is already implementing this, it would be a good idea to start work on it soon so that their implementation doesn't get set in stone before we can review it.
# Sorry for the delay to reply due to my business trip and being sick yesterday. Yeah, if we could implement it, it'd be great to me too. However, I don't have much time as least this Q3. And perhaps, Q4 isn't enough long time to work on it to me. So, you'll work on it, I'm very happy ;-) Where is a good point to dispatch beforeinput event depends on what causes the input. If keypress event will cause input, I think that we should dispatch it from EventStateManager::PreHandleEvent() when it receives an eKeyPress event. # beforeinput should be be fired before keypress event <https://www.w3.org/TR/uievents/#keypress-event-order>. If composition string will be changed, I think that we should dispatch it from TextComposition::CloneAndDispatchAs() when it dispatches eCompositionUpdate because we need to dispatch beforeinput before dispatching compositionupdate <https://www.w3.org/TR/uievents/#events-composition-input-events>. (And I think that we need to rename it or create a new method, DispatchBeforeInputAndCompositionUpdate() which dispatches beforeinput and calls CloneAndDispatchAs() with eCompositionUpdate.) I'm not sure where is the best place to dispatch beforeinput for the others. E.g., cut, paste, undo, redo. (We should NOT dispatch beforeinput for execCommand()? I don't check the conclusion of discussion about it, it's difficult to do it due to security issue.)
> If keypress event will cause input, I think that we should dispatch it from > EventStateManager::PreHandleEvent() when it receives an eKeyPress event. > # beforeinput should be be fired before keypress event > <https://www.w3.org/TR/uievents/#keypress-event-order>. And I think that we should do this only when the eKeyPress event will cause changing DOM in the editor's normal path. So, ESM needs to retrieve target editor and editor needs to implement a test event method which returns true when eKeyPress event causes changing the DOM.
If you think this is a really big project, then I'm afraid I won't have time to work on it, given my limited work hours.
According to ContentEditable spec, we need to dispatch beforeinput event from EventStateManager and it needs to check if it should be fired with "contenteditable" state or an editable element like <textarea>. https://w3c.github.io/editing/contentEditable.html#editing-states I think that, first, we should implement beforeinput event dispatched immediately before keypress and compositionupdate as our internal event and dispatch it from ESM. Then, editor should switch to handle "beforeinput" instead of "keypress". After that, we should implement "beforeinput" for paste or something if it's necessary (currently, UI Events doesn't say it should be fired, though). Finally, expose "beforeinput" to the web.
See Also: → bug 1181501
Whiteboard: [tw-dom] → [tw-dom][parity-webkit][parity-blink]
pinging Mike to check Web Compatibility and priority on this on this...
(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #14) > Then, editor should switch to handle "beforeinput" instead of "keypress". Oops, this must be wrong because keypress event should be fired on editor and the editor value shouldn't have been changed when web content received keypress event.
(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #18) > (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #14) > > Then, editor should switch to handle "beforeinput" instead of "keypress". > > Oops, this must be wrong because keypress event should be fired on editor > and the editor value shouldn't have been changed when web content received > keypress event. Or, ESM should make beforeinput event store WidgetKeyboardEvent of eKeyPress event. Then, when editor receives beforeinput and needs to consume it, editor can dispatch eKeyPress event before changing the DOM. Finally, ESM stops dispatching eKeyPress event only when the eKeyPress event has already been dispatched. I guess that this is better.
You need to log in before you can comment on or make changes to this bug.