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

NEW
Unassigned

Status

()

Core
DOM: Events
7 years ago
3 years ago

People

(Reporter: Brian Kaull, Unassigned)

Tracking

(Depends on: 1 bug, {regression})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

7 years ago
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.

Updated

7 years ago
Component: Disability Access → General
QA Contact: disability.access → general
(Reporter)

Comment 1

7 years ago
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
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"
Status: UNCONFIRMED → NEW
Component: General → DOM: Events
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → events
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
Of course, if it were a security precaution then letting the cross-site child frame set focus the first time means it's broken.

Updated

7 years ago
Keywords: regression, regressionwindow-wanted

Comment 5

7 years ago
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 <masayuki@d-toybox.com>
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
Keywords: regressionwindow-wanted
Masayuki-san, can you take a look please?
Blocks: 125282
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.
Depends on: 604289

Comment 8

6 years ago
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

3 years ago
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);
}
You need to log in before you can comment on or make changes to this bug.