559076 - Keyboard input is not accepted in a modal window containing an iframe.

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[john.doe_nl]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

From an input element in a document loaded into an iframe a modal window is launched via a keyboard event. The modal window in turn contains an iframe in which content is loaded. The inputs inside the document that was loaded into the iframe (in the modal window) do not received any keyboard input even though it has focus. Mouse events are no problem/are handled properly.

Reproducible: Always

Steps to Reproduce:
1. (Temporarily) disable popup-blocking
2. Open the _TestKeyInPopup0.html in firefox
3. Press 'F2' (or 'p')
4. type any readable characters
Actual Results:  
2. The focus is set to an <input type='text'/>
3. A modal window is shown, focus is set to an <input type='text'/>
4. no input is received in the input element.


This has been broken from FF 3.5 (3.5.8 last one tested where this still functioned properly) to 3.6 (including the latest 3.6.3). Tested on Win XP, Win 7 and Mac.

See attachments for sample code, that demonstrates the problem. Sample code consists of four xhtml's: _TestKeyInPopup0.html through _TestKeyInPopup3.html.

Common add-ons:
Firebug 1.5.3
Firesizer 1.0

Comment 1

[john.doe_nl]

Attachment: File 1 of 4 of test case.

Comment 2

[john.doe_nl]

Attachment: File 2 of 4 of test case.

Comment 3

[john.doe_nl]

Attachment: File3 of 4 of test case.

Comment 4

[john.doe_nl]

Attachment: File 4 of 4 of test case.

Comment 5

[john.doe_nl]

I've also conducted some tests/experiments using jquery where, in the modal window, I attached the keyup/down/press events to the document element and to the document element inside the iframe. I observed that all key events in the 'child iframe window' were caught by its parent.

Additionally, if the modal window is raised via a click on a <button type='button'> key events are properly handled.

Comment 6

[Ria Klaassen (not reading all bugmail)]

Confirmed for Firefox 3.6 on Windows Vista. It works fine with Firefox 3.5 and also with the latest trunk nightly build.
It is a bug fixed only on trunk.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Regression range and un-regression range would be great.

Comment 8

[Matt]

Regression range:

works:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090721 Minefield/3.6a1pre
http://hg.mozilla.org/mozilla-central/rev/f2a58ffcd00c

broken:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090722 Minefield/3.6a1pre
http://hg.mozilla.org/mozilla-central/rev/02f8bf10f441

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f2a58ffcd00c&tochange=02f8bf10f441


Fixed range:

broken:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091224 Minefield/3.7a1pre
http://hg.mozilla.org/mozilla-central/rev/fa1e6f870ff1

works:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091225 Minefield/3.7a1pre
http://hg.mozilla.org/mozilla-central/rev/f60b3bbfa8ce

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fa1e6f870ff1&tochange=f60b3bbfa8ce

Comment 9

[john.doe_nl]

v.3.6.6, was released on June 26th, 2010. Yet this issue is still in there. And it is highly annoying to the customers of the company that I work for. Any chance this gets solved at any time?

Comment 10

[Matt]

The first bad revision is:
changeset:   30539:026403392281
user:        Robert O'Callahan <[e-mail]>
date:        Wed Jul 22 12:45:11 2009 +1200
summary:     Bug 352093. Part 14: Make content IFRAMEs windowless. r=bzbarsky

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That fix range is surprising. It would have to be the GetPrimaryFrame changes, but that shouldn't have changed behaviour here.

Comment 12

[Matt]

The first good revision is:
changeset:   36656:8b6f32659aa6
user:        Boris Zbarsky <[e-mail]>
date:        Thu Dec 24 16:20:06 2009 -0500
summary:     Bug 500882 part 5.  Switch layout module to using the new GetPrimaryFrame API.  r=roc

Comment 13

[Boris Zbarsky [:bzbarsky]]

I can only echo comment 11...

Matt, if you take the build from rev 5824db6f9c71 and apply only the hunk at http://hg.mozilla.org/mozilla-central/rev/8b6f32659aa6#l4.69 then does the problem disappear?

What about the hunk at http://hg.mozilla.org/mozilla-central/rev/8b6f32659aa6#l4.78 ?

What about the hunk at http://hg.mozilla.org/mozilla-central/rev/8b6f32659aa6#l4.91 ?

What about http://hg.mozilla.org/mozilla-central/rev/8b6f32659aa6#l4.122 ?

Comment 14

[Boris Zbarsky [:bzbarsky]]

In any case, certainly confirmed!

Comment 15

[Matt]

I'll give it a shot.  I should be able to figure it out.

Comment 16

[Matt]

Works with this applied:
http://hg.mozilla.org/mozilla-central/rev/8b6f32659aa6#l4.69

Didn't try the others.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Huh.  That's.... very odd.  roc, any ideas what's up here?

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No clue!

Comment 19

[Benjamin Smedberg]

Certainly a bug, but not one I think we need to block on.

Comment 20

[Matt]

This no longer works on trunk.  It stopped working sometime in June 2010.

works:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100601 Minefield/3.7a5pre

broken:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:2.0b2pre) Gecko/20100701 Minefield/4.0b2pre


broken:
Mozilla/5.0 (X11; Linux i686; rv:2.0b3pre) Gecko/20100721 Minefield/4.0b3pre

Comment 21

[Matt]

status2.0 is probably wrong now.

Regression range 2:

works:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a6pre) Gecko/20100614 Minefield/3.7a6pre
http://hg.mozilla.org/mozilla-central/rev/33ff230a5b78

broken:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a6pre) Gecko/20100615 Minefield/3.7a6pre
http://hg.mozilla.org/mozilla-central/rev/0d8bf91aa71e

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=33ff230a5b78&tochange=0d8bf91aa71e

Comment 22

[Boris Zbarsky [:bzbarsky]]

OK, I can definitely reproduce this on Linux.  In a debug build I get:

###!!! ASSERTION: Unexpected document: 'capturingContent->GetCurrentDoc() == GetDocument()', file ../../../mozilla/layout/base/nsPresShell.cpp, line 6311
###!!! ASSERTION: Unexpected document: 'capturingContent->GetCurrentDoc() == GetDocument()', file ../../../mozilla/layout/base/nsPresShell.cpp, line 6311

Comment 23

[Boris Zbarsky [:bzbarsky]]

Though I get that in a build that doesn't show this bug too.

Comment 24

[Boris Zbarsky [:bzbarsky]]

For that last trunk regression range, testing on Linux, hg bisect tells me:

The first bad revision is:
changeset:   43624:c7f3d1f216d6
user:        Masayuki Nakano <[e-mail]>
date:        Tue Jun 15 14:05:37 2010 +0900
summary:     Bug 519913 The IME composition string isn't committed on Mac when the window is deactivating r=smaug+enn

Comment 25

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

Boris:

The bug is fixed only on trunk, so, I guess that the patch just shows a hidden bug.

I cannot move focus to the input field in the iframe on the modal window by tab key, therefore, I guess that there is a focus problem and the key and IME events are fired on another elements by the patch of bug 519913.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Oh, quite likely.  There are _definitely_ focus problems here; see comment 22....  If those would explain the behavior seen after bug 519913 was checked in, it all makes sense.

Comment 27

[Neil Deakin]

(In reply to comment #22)
> ###!!! ASSERTION: Unexpected document: 'capturingContent->GetCurrentDoc() ==
> GetDocument()', file ../../../mozilla/layout/base/nsPresShell.cpp, line 6311
> ###!!! ASSERTION: Unexpected document: 'capturingContent->GetCurrentDoc() ==
> GetDocument()', file ../../../mozilla/layout/base/nsPresShell.cpp, line 6311

Those assertions are in a code path that should never be hit by key events. But they do imply that when capturing, the mouse events aren't being redirected to the right presshell. (The if (!sDontRetargetEvents) block near the beginning of HandleEvent). Bug 519913 changed code here to fire key events even in inactive windows.

Comment 28

[Boris Zbarsky [:bzbarsky]]

> Those assertions are in a code path that should never be hit by key events.

To be clear, I get those if I click on the textfield in question.

Comment 29

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

When a content is capturing and it has iframe, mouse move events are fired on the iframe's contents too. Is that unexpected behavior??

Comment 30

[Daniel Veditz [:dveditz]]

fix is wanted, but not blocking a 1.9.2 release

Comment 31

[Johnny Stenback (:jst)]

Sounds like this doesn't affect trunk, so not blocking for Firefox 4.

Comment 32

[Boris Zbarsky [:bzbarsky]]

It does affect trunk (though it didn't use to).  See comment 20.  Renominating, since comment 31 was based on a misunderstanding.

Comment 33

[Johnny Stenback (:jst)]

Blocking, then. Masayuki, can you look into this? Or should Neil or someone else?

Comment 34

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

Enn may be better person if he has time. I'm not familiar with most part of nsFocusManager.

Comment 35

[Neil Deakin]

(In reply to comment #29)
> When a content is capturing and it has iframe, mouse move events are fired on
> the iframe's contents too. Is that unexpected behavior??

If gCaptureInfo.mRetargetToElement is true, then all mouse events are retargeted to the capturing element. That is, only the capturing element receives mouse events.

If gCaptureInfo.mRetargetToElement is false, then mouse events that are not descendants of the capturing element are retargeted to the capturing element. Elements in child frames that are descendants of the capturing element receive events as normal.

Comment 36

[john.doe_nl]

This has been broken all throughout 3.6.n and it is really annoying to our 1000's of customers. Can someone, please, please, please, fix this?

Comment 37

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Can't block on this any more. Can we get a regression range for trunk. Also, if we had had a automatic test for this it wouldn't have re-regressed :(

Comment 38

[Boris Zbarsky [:bzbarsky]]

> Can we get a regression range for trunk

We have one.  See comment 24!

Comment 39

[Manish Tuteja]

I see this issue still exists, when can we have a closure on this ?

Comment 40

[Emil Pasca [:emilpasca]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0

I have tested this issue on Windows 10 x64 with the latest Firefox release (47.0.1) and the latest Nightly (50.0a1-20160710030217) with e10 disabled and could not reproduce it. 
After opening _TestKeyInPopup0.html in Firefox, when pressing 'F2' (or 'p') the modal window is shown and the focus is set to an <input type='text'/>, as you type any readable character, the input is received in the input element.

Note that with the current testcase the popup won't open on the latest Nightly if e10s is enabled.

Also I have tested this issue on Windows 10 x64 with Firefox (3.6.3) and the issue was reproducible.
After following the STR in the description, no input is received in the input element.

Considering this, I will mark the issue as Resolved - Worksforme.