1976088 - REGRESSION: Firefox loses stylus tilt/rotation data during pointermove events (broken in versions after 139.0.4)

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[t_madjar]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36

Steps to reproduce:

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0

1. Use a pressure-sensitive stylus with tilt/rotation support (tested with Wacom pen)
2. Open any web application that reads pointer events with tilt/rotation such as https://patrickhlauke.github.io/touch/tracker/multi-touch-tracker-pointer-hud.html or https://patrickhlauke.github.io/touch/pen-tracker/
3. Tilt the stylus to a specific angle and rotate the barrel
4. Draw a continuous stroke (pointerdown → multiple pointermove → pointerup)
5. Log the raw event properties: event.tiltX, event.tiltY, event.twist

Actual results:

• Events 1-3: Correct tilt/rotation values (e.g., tiltX: 16, tiltY: 10, twist: 294)
• Events 4-N: All zeros (tiltX: 0, tiltY: 0, twist: 0)
• Final event: Often returns correct values again
• Pressure values work correctly throughout - only tilt/rotation are affected

Expected results:

• All pointermove events should report accurate, continuously-changing tilt/rotation values
• Values should reflect the actual physical stylus orientation throughout the stroke
• Behavior should match Chrome/Edge which maintain accurate data consistently

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Events' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Hsin-Yi Tsai (she/her)[:hsinyi]]

Hi Masayuki, do you see this issue? (You have a stylus device so you are able to test this, don't you?) Thanks.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Well, I have CTL-6100WL and I set up the latest driver and test roughly. Then, I can manage reproduce this bug. However, Chrome/Edge also print them as 0. So, the output are exactly same on any major browsers on Windows.

Reporter, do you really see non-zero values on Chrome/Edge? If you saw non-zero values before, didn't you update the driver? I guess it's a driver's or Windows' regression or something.

Comment 4

[t_madjar]

Attachment: Firefox_v139-0-4_64bit.png

As you see, Firefox v 139.0.4 records the Tilt and Rotation correctly (non-zero values)

Comment 5

[t_madjar]

Attachment: Firefox_v140-0-4_64bit.png

As you see, Firefox v140.0.4 does not record the Tilt and Rotation correctly (all zeros)

Comment 6

[t_madjar]

Attachment: Chrome_v138-0-7204-97_64bit.png

Chrome records the Tilt and Rotation/twist correctly (non-zero values)

Comment 7

[t_madjar]

Attachment: Edge_v138-0-3351-83_64bit.png

Edge records the Tilt and Rotation/twist correctly (non-zero values)

Comment 8

[t_madjar]

Attachment: Wacom_IntuosProM_PTK670_Driver-6-4-10-3.png

My Wacom hardware and driver (latest driver)

Comment 9

[t_madjar]

I do see non-zero values on Chrome/Edge. I attached screen captures of this. I am using the newest Wacom driver, and can recreate this issue with this driver. Can't be a Windows regression because I can recreate this issue now on both Win 10 and latest 11 version, on two different computers. Only the latest Firefox (v140) returns zeros for TiltX TiltY and Barrel Rotation. Firefox v139 records these values correctly.
I only tested this with the latest Wacom Intuos Pro tablet with the two latest drivers, and can recreate this issue. I am using Art Pen because only this pen can record Barrel Rotation/Twist.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, even with older than Firefox 139, I don't see non-zero values on Firefox with CTL-6100WL. I guess it does not support tilt nor twist.

Could you find a regression point with mozregression? Specifying the URL of the first window to the test page makes the check easier/faster.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Ah, tilt is supported only by Intuos Pro.

Comment 12

[t_madjar]

Attachment: mozregression.png

Comment 13

[t_madjar]

It looks like it broke here based on Mozregression (screen capture attached):
app_name: firefox
build_date: 2025-05-15
build_file: C:\Users\Tibor.mozilla\mozregression\persist\2025-05-15--mozilla-central--firefox-140.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2025/05/2025-05-15-23-03-42-mozilla-central/firefox-140.0a1.en-US.win64.zip
changeset: 80cc20e2740dfb72182d95e0ca08ab925fbba341
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c0650552f3ca8cff6a781188f6b287b84dd04328&tochange=80cc20e2740dfb72182d95e0ca08ab925fbba341
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

Comment 14

[t_madjar]

Attachment: Mozregression.log

Comment 15

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you.

However, the result is odd. It seems that bug 1550462 or bug 1960253 is the regressor...

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

t_madjar: Do you reproduce this bug with disabling dom.events.coalesce.touchmove pref from about:config? It could be that we fail copying Touch to dispatch the touch input in the next animation frame because I touched there to make the Touch is copied instead of reused in bug 1550462.

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oh, the pref needs to be enabled/disabled before opening the tab to check it.

Comment 18

[t_madjar]

If dom.events.coalesce.touchmove = False than the Tilt and Twist is recorded correctly.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you! Then, the buggy point is now found!

Comment 20

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1976088 - Make the copy constructor of `dom::Touch` call the copy constructor of `WidgetPointerHelper` r=smaug!,#dom-core

Surprisingly, the copy constructor does not call WidgetPointerHelper,
so, WidgetPointerHelper members have not been copied by the copy
constructor.

This patch adds a debug prefs to set various values to tiltX, tiltY,
and twist to pen input because those features are supported only by
expensive models. Therefore, it's hard to check the bug like this.

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/912973eef5e9
https://hg.mozilla.org/integration/autoland/rev/b7831ebbdf6f
Make the copy constructor of `dom::Touch` call the copy constructor of `WidgetPointerHelper` r=dom-core,edgar

Comment 22

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/b7831ebbdf6f

Comment 23

[Thorin [:thorin]]

widnows ?