Bug 110172 - Focusing a new frame (via window.focus()) should blur the active element in the current frame
Summary: Focusing a new frame (via window.focus()) should blur the active element in t...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Andy Estes
URL:
Keywords:
: 33512 (view as bug list)
Depends on:
Blocks: 117666
  Show dependency treegraph
 
Reported: 2013-02-18 18:42 PST by Andy Estes
Modified: 2013-06-14 17:33 PDT (History)
3 users (show)

See Also:


Attachments
Test case (951 bytes, text/html)
2013-02-18 21:18 PST, Andy Estes
no flags Details
Patch (12.68 KB, patch)
2013-02-18 22:29 PST, Andy Estes
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Estes 2013-02-18 18:42:07 PST
Focusing a new frame (via window.focus()) should blur the active element in the current frame
Comment 1 Andy Estes 2013-02-18 21:18:26 PST
Created attachment 188982 [details]
Test case

Consider this test case, where focus starts with the <input> element in the main frame and then shifts to the <iframe> (by calling focus() on the iframe's window object). When the <iframe>'s window is focused, it focuses its <input> element via an event listener. Your browser passes the test if you see the following two lines of text:

PASS: blur event was fired on [object HTMLInputElement] when [object HTMLIFrameElement] was focused
PASS: The main frame's activeElement is now [object HTMLIFrameElement] (should be [object HTMLIFrameElement])

This asserts two things that should be true at the end of the test:

1) A blur event should have been fired on the main frame's <input> element when focus shifts to the <iframe>.
2) When the <iframe>'s <input> element is focused, the main frame should report that its activeElement is the <iframe> [1].

Both of these assertions are true in shipping Firefox and IE, but not in WebKit.

[1] http://www.w3.org/TR/html5/editing.html#document-level-focus-apis
Comment 2 Andy Estes 2013-02-18 22:29:39 PST
Created attachment 188990 [details]
Patch
Comment 3 Andy Estes 2013-02-18 22:46:24 PST
*** Bug 33512 has been marked as a duplicate of this bug. ***
Comment 4 Rafael Brandao 2013-02-18 22:50:48 PST
Comment on attachment 188990 [details]
Patch

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

> LayoutTests/fast/frames/frame-focus-blurs-active-element-expected.txt:1
> +CONSOLE MESSAGE: line 17: PASS: blur event was fired on the active element when the iframe was focused.

Is there no way to avoid printing the line number here? If we ever change something in this test, there's a chance we will need to update the result here, but the fail alert on this one would be annoying for a random gardener.
Comment 5 Andy Estes 2013-02-18 23:00:36 PST
(In reply to comment #4)
> (From update of attachment 188990 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=188990&action=review
> 
> > LayoutTests/fast/frames/frame-focus-blurs-active-element-expected.txt:1
> > +CONSOLE MESSAGE: line 17: PASS: blur event was fired on the active element when the iframe was focused.
> 
> Is there no way to avoid printing the line number here? If we ever change something in this test, there's a chance we will need to update the result here, but the fail alert on this one would be annoying for a random gardener.

DumpRenderTree prints the line number when it logs console messages, so there is no way for an individual test to suppress it. We could change DRT, but would then have to rebase the numerous tests that use console.log(). The line number should only change if the test is changed, at which point you'd have to rebase anyway.
Comment 6 WebKit Review Bot 2013-02-18 23:24:14 PST
Comment on attachment 188990 [details]
Patch

Clearing flags on attachment: 188990

Committed r143299: <http://trac.webkit.org/changeset/143299>
Comment 7 WebKit Review Bot 2013-02-18 23:24:17 PST
All reviewed patches have been landed.  Closing bug.
Comment 8 Kentaro Hara 2013-06-13 18:09:40 PDT
FYI, this change caused a regression in Blink (https://code.google.com/p/chromium/issues/detail?id=246738) and we're removing the change from Blink.
Comment 9 Andy Estes 2013-06-14 17:33:16 PDT
(In reply to comment #8)
> FYI, this change caused a regression in Blink (https://code.google.com/p/chromium/issues/detail?id=246738) and we're removing the change from Blink.

Thanks Kentaro. I filed <https://bugs.webkit.org/show_bug.cgi?id=117666> to track this issue on our end.