Hi Anthony,
Thank you for review. I have updated the fix according to your comments.
Please find the new version here -
http://cr.openjdk.java.net/~dmarkov/8042465/jdk9/webrev.02/
Thanks,
Dmitry
On 26/05/2014 16:53, Anthony Petrov wrote:
Hi Dmitry,
The fix seems to cover only the case when an app is running with the
default L&F. What is the solution for custom L&Fs? Can we move the
logic for cache disabling to the shared popup-related code somewhere
so that the issue is fixed for all L&Fs at once?
--
best regards,
Anthony
On 5/26/2014 4:08 PM, dmitry markov wrote:
Hello,
Could you review the updated fix, please? The new version of the webrev
is located at -
http://cr.openjdk.java.net/~dmarkov/8042465/jdk9/webrev.01/
the list of changes:
1. Removed the NSWindowCollectionBehaviorCanJoinAllSpaces option
from definition of collection behavior, since it causes the regression
(please refer to the previous emails for details).
2. Disable the cache of HeavyWeightPopups for the applets on Mac OS
X, since the NSWindowCollectionBehaviorFullScreenAuxiliar option does
not work properly alone for the popups from the cache.
Thanks,
Dmitry
On 15/05/2014 11:04, dmitry markov wrote:
Hi Petr, Anthony,
Thank you for looking at this. I really missed the case pointed out by
Petr. If the test app is running in browser instead of IDE or
appletviewer, the situation is much worse - the opened popup does not
hide at all when we switch to another space. This behavior is caused
by usage of NSWindowCollectionBehaviorCanJoinAllSpaces. I used that
option since NSWindowCollectionBehaviorFullScreenAuxiliary does not
work properly alone, (i.e if browser is in full screen mode and we
open the popup first time, it works well; however if we exit full
screen and then enter back again and try to open the popup, it will be
displayed behind the browsers window). I am not sure, but it is most
likely such behavior is caused by popups caching.
I need more time for deeper investigation.
Thanks,
Dmitry
On 14/05/2014 14:46, Anthony Petrov wrote:
To add to what Petr just said, what is the exact reason to specify
the NSWindowCollectionBehaviorCanJoinAllSpaces behavior? I believe
that NSWindowCollectionBehaviorFullScreenAuxiliary alone should do
the trick, does it not?
Petr: we used to build JDK with OS X 10.6 SDK where the 10.7-specific
constants are not defined. Hence the reason for (1 << 8), etc. As
long as this fix is not going to be ported to JDK 7u, I think we
could use the constant names explicitly (we need to make sure RE
builds 8u with 10.7+ SDK though.)
--
best regards,
Anthony
On 5/14/2014 1:22 PM, Petr Pchelko wrote:
Hello, Dmitry.
With your fix I'm observing the following regression:
1. Run the test app from the bug in IDE or appletviewer.
2. Open the menu
3. Without closing the menu switch to another space using keyboard
(Ctrl+Arrow) or touchpad gesture
4. The opened popup will be shown on another space and than will
disappear. But it will be visible for enough time to get noticed and
annoying.
And also, why are you explicitly setting 1<<8 instead of using the
name of the constant?
Thank you.
With best regards. Petr.
On 14 мая 2014 г., at 12:54, dmitry markov
<dmitry.mar...@oracle.com> wrote:
Hello,
Could you review the fix for jdk9, please?
bug: https://bugs.openjdk.java.net/browse/JDK-8042465
webrev:
http://cr.openjdk.java.net/~dmarkov/8042465/jdk9/webrev.00/
Problem description: On Mac OS X when a browser is in full screen
mode, applet's popup is displayed behind the browser's window.
Fix: It is necessary to change the collection behavior for the
popup windows to make them visible when the browser runs in full
screen mode.
Thanks,
Dmitry
