Hi Semyon, Thank you for the clarification. I will try to fix the problem in the native code.
Thanks, Manajit > On 10-Jan-2018, at 9:11 PM, Semyon Sadetsky <semyon.sadet...@oracle.com> > wrote: > > Hi Manajit, > > Not sure what did you mean under valid. The general approach is user may do > with the mouse whatever he wants nevertheless UI should not be broken. This > is just an indication the issue you are trying to fix may be a generic one. > > --Semyon > > On 01/10/2018 05:21 AM, Manajit Halder wrote: >> Hi Semyon, >> >> I could reproduce the behaviour on Ubuntu. But I am curious to know whether >> this particular mouse operation is a valid operation? >> >> Thanks, >> Manajit >> >>> On 08-Jan-2018, at 10:06 PM, Semyon Sadetsky <semyon.sadet...@oracle.com >>> <mailto:semyon.sadet...@oracle.com>> wrote: >>> >>> Hi Manajit, >>> >>> Still didn't get why are you limited to Mac platform only while you change >>> updates generic code. Why mouse provided by Apple matters here? >>> --Semyon >>> >>> On 01/08/2018 01:40 AM, Manajit Halder wrote: >>>> Hi Semyon, >>>> >>>> I could not reproduce the behaviour on Mac as on Mac this operation is not >>>> possible and hence it won’t be a problem on Mac. It is not possible to >>>> press the right button or the left button when the other button is already >>>> pressed using both Mouse provided by Apple and Track pad. Once the left >>>> button is pressed it need to be release to press the right button and vice >>>> versa. >>>> >>>> Thanks, >>>> Manajit >>>> >>>>> On 05-Jan-2018, at 7:08 AM, Semyon Sadetsky <semyon.sadet...@oracle.com >>>>> <mailto:semyon.sadet...@oracle.com>> wrote: >>>>> >>>>> Hi Manajit, >>>>> >>>>> I could reproduce similar behaviour on Linux when mouse is dragged to >>>>> another component with the left button pressed and then the right button >>>>> is immediately pressed. The popup is triggered by the same logic despite >>>>> it isn't configured for the component. >>>>> --Semyon >>>>> >>>>> On 01/04/2018 10:22 AM, Manajit Halder wrote: >>>>>> Hi Semyon, >>>>>> >>>>>> Fix for issue JDK-8080729 >>>>>> <https://bugs.openjdk.java.net/browse/JDK-8080729> has caused this >>>>>> regression due to changes in method setVisible(boolean visible) in file >>>>>> CPlatformWindow.java >>>>>> orderWindow is causing the issue here, if we revert to addChildWindow >>>>>> then the issue is not observed but then the fix for issue JDK-8080729 >>>>>> fails. >>>>>> Before this change the child window used to be added on to the parent as >>>>>> shown below in the commented code. But after the change child window is >>>>>> ordered above the parent. >>>>>> >>>>>> Below code causes the regression: >>>>>> >>>>>> CWrapper.NSWindow.orderWindow(ptr, CWrapper.NSWindow.NSWindowAbove, >>>>>> ownerPtr); >>>>>> //CWrapper.NSWindow.addChildWindow(ownerPtr, ptr, >>>>>> CWrapper.NSWindow.NSWindowAbove); >>>>>> >>>>>> Debugging further I found that if we use orderWindow then the new window >>>>>> is considered as new graphics device in the method notifyReshape in >>>>>> LWWindowPeer.java (the method updateGraphicsDevice() returns true) and >>>>>> is the difference between using orderWindow and addChildWindow. >>>>>> >>>>>> Since the option to add child window is between choosing oderWindow and >>>>>> addChildWindow we don’t have any option to do the fix in the Mac OS >>>>>> native code. >>>>>> >>>>>> Regards, >>>>>> Manajit >>>>>> >>>>>> >>>>>>> On 02-Jan-2018, at 11:30 PM, Semyon Sadetsky >>>>>>> <semyon.sadet...@oracle.com <mailto:semyon.sadet...@oracle.com>> wrote: >>>>>>> >>>>>>> Hi Manajit, >>>>>>> >>>>>>> JDK-8080729 bug was Mac OS specific issue and its fix changed the Mac >>>>>>> OS code only. Nevertheless you are suggesting to fix the regression in >>>>>>> generic code. This need to be explained somehow. >>>>>>> >>>>>>> --Semyon >>>>>>> On 12/25/2017 02:42 AM, Manajit Halder wrote: >>>>>>>> Hi Semyon, >>>>>>>> >>>>>>>> Regression is cause by JDK-8080729 >>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8080729>. The fix can’t be >>>>>>>> reversed since it is the choice between addChildWindow or orderWindow. >>>>>>>> Went through code flow related to the issue but didn’t find any other >>>>>>>> better place in code to handle this issue. The best way to fix the >>>>>>>> issue would be to avoid retargeting of events (MOUSE_ENTER and >>>>>>>> MOUSE_EXIT) between MOUSE_PRESS and MOUSE_RELEASE on the parent window >>>>>>>> (when the mouse is actually on the child window). Therefore request >>>>>>>> you to review the webrev.00. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Manajit >>>>>>>> >>>>>>>>> On 08-Dec-2017, at 9:55 PM, semyon.sadet...@oracle.com >>>>>>>>> <mailto:semyon.sadet...@oracle.com> wrote: >>>>>>>>> >>>>>>>>> Hi Manajit, >>>>>>>>> >>>>>>>>> Can you provide information which fix caused the regression? >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> On 12/8/17 5:53 AM, Manajit Halder wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Kindly review the following Swing fix. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189253 >>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8189253> >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/ >>>>>>>>>> <http://cr.openjdk.java.net/%7Emhalder/8189253/webrev.00/> >>>>>>>>>> >>>>>>>>>> Cause: >>>>>>>>>> Issue was due to retargeting of mouse enter exit events. >>>>>>>>>> MOUSE_ENTER and MOUSE_EXIT events were sent on the parent >>>>>>>>>> window (JFrame) in between MOUSE_PRESS and MOUSE_RELEASE events on >>>>>>>>>> the modeless JDialog. >>>>>>>>>> >>>>>>>>>> Fix: >>>>>>>>>> Retargeting of events is not done in-between MOUSE_PRESS and >>>>>>>>>> MOUSE_RELEASE. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Manajit >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
