It looks like the EventStateManager is not tracking FocusedContent changes in the browser or editor content windows. This causes several problems like the ones reported in bugs #18002 and #18006. kipp@netscape.com checked in a change to the method nsContainerFrame::GetFrameForPointUsing() that corrects the algorithm used for selecting a frame that contains a point to fix bug #1413. mozilla/layout/html/base/src/nsContainerFrame.cpp revision 1.68 Before kipp's change, the call to GetFrameForPoint() in PresShell::HandleEvent() would always return the RootFrame's child AreaFrame, which had a content node associated with it, so PresShell::HandleEvent() was able to call that content node's HandleDOMEvent() method and notify any listeners. After kipp's change, GetFrameForPoint() returns the RootFrame, when the content area is larger than the viewable area, which has no content node associated with it. This prevents nsPresShell::HandleEvent() from calling HandleDOMEvent(), so DOM listeners like the editor can't process the key events. Kipp's change is okay, but it just exposes the fact that our applications are not using the EventStateManager FocusedContent tracking mechanism. It looks like the EventStateManager's FocusedContent member is always NULL. This forces nsPresShell::HandleEvent() to send all events including KeyEvents, through the code that selects the frame to handle an event based on the Event structure's point member. The point in a KeyEvent structure is meaningless, in fact it is always (0,0). With Kipp's permission, I backed out his change mozilla/layout/html/base/src/nsContainerFrame.cpp revision 1.69 for M11 so that we can get around bugs #18002 and #18006 and get the release out the door. After M11 branches, I will check his fix for bug #1413 back in, so bugs #18002 and #18006 will reappear. We need to make sure that the EventStateManager tracks FocusedContent for Composer and all TextAreas in the browser so we can resolve #18002 and #18006.

Accepting bug. Marking M12.

Making P1 critical.

actually, I would think you wouldn't re-enable kipp's fix until this issue is resolved. The bug kipp fixed is important, but not as critical as the bugs it uncovered. So unless he feels very strongly about it, I'd much prefer will leave the code as is until the full solution is in place.

The problem is not that the EventStateManager doesn't track focusedcontent and it is not always null. Try giving focus to anything other that a text field like a link, button, etc. and you'll see that. The problem is specifically one of focus management with ender widgets. As far as event dispatch to the main document goes the focusContent is supposed to be null. However, we apparently are still using the GetFrameForPoint return as a crutch to get to the document content in this case and that will need to be tweaked.

linking to PDT+ tracking bug 12658

this has been investigated and Kin has a plan on how to resolve it, he may or may not need assistance from joki or hyatt.

I am about to land some major focus changes (today). I need to review any changes you plan on making, as I'm mucking with focus extensively and it is much easier to break something on one platform or another than fix it on all of them (as I've painfully discovered in the last few weeks).

I was planning on attacking this problem next week, so I don't have any fixes just yet. If this is still a problem after you land your focus changes, I'll be sure to run any fixes by you.

Fix checked into tip: mozilla/layout/html/base/src/nsContainerFrame.cpp revision: 1.73 Modified Kipp's fix for #1413 so that nsContainerFrame::GetFrameForPointUsing() looks through any outside children even if it finds a normal child containing aPoint. r=joki@netscape.com

Taking this bug for janc. Kin, do you have a testcase that I can use to verify this bug? Thanks!

The test cases for this are in bugs #1413, #18002 and #18006.

Marking VERIFIED FIXED on: - Linux6 1999113008 mozilla - MacOS86 1999113008 mozilla - WinNT 1999113012 mozilla