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

Artem Ananiev artem.ananiev at oracle.com
Tue Oct 8 05:30:01 PDT 2013


On 10/8/2013 2:01 PM, Petr Pchelko wrote:
> 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/

Looks fine.

Thanks,

Artem

>> 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.
>>>>>>
>>>
>


More information about the awt-dev mailing list