Bug 13291 – REGRESSION (r19595): WebViewDidBeginEditingNotification not posted when focusing with the mouse

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit API

The WebViewDidBeginEditingNotification isn't sent when editing begins as the result of clicking and thus focusing an editable element. It is posted when tabbing into the element.

Regressed in <http://trac.webkit.org/projects/webkit/changeset/19595>. updateFocusAppearance() is only called in (possible delayed) response to focus().

The regression was detected by a few tests! <http://trac.webkit.org/projects/webkit/changeset/19605>

Created attachment 13976 [details]
Move the call to didBeginEditing() back to Document::setFocusedNode()

[Dave Hyatt]

Comment on attachment 13976 [details]
Move the call to didBeginEditing() back to Document::setFocusedNode()

I don't think the fix is that simple.  The problem I was originally fixing involved the issue of being focused at a time when you don't yet have a renderer.

I'm pretty sure in that case didBeginEditing is being called too early.  My movement into updateFocusAppearance made didBeginEditing fire in places where it was not before.  

(This is also why I expected results to change in the tests and I guess got confused into thinking failures were changes for the better.)

[Dave Hyatt]

Comment on attachment 13976 [details]
Move the call to didBeginEditing() back to Document::setFocusedNode()

Actually going to +.  I still think it's the wrong behavior to fire this notification before the renderer is constructed, but it wasn't relevant to the bug I was fixing and is no worse than it was before.

We should have a followup bug to track this though.

Comment on attachment 13976 [details]
Move the call to didBeginEditing() back to Document::setFocusedNode()

The two tests updated in <http://trac.webkit.org/projects/webkit/changeset/20762> will probably be affected by this patch and need updated results checked in.

[Sam Weinig]

Landed in r20950.