1981343 - Cursor flickering and FF unresponsive on most pages when using Wacom tablet

Status: UNCONFIRMED

(Core :: DOM: Events, defect)

Description

[mzzla.20.tuner]

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

Steps to reproduce:

In FF 141.02, with a Wacom Intuos CTH-690/K on Windows 10.0.19045 I open github.com (but it happens on most other pages as well). I then scroll on the page.

Actual results:

As soon as I start to scroll the mouse cursor will start flickering between the text and the pointer cursor. Depending on the duration I use the tablet the flickering will go on for seconds to minutes. During the flickering the website will become irresponsive and will not load new content anymore.
Behavior continues even when I unplug the tablet and stops after a few minutes. If I use the trackpad after that the problem does not reoccur. It starts again when using the tablet.
The Firefox nightly 143.0a1 (2025-08-04) (64-bit) shows the same problem.

Expected results:

Scrolling should not produce a myriad of cursor change events that block FF?

Comment 1

[mzzla.20.tuner]

The bug was also filed here.

Comment 2

[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 3

[mzzla.20.tuner]

I just noticed that it is sufficient to interact with a website to trigger the problem. For example clicking a link. Moving the cursor is not sufficient to trigger the problem (or it vanishes fast enough to not be visible).

Comment 5

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

Although the fix of bug 1979332 has not been contained in the latest nightly build. Could you attach a log file or part of the log if it's too big to attach to this bug?

Steps to get the log:

1. First wait for appearing the symptom
2. Open about:logging in a new tab
3. Set the input field for Log module selection to PointerLocation:4,ActivePointers:4,sync,timestamp
4. Select Logging to a file of Logging output and set the path to log file, then, press Set Log File button
5. Press Start Logging button
6. Now, starts logging. Go to the previous tab and reproduce the symptom for a while (10 sec or less)
7. Then, back to the about:logging tab and press Stop Logging button

Then, you should see 2 log files (if you enter the pointer over another <iframe> coming from external web site like an ad, 3 or more files may appear). One is a log of the parent process and the other is a log of the content process (if you see multiple content process files, please attach the biggest one). Attach only the log file of the content process, but please preserve the log file of the parent process. If I see odd events coming from the parent process, I'll request it too.

Note that the logger will put a lot of lines per native pointer move event. Therefore, be careful the file size, you cannot attach too big file to bugzilla and it's too difficult to investigate too big log file because it becomes unclearer where is the problem occurred.

The nightly build will be available here:

• installer
• zip (x86_64)
• zip (arm64)

Even if you install Nightly, it does not overwrite Firefox release/beta installs. And Nightly will use its own profile. Therefore, you can run it safe from the release/beta build's profile point of view, and you can import the daily use profile via Firefox Sync.

(FYI: It is a national holiday in Japan on Monday so that I'll be back on Tuesday.)

Comment 6

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

Sorry, I forgot that PointerLocation does not work in the opt builds. I'll make test builds which can log that.

Comment 7

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

Here are new test builds:

• x86_64
• arm64
• x86

Comment 8

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

Note for myself:

• Here may not enough if ePointerMove is not a preceding event of eMouseMove. That could cause pointer leaks in the remote process because it won't receive eMouseExitFromWidget which is the only event to delete the pointer from sActivePointerIds if the input source is "mouse" or "pen".
• Ditto

Comment 9

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

With investigating the STR reported in bug 1980636, I found unexpected cursor setting. So, cursor flickering would be fixed in bug 1980636.

On the other hand, I'm still unsure that whether the victims of the regression still see the highly usage of CPU. I guess it's already fixed by bug 1979332 because it fixes kicking new reflow (layout) at every odd native mouse message and that should've wasted the CPU resource.