Bug 110172 – Focusing a new frame (via window.focus()) should blur the active element in the current frame

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Andy Estes]

Focusing a new frame (via window.focus()) should blur the active element in the current frame

[Andy Estes]

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

[Andy Estes]

Created attachment 188990 [details]
Patch

[Andy Estes]

*** Bug 33512 has been marked as a duplicate of this bug. ***

[Rafael Brandao]

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.

[Andy Estes]

(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.

[WebKit Review Bot]

Comment on attachment 188990 [details]
Patch

Clearing flags on attachment: 188990

Committed r143299: <http://trac.webkit.org/changeset/143299>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Kentaro Hara]

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.

[Andy Estes]

(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.