Bug 60400 - Missing focus change event on form submit.
Summary: Missing focus change event on form submit.
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-06 13:43 PDT by Varun Jain
Modified: 2011-09-07 12:38 PDT (History)
5 users (show)

See Also:


Attachments
Patch (1.47 KB, patch)
2011-05-06 13:48 PDT, Varun Jain
no flags Details | Formatted Diff | Diff
Patch (6.04 KB, patch)
2011-05-10 15:52 PDT, Varun Jain
tkent: review-
webkit.review.bot: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Varun Jain 2011-05-06 13:43:16 PDT
WebKit should reset focus and generate a focus change event when a form is submitted using the return key. Currently, the focus controller is not triggered and the WebViewClient is not informed that the focused element has lost focus.
Comment 1 Varun Jain 2011-05-06 13:48:20 PDT
Created attachment 92633 [details]
Patch
Comment 2 Alexey Proskuryakov 2011-05-06 17:31:30 PDT
> WebKit should

Why should WebKit do that?
Comment 3 Varun Jain 2011-05-06 18:02:24 PDT
(In reply to comment #2)
> > WebKit should
> 
> Why should WebKit do that?

Hi Alexey, thanks for looking into this. As I understand, the WebViewClient is notified through WebViewClient::focusedNodeChanged() whenever there is a change of focus on the webpage. When a form is submitted using the return key, the node currently focused looses focus. But no notification is sent to the WebViewClient because FocusController is never informed.
Comment 4 Kent Tamura 2011-05-06 18:28:57 PDT
(In reply to comment #3)
> When a form is submitted using the return key, the node currently focused looses focus.

I don't think so.
If a form target is an iframe, the text field doesn't lost focus.
Comment 5 Kent Tamura 2011-05-06 18:29:23 PDT
Comment on attachment 92633 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=92633&action=review

> Source/WebCore/ChangeLog:10
> +        No new tests. (OOPS!)

Need a test.
Comment 6 Varun Jain 2011-05-10 15:52:37 PDT
Created attachment 93031 [details]
Patch
Comment 7 Varun Jain 2011-05-10 15:55:11 PDT
(In reply to comment #5)
> (From update of attachment 92633 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=92633&action=review
> 
> > Source/WebCore/ChangeLog:10
> > +        No new tests. (OOPS!)
> 
> Need a test.

Hi Alexey,Kent...
I have added a test to the patch to illustrate the issue. The Test fails on the last expectation due to the lack of focus change events. I have also added a possible fix to the patch. Please have a look.
Comment 8 WebKit Review Bot 2011-05-10 15:55:24 PDT
Attachment 93031 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'ChangeLog', u'Source/WebCore/loader/FrameL..." exit_code: 1

Source/WebKit/chromium/tests/WebFrameTest.cpp:36:  Alphabetical sorting problem.  [build/include_order] [4]
Total errors found: 1 in 4 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 9 WebKit Review Bot 2011-05-10 16:21:11 PDT
Comment on attachment 93031 [details]
Patch

Attachment 93031 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/8687100
Comment 10 Kent Tamura 2011-05-10 20:21:00 PDT
I confirmed 'blur' event was not fired in such case with IE9, Firefox4, and Opera 11.  So I'm negative about adding setFocusedNode() call.

Varun,
What problem are you trying to solve?
Comment 11 Kent Tamura 2011-05-10 20:21:39 PDT
Comment on attachment 93031 [details]
Patch

r- because of Chromium build error.