Request for review 7156191 [macosx] Can't type into applet demos in Pivot

[Anton V. Tarasov]

Hi Dmitry,

Let me share my thoughts on it.

We have two focus related callbacks:

1. handleWindowFocusEvent
2. handleFocusEvent

The 1st one is called when the toplevel (browser) parent becomes active (focused), right? This 
doesn't yet mean the plugin itself should gain focus.
However, from the method you call the following:

  118     private void updateOverlayWindowActiveState() {
  119         final boolean showAsFocused = parentWindowActive&&  focused;
  120         responder.handleWindowFocusEvent(showAsFocused);
  121      }

When focused==false the responder will initiate deactivation of the EmbeddedFrame which seems 
unrelated. I think we shouldn't call responder.handleWindowFocusEvent here at all.
That's what the 2nd method is called for. It tells us the plug-in (EmbeddedFrame) itself gains/loses 
focus and here we can respond with calling handleWindowFocusEvent which in its turn
will check the parentWindowActive==true condition. In case parentWindowActive==false && 
focused==true (is that possible?) I think we shouldn't activate the plug-in as well.

Another question is whether handleFocusEvent(false) is called in response  to deactivating the 
browser window by, say, alt-tab? I would expect the methods are called in the following order:

handleFocusEvent(false)
handleWindowFocusEvent(false)

If that is true then what I suggested above should work if I got all that stuff right.

What do you think?

Thanks,
Anton.


On 26.03.2012 18:37, Dmitry Cherepanov wrote:
> Hello,
>
> Here's a fix for 7156191 ([macosx] Can't type into applet demos in Pivot)
>
> The current implementation of focus event handlers in CEmbeddedFrame dispatches focus events 
> directly to the embedded frame. The fix changes the implementation and now it calls 
> peer.notifyActivation() like it's done in standalone mode.
>
> http://cr.openjdk.java.net/~dcherepanov/7156191/webrev.0/
>
> Thanks,
> Dmitry
>