Bug 23305 – EditorClient.handleKeyboardEvent() invoked even for non editable node

• Status: NEW
• Component: HTML Editing

[Jay Campan]

The layout test fast/events/key-events-in-input-button.html is failing.
in the test, an input button is focused and a keyboard event is sent to it.
The failure happens because we get an unexpected textInput event in that case.

It appears the EditorClient.handleKeyboardEvent() method is invoked when it should not.
This has been introduced in changeset 38629, specifically the editing/Editor.cpp change.

[Alexey Proskuryakov]

This test doesn't fail on http://build.webkit.org - are you seeing the failure with Chrome?

[Darin Adler]

I stumbled onto this difference recently while fixing another bug.

I believe this is now different between Mac and the other platforms. The Mac has an additional test for canEdit in -[WebHTMLView insertText:] that prevents it from calling through to Editor::insertText, and the equivalent is not present in other platforms.

I prefer this new behavior on the other platforms to the Mac behavior. I think it's good to fire the text input event even if the selection is not in an editable area; editor commands will eventually detect that the selection is not editable and so the default handler won't do anything.

But I think this something that reasonable people might disagree on; input methods create some complexity too. I'd like to hear Alexey's take on this.

I don't agree that handleKeyboardEvent should not be invoked, though. That machinery is responsible for figuring out what key bindings do, and although it's on the EditorClient it should not be limited to editable areas.

If decide that it's better suppress the text input event, I think we should do it at the caller of handleTextInputEvent. For example, if we wanted to fix this on the Windows port, we would add the check to the end of WebView::handleEditingKeyboardEvent or we could add the check to Editor::insertText.

[Alexey Proskuryakov]

Browsers do dispatch keypress after keydown when a key is pressed on a focused <button> or <input type=button>, and I think that textInput should work just like keypress does in simple cases.

[Darin Adler]

(In reply to comment #3)
> Browsers do dispatch keypress after keydown when a key is pressed on a focused
> <button> or <input type=button>, and I think that textInput should work just
> like keypress does in simple cases.

So that means that the new behavior on platforms other than Mac is the correct behavior, and it's the Mac platform and the test results that are incorrect.

[Jay Campan]

Note that IE and Firefox do not dispatch a textInput event in that case.

[Darin Adler]

(In reply to comment #5)
> Note that IE and Firefox do not dispatch a textInput event in that case.

Does either of them dispatch a text input even in any case?

[Jay Campan]

Good point, they don't dispatch a textInput event with a text input either.
So I guess dispatching a inputEvent in the button case makes sense and
the test results are incorrect.