<AWT Dev> [8] Review Request: JDK-8025585 Win: Popups in JFXPanel do not receive MouseWheel events

[Petr Pchelko]

Hello, Anthony.

Sorry for the delay, I've got distracted by other fixes. Here's an updated version of the fix:
http://cr.openjdk.java.net/~pchelko/8025585/webrev.01/

> So I think we should ignore the SendMessage's return value and always return TRUE here because the message has already been processed by the target toolkit. What do you think?
Indeed in case an other toolkit would return false here we would get quite inconsistent behaviour. So I've updated the fix to always return TRUE.

With best regards, Petr.

On 02.10.2013, at 20:41, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Petr,
> 
> The new version looks better. However, there's still one minor issue:
> 
>> 1528                     return ::SendMessage(hWndForWheel, msg.message, mouseWParam, mouseLParam);
> 
> The PreProcessMouseMsg() function to which this line belongs should return a boolean value indicating whether the event must be processed (FALSE) or silently consumed (TRUE). The ::SendMessage() returns the result of calling a WndProc() for the target window when it processes the message, which we really don't care about here. And regardless of the result, I don't think that AWT should process the message any further after it's been redirected to the target toolkit.
> 
> So I think we should ignore the SendMessage's return value and always return TRUE here because the message has already been processed by the target toolkit. What do you think?
> 
> --
> best regards,
> Anthony
> 
> On 10/02/2013 05:33 PM, Petr Pchelko wrote:
>> Hello, Thank you for the review.
>> 
>>> It really seems to be an issue. We need another check that hWndForWheel belongs to the current process, and doesn't sent the event to this window, if it doesn't.
>> That was indeed an issue. I've got used to Mac behaviour and did not notice the problem.
>> 
>> The new version of the fix is available here:
>> http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/
>> 
>> Now we redispatch the wheel event only if the window is in the same process.
>> 
>> With best regards. Petr.
>> 
>> On Oct 1, 2013, at 9:54 PM, Artem Ananiev <artem.ananiev at oracle.com> wrote:
>> 
>>> 
>>> On 10/1/2013 9:17 PM, Anthony Petrov wrote:
>>>> Hi Petr,
>>>> 
>>>> MS Windows always sends WHEEL events to the focused window. And my
>>>> testing shows that when you scroll the wheel outside of an AWT window,
>>>> the scroll events are consumed (by AWT, supposedly).
>>>> 
>>>> With your fix you seem to always redirect the events to the window under
>>>> the mouse. Now suppose you have a 3rd-party window with a scroll bar in
>>>> background (e.g. Windows Explorer). If an AWT window is currently
>>>> focused, but you move the mouse pointer outside of it and above the
>>>> Explorer window, and start scrolling, will the Explorer window scroll
>>>> its contents? Currently it doesn't. What about if we apply your fix?
>>> 
>>> It really seems to be an issue. We need another check that hWndForWheel belongs to the current process, and doesn't sent the event to this window, if it doesn't.
>>> 
>>> Thanks,
>>> 
>>> Artem
>>> 
>>>> --
>>>> best regards,
>>>> Anthony
>>>> 
>>>> On 09/27/2013 07:24 PM, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>> 
>>>>> Please review the fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8025585
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/
>>>>> 
>>>>> The fix is needed for JFXPanel support. We need to redispatch
>>>>> MOUSEWHEEL messages to the window under mouse. In case of Popups in a
>>>>> JFXPanel the HWND belongs to a different tollkit, so we need to use
>>>>> ::SendMessage to redispatch the message.
>>>>> 
>>>>> With best regards. Petr.
>>>>> 
>>