<Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse scroll

[Prasanta Sadhukhan]

On 6/20/2017 10:36 AM, Prasanta Sadhukhan wrote:
> I also thought about it and thought of removing cancelPopupMenu 
> altogether first but decided not to remove it and added this 
> conditions (in case there are some conditions which we are not 
> thinking of)
>
> ((src instanceof JWindow) && ((JWindow)src).isVisible())
>                     || ((src instanceof JMenuItem) && 
> ((JMenuItem)src).isVisible())
>                     || (src instanceof JFrame))
>
> I am not sure in which case it should execute cancelPopupMenu in mouse 
> -wheel events. If you want, I can remove this "case".
>
It seems if (c instanceof Applet || c instanceof Window) [although not 
Popup#HeavyWeightWindow which is a JWindow] then cancelPopMenu will be 
executed.
> Regards
> Prasanta
> On 6/19/2017 7:59 PM, Sergey Bylokhov wrote:
>> The fix added a number of checks to exclude execution of 
>> «cancelPopupMenu» on MOUSE_WHEEL, so I wonder in which situations we 
>> should execute cancelPopupMenu?
>>
>>> Fair enough suggestion, modified webrev to never ungrab for wheel event
>>>
>>> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.02/
>>>
>>> Regards
>>> Prasanta
>>> On 6/16/2017 9:37 PM, Semyon Sadetsky wrote:
>>>> They are related to a wheel event happend in another java window 
>>>> (not outside the app).
>>>> My questions is if we do not ungrab on wheel event outside the app 
>>>> should we be consistent and do never ungrab on wheel event?
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 06/16/2017 08:49 AM, Prasanta Sadhukhan wrote:
>>>>> I was not sure about the scenario at what condition those ungrabs 
>>>>> are sent, so I did not modify those. For wheel event outside our 
>>>>> java window was the scenario here and my modification fixed that.
>>>>>
>>>>> // According to the specification of UngrabEvent, post it
>>>>>    // when press occurs outside of the window and not on its owned 
>>>>> windows
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 6/16/2017 8:57 PM, Semyon Sadetsky wrote:
>>>>>> In lines 2337 and 2345 ungrab is also sent. Shouldn't the button 
>>>>>> number be checked there as well before ungrab?
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 06/16/2017 03:22 AM, Prasanta Sadhukhan wrote:
>>>>>>> Yes, it is failing in linux as it posts a UngrabEvent which 
>>>>>>> causes the popup to be closed in BasicPopupMenuUI at eventDispatched()
>>>>>>>
>>>>>>> if(ev instanceof sun.awt.UngrabEvent) {
>>>>>>>                 // Popup should be canceled in case of ungrab event
>>>>>>>                 cancelPopupMenu( );
>>>>>>>                 return;
>>>>>>>             }
>>>>>>> I have modified to not post the ungrab event if mouse wheel is 
>>>>>>> rotated by checking if button 4 or 5 is pressed or not.
>>>>>>> as per 
>>>>>>> https://stackoverflow.com/questions/15510472/scrollwheel-event-in-x11 
>>>>>>>
>>>>>>> and
>>>>>>> ftp://www.x.org/pub/X11R6.8.0/doc/mouse.4.html [Wheel button 
>>>>>>> events (typically buttons 4 and 5) are usually used for scrolling]
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.01/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 6/15/2017 8:55 PM, Semyon Sadetsky wrote:
>>>>>>>> On 06/15/2017 08:18 AM, Prasanta Sadhukhan wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 6/15/2017 8:40 PM, Semyon Sadetsky wrote:
>>>>>>>>>> On 06/14/2017 09:54 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>>> Hi Semyon,
>>>>>>>>>>>
>>>>>>>>>>> I tried on Firefox and other app. If popup or drop down menu 
>>>>>>>>>>> is opened, then mouse wheel rotation is not closing the 
>>>>>>>>>>> popups. In our case, it is closing the popups/menus.
>>>>>>>>>> That is true. I meant you fixed only the case when the mouse 
>>>>>>>>>> wheel rotation is over java windows (wheel event's source != 
>>>>>>>>>> null). What will be if the wheel is rotated outside java 
>>>>>>>>>> (source == null), or it is not the case?
>>>>>>>>>>
>>>>>>>>> It is not closing in other app (if it rotated over non-app 
>>>>>>>>> window) as well as in our java with my fix.
>>>>>>>> Did you check this on all platforms? At least on my Ubuntu it 
>>>>>>>> is not so.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>>> --Semyon
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta
>>>>>>>>>>> On 6/14/2017 8:26 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>> Hi Prasanta,
>>>>>>>>>>>>
>>>>>>>>>>>> I may be wrong, but it seems to me that the standard 
>>>>>>>>>>>> behavior is when any wheel event cannot close popups.
>>>>>>>>>>>>
>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 06/13/2017 10:39 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review a fix for an issue whereby it is seen
>>>>>>>>>>>>> hitting the scroll wheel by accident closes whole 
>>>>>>>>>>>>> structure of context menus causing it to disappear and the 
>>>>>>>>>>>>> user has to invoke the menu again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Issue was popupMenu is getting closed for mouse wheel 
>>>>>>>>>>>>> rotation if the menu is not from JComboBox.
>>>>>>>>>>>>> If the context menu is opened from JMenuItem, JMenu then 
>>>>>>>>>>>>> if the mouse wheel is rotated anywhere in frame, then it 
>>>>>>>>>>>>> calls cancelPopupMenu() causing it to call 
>>>>>>>>>>>>> setVisible(false) and so menu disappears.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Proposed fix is to check if the mouse wheel rotation is 
>>>>>>>>>>>>> done in JMenu, JMenuItem or anywhere in frame, then if 
>>>>>>>>>>>>> popup is present, then do not close the popupmenu.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
>>>>>>>>>>>>> webrev: 
>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>>
>