WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
60400
Missing focus change event on form submit.
https://bugs.webkit.org/show_bug.cgi?id=60400
Summary
Missing focus change event on form submit.
Varun Jain
Reported
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.
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
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Varun Jain
Comment 1
2011-05-06 13:48:20 PDT
Created
attachment 92633
[details]
Patch
Alexey Proskuryakov
Comment 2
2011-05-06 17:31:30 PDT
> WebKit should
Why should WebKit do that?
Varun Jain
Comment 3
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.
Kent Tamura
Comment 4
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.
Kent Tamura
Comment 5
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.
Varun Jain
Comment 6
2011-05-10 15:52:37 PDT
Created
attachment 93031
[details]
Patch
Varun Jain
Comment 7
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.
WebKit Review Bot
Comment 8
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.
WebKit Review Bot
Comment 9
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
Kent Tamura
Comment 10
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?
Kent Tamura
Comment 11
2011-05-10 20:21:39 PDT
Comment on
attachment 93031
[details]
Patch r- because of Chromium build error.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug