Hello Petr,
Thank you for review. Please find my answer below.
Thanks,
Dmitry
On 23/07/2014 11:58, Petr Pchelko wrote:
Hello, Dmitry.
What happens if the focused applet is closed? Does the pluginFocusedWindow
correctly updated in this case?
Does the closed applet receives handleFocusEvent(false) event?
The closing of an applet means that we closed the browser's window contained
the applet or moved to another web-page. In this case we are not interesting in
pluginFocusedWindow or focus events anymore, since all applets in the window
are destroyed. If we go back to the applet's page, all applets will be started
from scratch.
And what would happen if we press "refresh". The VM is not restarted in this
case, so couldn't we have a pluginFocusedWindow in an incorrect state after that?
If the page is refreshed, all applets will be restarted by Java Plugin
and the focus will be set to the firs applet on the page. We do not care
about pluginFocusedWindow in this case.
Also, I'm not sure about the naming. pluginFocusedWindow seems not quite self-explanatory to me. In
reality it's "browserWindowFocusedApplet" isn't it? Why did you call it
"plugin"?
You are right. I updated the field's name. Please find new version here:
http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.03/
With best regards. Petr.
On 23 июля 2014 г., at 11:29, dmitry markov <dmitry.mar...@oracle.com> wrote:
Hello,
Could anyone else review the fix, please?
https://bugs.openjdk.java.net/browse/JDK-8044614
http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/
Thanks in advance,
Dmitry
On 18/07/2014 15:57, Alexander Scherbatiy wrote:
The fix looks good to me.
Thanks,
Alexandr.
On 7/18/2014 3:52 PM, dmitry markov wrote:
Hi Alexandr,
Please find answer below.
Thanks,
Dmitry
On 17/07/2014 14:18, Alexander Scherbatiy wrote:
The pluginFocusedWindow is only updated after switching from one browser to
another (after WindowFocusEvent event).
Should it also be updated after switching from one applet to another in the
same browser (after FocusEvent)?
It is not necessary, since the pluginFocusedWindow stores information about the
latest focused applet in the browser's window. This information is only used
for focus restoring when the window becomes active again. So I think that is
enough to update pluginFocusedWindow only in handleWindowFocusEvent() when the
browser's window becomes inactive.
What happens if the focused applet is closed? Does the pluginFocusedWindow
correctly updated in this case?
Does the closed applet receives handleFocusEvent(false) event?
The closing of an applet means that we closed the browser's window contained
the applet or moved to another web-page. In this case we are not interesting in
pluginFocusedWindow or focus events anymore, since all applets in the window
are destroyed. If we go back to the applet's page, all applets will be started
from scratch.
Thanks,
Alexandr.
On 7/16/2014 4:08 PM, dmitry markov wrote:
Hi Alexandr,
I am sorry for the delay.
When a browser's window becomes active/inactive, the browser generates
WindowFocusEvent and sends it to the applets via Java Plugin. So the order of
the events is defined by the browser. I tested several browsers - all of them
sends WindowFocusEvent(parentWindow=false) to the active window and then
WindowFocusEvent(parentWindow=true) to inactive window during switching between
two browser's windows. It looks like this is common practice for such
operation. However, I did not find any docs which can confirm this behavior.
Please find new version of the fix here -
http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/
Changes:
- Made small refactoring: focusedWindow -> globalFocusedWindow,
previousFocusedWindow -> pluginFocusedWindow, etc.
- Added manual test
Thanks,
Dmitry
On 04/07/2014 14:26, Alexander Scherbatiy wrote:
On 7/3/2014 2:25 PM, Alexander Scherbatiy wrote:
On 7/3/2014 1:15 PM, dmitry markov wrote:
Hi Alexandr,
Thank you for review.
For the use case you described - when we move back to the first browser window
with 3 applets, the first applet (not the second one) will receive the focus.
This behavior is incorrect, since the second applet should receive the focus.
I have updated the fix, please find new version here:
http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.01/
Now we store the information about focused applet when browser window is
deactivated and restore the focus to the previously focused applet when browser
window becomes active again
The case can be more complicated with some browsers where each of them has
several applets.
It seems there should be a map between a browser and it's focused applet.
I see that your fix solves these cases.
One more problem can be with the WindowsFocusEvents order.
Is it guarantee that order of events WindowsFocusEvent (parentwindow=false)
to one browser and WindowsFocusEvent (parentWindow=true)
for other browser can't be changed?
I would suggest to do a small refactoring.
Something like focusedWindow to globalFocusedWindow, previousFocusedWindow to
pluginFocusedWindow, add method like isPluginFocused(...)
and use conditional operator '?' for globalFocusedWindow setting.
Thanks,
Alexandr.
Is it possible to add a manual test for the fix?
Thanks,
Alexandr.
Thanks,
Dmitry
On 02/07/2014 16:36, Alexander Scherbatiy wrote:
Let's assume one browser has 3 applets where the second applet has focus.
I click on the second browser with an applet (the applet receives the focus)
and then click on the first browser back.
Should the second applet in the first browser receive the focus?
Thanks,
Alexandr.
On 7/2/2014 2:45 PM, dmitry markov wrote:
Hello,
Could you review the fix for jdk9, please?
bug: https://bugs.openjdk.java.net/browse/JDK-8044614
webrev: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/
Problem description: on Mac OSX when switching between several applets running
in separate browser's windows, the applet in active window does not receive
focus.
Fix: the method CEmbeddedFrame.handleWindowFocusEvent() should be modified. It
has to detect the switching between browser's windows and update focusedWindow
field accordingly.
Thanks,
Dmitry
