Bug 1930374 Comment 12 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

We discussed this over Matrix, but to summarize:

 * The [codepath](https://searchfox.org/mozilla-central/rev/66aaf96f955d9bdc4bdb087a5075d5fbff2b9c8d/widget/windows/nsWindow.cpp#4139) where we "eat" a mouse event (do not create a `WidgetMouseEvent` for it and dispatch it to Gecko) is intended for cases where we previously received a **touch** event for the same user interaction, and dispatched _that_ to Gecko (as a `MultiTouchInput`, around [here](https://searchfox.org/mozilla-central/rev/66aaf96f955d9bdc4bdb087a5075d5fbff2b9c8d/widget/windows/nsWindow.cpp#6656)). The handling of the touch events ensures that e.g. a click (tap) on the close button is correctly processed.
 * For touch interactions over the non-client area, the native touch events are of a different type (`NCPOINTER` rather than `POINTER`) which we don't handle. To ensure that we react to these interactions, we need to either:
   * Ensure we **do** handle the corresponding mouse events. This is what bug 1736128 did for the `NCLBUTTONDOWN`, but for the scenario in this bug we'd need to extend that handling to the corresponding button-up (which for some reason is an `LBUTTONUP` rather than `NCLBUTTONUP`).
   * Or alternatively, start handling the native touch events (e.g. `NCPOINTER`) themselves (in which case the workaround added in bug 1736128 can likely be removed).
We discussed this over Matrix, but to summarize:

 * The [codepath](https://searchfox.org/mozilla-central/rev/66aaf96f955d9bdc4bdb087a5075d5fbff2b9c8d/widget/windows/nsWindow.cpp#4139) where we "eat" a mouse event (do not create a `WidgetMouseEvent` for it and dispatch it to Gecko) is intended for cases where we previously received a **touch** event for the same user interaction, and dispatched _that_ to Gecko (as a `MultiTouchInput`, around [here](https://searchfox.org/mozilla-central/rev/66aaf96f955d9bdc4bdb087a5075d5fbff2b9c8d/widget/windows/nsWindow.cpp#6656)). The handling of the touch events ensures that e.g. a click (tap) is correctly processed.
 * For touch interactions over the non-client area, the native touch events are of a different type (`NCPOINTER` rather than `POINTER`) which we don't handle. To ensure that we react to these interactions, we need to either:
   * Ensure we **do** handle the corresponding mouse events. This is what bug 1736128 did for the `NCLBUTTONDOWN`, but for the scenario in this bug we'd need to extend that handling to the corresponding button-up (which for some reason is an `LBUTTONUP` rather than `NCLBUTTONUP`).
   * Or alternatively, start handling the native touch events (e.g. `NCPOINTER`) themselves (in which case the workaround added in bug 1736128 can likely be removed).

Back to Bug 1930374 Comment 12