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

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.

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.

Regression range and un-regression range would be great.

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

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?

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

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

The first good revision is: changeset: 36656:8b6f32659aa6 user: Boris Zbarsky <bzbarsky@mit.edu> 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

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 ?

In any case, certainly confirmed!

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

Works with this applied: http://hg.mozilla.org/mozilla-central/rev/8b6f32659aa6#l4.69 Didn't try the others.

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

No clue!

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

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

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

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

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

For that last trunk regression range, testing on Linux, hg bisect tells me: The first bad revision is: changeset: 43624:c7f3d1f216d6 user: Masayuki Nakano <masayuki@d-toybox.com> 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

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.

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.

(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.

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

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

fix is wanted, but not blocking a 1.9.2 release

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

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

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

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

(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.

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?

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 :(

> Can we get a regression range for trunk We have one. See comment 24!

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

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.