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.
Component: Disability Access → General
QA Contact: disability.access → general
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.
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 <firstname.lastname@example.org> 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
Masayuki-san, can you take a look please?
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
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.
You need to log in before you can comment on or make changes to this bug.