Thanks. Can I have a second Review please?
> Am 01.12.2018 um 01:20 schrieb Sergey Bylokhov :
>
> Looks fine.
>
>> On 30/11/2018 05:22, Baesken, Matthias wrote:
>> Hi Sergey, I prepared a second webrev :
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8214380.1/
>> - removed the unused isCopy
Looks good to me.
Krishna
> On 01-Dec-2018, at 7:33 AM, Sergey Bylokhov
> wrote:
>
> Hello.
> Please review the fix for jdk 12.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8214461
> Webrev: http://cr.openjdk.java.net/~serb/8214461/webrev.00
>
> We have a few internal classes/interfaces
Hello.
Please review the fix for jdk 12.
Bug: https://bugs.openjdk.java.net/browse/JDK-8214461
Webrev: http://cr.openjdk.java.net/~serb/8214461/webrev.00
We have a few internal classes/interfaces which currently unused and may be
removed:
- sun.awt.image.BadDepthException.java: looks like it w
Looks fine, if there are no other comments I'll push the fix.
On 26/11/2018 05:02, Ichiroh Takiguchi wrote:
Hello.
Could you review the fix ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8212677
Change: https://cr.openjdk.java.net/~itakiguchi/8212677/webrev.00/
Screen shots are in JDK-821
Hi, Shashi.
On 26/11/2018 01:15, Shashidhara Veerabhadraiah wrote:
Hi Alexey, The accessible information is already set for the component
in question and that is the reason it works with the accessibility
short cut(without this fix).
Did you check that VO announces when the ProgressBar is updat
Hello,
I think that you can use invokeAndWait instead of invokeLater(),
which will wait while the code is executed on EDT, and I am not
sure that you need to interrupt the main thread of the test.
On 26/11/2018 09:19, Ichiroh Takiguchi wrote:
Hello.
Could you review the fix ?
Issue:
JDK-821126
Looks fine.
On 30/11/2018 05:22, Baesken, Matthias wrote:
Hi Sergey, I prepared a second webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8214380.1/
- removed the unused isCopy
- added a NULL check after GetLongArrayElements
Best regards, Matthias
-Original Message-
Fro
Hi, Manajit.
When the use clicks on the title bar then frame is moved to the either zoom or
minimize depending upon the System Preferences -> Dock setting.
With my fix if a frame state is MAXIMIZED_BOTH, the frame resizibility is set
to true to allow the frame to go to the set state (zoom or mi
On 2018-11-30 04:29, Philip Race wrote:
+1 from me.
-phil.
On 11/29/18, 7:27 PM, Sergey Bylokhov wrote:
Then it can be simplified further:
http://cr.openjdk.java.net/~serb/8212680/webrev.01
This looks good to me too, but as I said before, I still think you
should write a note about this ch
Hi Sergey,
When the use clicks on the title bar then frame is moved to the either zoom or
minimize depending upon the System Preferences -> Dock setting.
With my fix if a frame state is MAXIMIZED_BOTH, the frame resizibility is set
to true to allow the frame to go to the set state (zoom or minim
Hi Sergey, I prepared a second webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8214380.1/
- removed the unused isCopy
- added a NULL check after GetLongArrayElements
Best regards, Matthias
> -Original Message-
> From: Baesken, Matthias
> Sent: Donnerstag, 29. November 2018
Hi Prasanta,Please review the fix for JDK12.Issue: https://bugs.openjdk.java.net/browse/JDK-8208290Webrev: http://cr.openjdk.java.net/~mhalder/8208290/webrev.00/Fix:
This webrev was sent earlier with issue 8208743 and contains a new test case. The root cause of both the issues are same and are
Hi Sergey,
The occurrence of the problem does not depend on child windows, their type and
visibility. The issue is caused by orderFront operation when it is called for
the focused window, (i.e. window which is already located above other windows).
In other words double invocation of order opera
13 matches
Mail list logo
