656026 - Programmatically trying to set focus in cross domain iframe does not fully focus

Status: NEW

(Core :: DOM: Events, defect, P5)

Description

[Brian Kaull]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.65 Safari/534.24
Build Identifier: Firefox 4.0.1

The issue I'm seeing is that, in FF4, programmatically setting focus between cross domain frames doesn't appear to work properly.  The .focus() call on the element doesn't throw an error and additional keypress events are executed on the element that was just given focus (or at least .focus() was called on it).  However, visually, the focus has not changed, and the focused element isn't properly firing the onFocus event.

In the message list for Yahoo Mail, we rely on the onFocus event to fire when we programmatically set focus on an element in the list.

I've created a simple test case here to demonstrate the issue:
http://kaull.com/top.html

Try this page in both FF3 (or Chrome) and FF4 to see the difference.

I have found that if I call .blur() on the document.activeElement before sending the postMessage that will focus on the other side, things work properly.

Reproducible: Always

Steps to Reproduce:
1. See the sample page for an example.

Actual Results:  
The focused element was not visually focused and did not fire a focus event, yet it received keypress events

Expected Results:  
The focused element should have visual focus and fire a focus event.

Comment 1

[Brian Kaull]

To clarify, I don't see this issue with FF3, but do see it with 4.0.1 as well as these 2 builds:
 - firefox-6.0a1.en-US.mac.dmg	10-May-2011 06:04	 34M
 - http://releases.mozilla.org/pub/mozilla.org/firefox/releases/5.0b1/mac/en-US/ --  Firefox 5.0b1.dmg                                  28-Apr-2011 01:54

Comment 2

[Daniel Veditz [:dveditz]]

According to console log messages focus -does- get transfered back out to the parent (though not visually), and then gets stuck there. The child frame is spitting out the "child focus" message after falling .focus(), but events keep going to the top frame. Visually the focus ring appears to be in the child.

[10:23:50.442] "parent key down"
[10:23:50.459] "child focus"
[10:23:54.263] "child key down"
[10:23:54.280] "parent focus"
[10:23:55.935] "parent key down"
[10:23:55.953] "child focus"
--
[10:24:02.230] "parent key down"
[10:24:02.242] "child focus"

Comment 3

[Daniel Veditz [:dveditz]]

We may have done this as a security precaution, so cross-site frames cannot steal focus and maybe steal a password surreptitiously. bug 552255 was like that but we fixed that one in 3.6.4

Comment 4

[Daniel Veditz [:dveditz]]

Of course, if it were a security precaution then letting the cross-site child frame set focus the first time means it's broken.

Comment 5

[Thomas Ahlblom]

Last good nightly: 2009-12-11 First bad nightly: 2009-12-12

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9af2a428dcb1&tochange=d379a17cbf8f

The first bad revision is:
changeset:   35609:a8f46161c891
user:        Masayuki Nakano <[e-mail]>
date:        Sat Dec 12 14:17:40 2009 +0900
summary:     Bug 125282 Webpage-JS can steal focus from URLbar / chrome r=enndeakin

http://hg.mozilla.org/mozilla-central/rev/a8f46161c891

Comment 6

[Boris Zbarsky [:bzbarsky]]

Masayuki-san, can you take a look please?

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oops, I forgot to work on the regressions. This bug is fixed by the patch for bug 604289. But I don't create some tests for very complex cases. I think I should separate the patches and land them for simple cases.

Comment 8

[Tim Martin]

I still see this bug in recent Nightly builds.

Also, seems like the current situation is actually the worst possible from a security context!  Keystrokes are still captured by the cross domain frame, but there is no visual indication that this will happen.

Comment 9

[Sacha C]

I believe this bug is still present in Firefox 32.0.3, or at least something very similar. If focus is on an input element in a child iframe (in a different domain) and the parent iframe tries to focus an input, it will appear as though focus is still within the iframe, however the parent iframe will receive keyboard events. Additionally, clicking on the input in the child iframe will have no effect, and focus will still remain with the parent.

Here is a small sample illustrating the issue. Click the "Go" button, then quickly place focus in the iframe's input, wait the 2 seconds, and start typing. You should see the text apper in the parent's input.


index.html:

<html>
  <head>
    
  </head>
  <body>
    <input id="outer" type="text" onkeypress=""></input>
    <iframe id="frame" src="http://<some other domain>/firefoxIframeFocus/frame.html"></iframe>
    <button onclick="go()">Go</button>
    <div id="output"></div>

    <script type="text/javascript" src="index.js"></script>
  </body>
</html>



frame.html:

<html>
  <head>
    <script type="text/javascript" src="index.js"></script>
  </head>
  <body>
    <input id="inner" type="text"></input>
  </body>
</html>



index.js:

document.getElementById("outer").onkeypress = function(evt) {
  var out = document.getElementById("output");
  out.innerHTML = out.innerHTML + evt.key;
}

function go() {
  setTimeout(function() {document.getElementById("outer").focus();}, 2000);
}

Comment 10

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 11

[Marco.Stahl]

This bug is still present in Firefox version 66.0.2 (tested on Linux and Windows).

Situation:

An element in a child iframe is focused and the parent frame (from a different domain) tries to "steal" the focus back to one of it's own textareas.

Unexpected Result:

The "focused" textarea in the parent iframe is only "partially" focused.
"Partially focused" means, it's possible to type but there is no visual indication that the textarea is focused (no cursor, no visible selection, no focus border).

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Well, if I rewrite the patch of bug 604289, we could fix this soon. But I gave up to fix that since I didn't have a time to write automated test of that.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Is there some way to fix this, with automated test, without fixing that bug? Or even just fix that bug and at least write a test for this one in the process?