Currently, if we enable dom.w3c_pointer_events.dispatch_by_pointer_messages, we handle WM_POINTER* message for pen input, and we dispatch mouse event for it, https://searchfox.org/mozilla-central/rev/446160560bf32ebf4cb7c4e25d7386ee22667255/widget/windows/nsWindow.cpp#8629. But with this, we hit bug 1345398, because of drag and drop. What Chrome does is - Generate touch event for WM_POINTER* messages, https://source.chromium.org/chromium/chromium/src/+/master:ui/views/win/pen_event_processor.cc;l=101;drc=2f11470d7ad8963a9add116df64d2edd1b85d3a4?originalUrl=https:%2F%2Fcs.chromium.org%2F - And if any button (other than the first button) is pressed, then generate mouse event instead, https://source.chromium.org/chromium/chromium/src/+/master:ui/views/win/pen_event_processor.cc;l=77-89;drc=2f11470d7ad8963a9add116df64d2edd1b85d3a4?originalUrl=https:%2F%2Fcs.chromium.org%2F Another pointer is that if we don't handle WM_POINTER* messages, OS actually generates WM_TOUCH messages for pen input. So generate touch event for WM_POINTER* messages WM_POINTER* seems to make sense, this also aligns with what we behave now, but with more accurate information. What do you think?
Bug 1637259 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Currently, if we enable dom.w3c_pointer_events.dispatch_by_pointer_messages, we handle WM_POINTER* message for pen input, and we dispatch mouse event for it, https://searchfox.org/mozilla-central/rev/446160560bf32ebf4cb7c4e25d7386ee22667255/widget/windows/nsWindow.cpp#8629. But with this, we hit bug 1345398, because of drag and drop. What Chrome does is - Generate touch event for WM_POINTER* messages, https://source.chromium.org/chromium/chromium/src/+/master:ui/views/win/pen_event_processor.cc;l=101;drc=2f11470d7ad8963a9add116df64d2edd1b85d3a4?originalUrl=https:%2F%2Fcs.chromium.org%2F - And if any button (other than the first button) is pressed, then generate mouse event instead, https://source.chromium.org/chromium/chromium/src/+/master:ui/views/win/pen_event_processor.cc;l=77-89;drc=2f11470d7ad8963a9add116df64d2edd1b85d3a4?originalUrl=https:%2F%2Fcs.chromium.org%2F Another point is that if we don't handle WM_POINTER* messages, OS actually generates WM_TOUCH messages for pen input. So generate touch event for WM_POINTER* messages WM_POINTER* seems to make sense, this also aligns with what we behave now, but with more accurate information. What do you think?
Currently, if we enable dom.w3c_pointer_events.dispatch_by_pointer_messages, we handle WM_POINTER* message for pen input, and we dispatch mouse event for it, https://searchfox.org/mozilla-central/rev/446160560bf32ebf4cb7c4e25d7386ee22667255/widget/windows/nsWindow.cpp#8629. What Chrome does is - Generate touch event for WM_POINTER* messages, https://source.chromium.org/chromium/chromium/src/+/master:ui/views/win/pen_event_processor.cc;l=101;drc=2f11470d7ad8963a9add116df64d2edd1b85d3a4?originalUrl=https:%2F%2Fcs.chromium.org%2F - And if any button (other than the first button) is pressed, then generate mouse event instead, https://source.chromium.org/chromium/chromium/src/+/master:ui/views/win/pen_event_processor.cc;l=77-89;drc=2f11470d7ad8963a9add116df64d2edd1b85d3a4?originalUrl=https:%2F%2Fcs.chromium.org%2F Another point is that if we don't handle WM_POINTER* messages, OS actually generates WM_TOUCH messages for pen input. So generate touch event for WM_POINTER* messages WM_POINTER* seems to make sense, this also aligns with what we behave now, but with more accurate information. And we still need to find a way to deal with drag and drop (bug 1345398). What do you think?