<Swing Dev> <AWT Dev> [9] Review request for 8042465: Applet menus not rendering when browser is full screen on Mac
Anthony Petrov
anthony.petrov at oracle.com
Mon May 26 12:53:15 UTC 2014
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.markov at 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
>>>>
>>
>
More information about the swing-dev
mailing list