Open Bug 1368864 Opened 4 years ago Updated 2 years ago

Programmatically focusing an iframe's parent window prevents focus on iframe contents


(Core :: DOM: Core & HTML, defect, P2)

53 Branch



Tracking Status
platform-rel --- ?


(Reporter: bugzilla, Unassigned)


(Whiteboard: [platform-rel-Twitch])


(3 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Steps to reproduce:

With these two files:

<!doctype html>
    <script type="text/javascript">
      window.addEventListener('message', function(event) {
        if ( !== 'INPUT') {
<body tabindex="-1">

<!doctype html>
    <script type="text/javascript">
      var input = document.getElementById('click-to-focus');
      var button = document.getElementById('click-to-show');

      button.addEventListener('click', function(event) { = ( === '' ? 'block' : 'none');
        window.parent.postMessage({ tagName: }, '*');
      }, false);
    <style type="text/css">
        html, body {
            width: 100%;
            height: 100%;
<body tabindex="-1">
    <button type="button" id="click-to-show">Click me!</button>
    <input style="display: none;" id="click-to-focus" placeholder="Click to focus" />

Click the button. Click the resulting input element. Attempt to enter text.

Actual results:

Text was not entered into the input element

Expected results:

Text should have been entered into the input element
Component: Untriaged → DOM
Hi Scott, thanks for reporting this. I tried to reproduce by the test case but in vain. More clearly, when I clicked the second iframe ("This frame does not"), no input element was displayed. So I couldn't even go far enough to see what happened when typing in. I observed the same behaviour on both firefox and chrome on XOS.  Would you mind checking again your test case or pointing me where I might go wrong while testing?  Thanks.
Flags: needinfo?(bugzilla)
Hi Hsin-Yi;

This repro case does not appear to work if served over the file:// protocol. You will need to use the included server script (via `yarn start`) or the publicly hosted reproduction case on Github Pages ( If you were using the file:// protocol, can you attempt to use one of the other methods to confirm?
Flags: needinfo?(bugzilla)
Thanks Scott.
I tried to make your test cases more simpler, and created simplified versions as attached. I can reproduce the problem now. And the issue seems can be narrowed down a bit. This is reproducible when the value of |sandbox| attribute is allow-scripts.
Hi Olli,
Do you see where we do wrong with sandbox allow-scripts?
Flags: needinfo?(bugs)
Doesn't ring immediately any bells.
In debug build I get
[Child 20231] WARNING: NS_ENSURE_TRUE(frame) failed: file /home/smaug/mozilla/hg/vsync/dom/events/ContentEventHandler.cpp, line 1276
[Child 20231] WARNING: 'NS_FAILED(rv)', file /home/smaug/mozilla/hg/vsync/dom/events/ContentEventHandler.cpp, line 2467
[Child 20231] WARNING: '!caretRect.mSucceeded', file /home/smaug/mozilla/hg/vsync/widget/ContentCache.cpp, line 208
[Child 20231] WARNING: '!CacheText(aWidget, aNotification)', file /home/smaug/mozilla/hg/vsync/widget/ContentCache.cpp, line 145
[Child 20231] WARNING: '!mContentCache.CacheAll(this, &aIMENotification)', file /home/smaug/mozilla/hg/vsync/widget/PuppetWidget.cpp, line 790
platform-rel: --- → ?
Whiteboard: [platform-rel-Twitch]
Priority: -- → P2
Flags: needinfo?(bugs)
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.