Closed Bug 502128 Opened 15 years ago Closed 5 years ago

toplevel window should remain active while plugin child window has focus

Categories

(Core :: Widget: Gtk, defect, P5)

x86
Linux
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: karlt, Unassigned)

References

Details

Attachments

(1 file)

There is a mismatch between GtkWidget focus-in/out-event signals, which indicate which *widget* has keyboard focus, and NS_ACTIVATE/DEACTIVATE events which are associated with which toplevel *window* is active.

When a plugin GtkWidget is given focus, the container widget loses focus.
This causes a focus-out-event on Mozilla's container widget and
OnContainerFocusOutEvent() responds to this by sending a NS_DEACTIVATE event,
deactivating the window.

Active status would be better determined through is-active or
has-toplevel-focus properties on the toplevel GtkWindow mShell.

Widget-focus grabs from a plugin window may be better detected through the
set-focus signal on the toplevel GtkWindow or signals on the GtkSocket for the
plugin (see bug 498143 comment 37).

(This is discussed in bug 498143 comment 26 and subsequent.)
We should fix this. I'm hoping that it will make tests that depend on focus and firing keys more reliable or easier to debug why they fail arbitrarily on Linux so often.

Karl, do you know what needs to be done here, or plan on working on this?
Flags: blocking1.9.2?
I don't think this is going to help (the majority of) Linux focus issues for tests, as this bug is only having an effect when windowed plugins are involved.

Bug 497839 comment 11 summarizes my current understanding of the main issue with synthetic key events and focus on Linux.  (That bug is probably a better place to discuss this, as fixing this bug will not help that issue.)

One thing this bug would affect is whether keyboard events received by plugin windows and propagated to the browser get processed correctly by the browser.

I'm not sure whether to make this bug a priority at the moment because I'm not sure whether plugins are currently propagating keyboard events.
Maybe I'm thinking of another bug then. I'm referring to the issue of handling activate and focus separately, and without the extra activate call from within SetFocus.
This bug is part of the issue of handling activate and focus separately.
This part is about the toplevel window being marked inactive when it is active but the plugin child widget has focus, and about sending an activate event (that should be unecessary) when the user clicks outside the plugin:
http://hg.mozilla.org/mozilla-central/annotate/ea46b7fe6320/widget/src/gtk2/nsWindow.cpp#l2770

The GtkWidget focus-in/out-event signals that we are currently using to detect activation actually happen to work well when there are no plugins involved.

Sending the activate event from within SetFocus is currently only necessary because tests are assuming that synthesizeKey will work after a focus() method call.  I'm not sure whether we need a bug to track changing tests to wait for focus or whether we need a means of sending key events to windows that are not active, but that is the question I'm trying to raise in bug 497839 comment 11.
What issue does this bug cause? How would I reproduce this?
I think this bug will need to be fixed to correctly handle key events
propagated from XEmbed (windowed) plugins. (bug 78414 is the superbug.)

However, there could be many other bugs preventing this from working:

1. Apply this patch.

2. Load
http://hg.mozilla.org/mozilla-central/raw-file/ec96a6a36e84/layout/generic/test/test_plugin_position.xhtml

3. Click on the plugin 

   Plugin widget receives focus.

4. Type Alt-F

   Plugin doesn't handle the key event and so propagates event up to
   Mozilla's widget.  The event is received in key_press_event_cb in
   nsWindow.cpp where the widget parameter is the MozContainer GtkWidget.

Expected results: File menu opens
Actual results: nothing

I don't think this needs to block 1.9.2 because AFAIK this never worked.

The first bug in the event processing is that the event gets sent to
nsWebShellWindow::HandleEvent() instead of HandleEvent() in nsView.cpp.  This
happens because the container GtkWidget doesn't know which nsIWidget has focus
(and so sends the event to the toplevel nsIWidget).
...
> 4. Type Alt-F
> 
>    Plugin doesn't handle the key event and so propagates event up to
>    Mozilla's widget.  The event is received in key_press_event_cb in
>    nsWindow.cpp where the widget parameter is the MozContainer GtkWidget.
> 
> Expected results: File menu opens
> Actual results: nothing

That's just bug 78414 no?

I thought this was a bug about the active status of the window when a plugin was focused? I don't see the active/raised state of the window having a problem for me.
Flags: blocking1.9.2?
(In reply to comment #7)
> That's just bug 78414 no?

Yes, though bug 78414 is really a different bug (or bugs) for each platform and each mode of plugin on the platform.  For XEmbed plugins no change in the spec is required to fix bug 78414, but this bug is one of the dependencies.  AIUI if the focus manager does not know that the window is active, then the events will not be processed correctly.

> I thought this was a bug about the active status of the window when a plugin
> was focused? I don't see the active/raised state of the window having a problem
> for me.

Yes, this bug is about the active status.  The window manager (process) still
gets the active status right, but an NS_DEACTIVATE is sent.  On procssing this
event, nsWebShellWindow::HandleEvent calls fm->WindowLowered(window).  This
then "informs the DOM window that it has deactivated" and set
nsFocusManager::mActiveWindow to NULL.

There is a windowed plugin that takes focus on click on this site:
http://www.communitymx.com/content/source/E5141/wmodenone.htm
Ah, yes, I remember this problem now. I'll take another look.
Attachment #401594 - Attachment is patch: true

Windowed Flash is no longer supported and other plugins are not supported at all.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: