1979332 - Cursor rapid flickering on random places within the browser window when graphic tablet is used

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Jaroslav Haken [:Kraken]]

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

Steps to reproduce:

Graphic tablet connected, tablet drivers installed, Windows Ink disabled. Opening random webpage (Google search results for example) and scrolling down. Same thing happens when hovering mouse over opened browser tabs. Tested with many different webpages.

Actual results:

At some places the cursor shape starts to change rapidly (as if more processes are trying to change its current form). This temporarily slow down or freeze the browser and moving cursor is lagged.

This happens on random places, also when cursor hovers over the webpage name on tab in tab ribbon above the address bar.

Expected results:

Cursor should not flicker on unexpected places when graphic tablet is used.

Graphic tablet: Wacom Intuos PT S CTH-490 (upgrade to latest Wacom drivers did not make any difference)
Machine: Dell Latitude 5510 laptop
OS: Windows 11 24H2, build 26100.4652
Windows Ink: disabled
Firefox: 141.0 (64-bit)

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Bookmarks & History' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[David Parks [:handyman]]

The associated bug looks to me like a dupe. Chris, can you take a look and assign severity for these? Both appeared today. Neither says that the bug wasn't present in the past (pre-Fx141) but the timing suggests that is probable.

Comment 3

[Jaroslav Haken [:Kraken]]

(In reply to David Parks [:handyman] from comment #2)

Neither says that the bug wasn't present in the past (pre-Fx141) but the timing suggests that is probable.

At least in my case, this problem did not exist before the update to Firefox 141 with the same hardware and software setup.

Comment 4

[Jane]

Came here looking for cursor issues related to 141. My issue may be different but it shares the commonality of cursor weirdness + starting with FF141.

Since updating to FF141 (Win x64), after some varying amount of usage (within an hour or two of app starting) my browser will enter a bugged cursor state wherein the mouse cursor continually changes from its default "pointer" state into the OS text entry cursor.

Mousing over various page elements will bring back the normal cursor briefly but when the interactions stop it quickly reverts back into text entry mode. Also, when I mouse over a hyperlink the link-hand will appear for about a tenth of a second but then quickly revert back to the text entry cursor. Luckily clicking still functions normally; the error seems cosmetic only so far.

The wrong-cursor behavior persists until the browser is restarted, after which it will occur again after an unknown but relatively brief time.

Comment 6

[Chris Martin [:cmartin] - PTO back Oct 14]

Ooof this sounds pretty bad. Would either of you be willing to use the mozregression tool to try out a bunch of different Firefox commits and answer a yes/no question if you see the bad behavior or not?

This would help us immensely to narrow it down to the change that caused the issue.

Comment 7

[Q]

(In reply to Chris Martin [:cmartin] from comment #6)

Ooof this sounds pretty bad. Would either of you be willing to use the mozregression tool to try out a bunch of different Firefox commits and answer a yes/no question if you see the bad behavior or not?

This would help us immensely to narrow it down to the change that caused the issue.

I have tested using the tool, with last known good release 140 and first known bad build 141. And then it did not find any good build. Is there any specific test configuration you want to use?

Comment 8

[Pablo Couto]

Hi. I think I'm having the same issue. The description in comment 4 fits my experience, with the addition that the pointer sometimes disappears, and that when these issues occur, moving the pointer outside of the content area momentarily restores the pointer to normal.

I also have a Wacom tablet plugged in, although disconnecting it doesn't seem to resolve the issue.

One user from the related Reddit thread suggested setting dom.event.pointer.boundary.dispatch_when_layout_change to false, and this so far appears to reproducibly solve the issue for me.

I tried the mozregression tool, and, if I understand the log correctly, it appears to have centered on this change: https://phabricator.services.mozilla.com/D252781. This is the relevant part of the log:

2025-07-31T11:56:20.748000: INFO : Narrowed integration regression window from [fcd2f6bc, e502f712] (3 builds) to [fcd2f6bc, dd7642ee] (2 builds) (~1 steps left)
[...]
2025-07-31T11:56:22.770000: DEBUG : Found commit message:
Bug 1967878 - part 3: Make `PointerEventHandler` store the last mouse state instead of root `PresShell`s r=edgar

Comment 9

[Jane]

Glad to see forward progress on this. Thank you Pablo for running the regression tool.

Two things to add to my earlier comment 4:

First is that I have no Wacom tablet and never have. So it can happen without that.

Second is that I've more rarely observed the cursor defaulting into cursors other than the text entry cursor, so there's some dynamic element to this. Once it seemed stuck as the normal cursor (even in situations it shouldn't have been the normal cursor, like mousing over a hyperlink) and sometimes the cursor just seems to become invisible, most commonly when mousing over a YouTube video on YouTube.com.

Comment 10

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

Well, I've not reproduced this bug with Wacom Intuos CTL-6100WL. Could somebody sort out the STR? I'm not sure where should I put mouse cursor and what should I do with a pen tablet, and how to scroll the page?

Comment 11

[Alice0775 White]

Refer to https://www.reddit.com/r/firefox/comments/1m9v3rz/comment/n6i0fs2/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

There are also reports that XMouseButtonControl is causing problems.

Comment 12

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

Okay, I reproduced this bug with the following STR:

1. Go to https://d-toybox.com/studio/lib/pointing_device_event_viewer.html
2. Move mouse cursor over the red-dashed box
3. Hover the pen from bottom of the tablet and don't move into the read-dashed box.
4. Keep hovering over the event log table

Then, I see sometimes mouse boundary events are logged. They are oddly caused by mousemove whose preceding pointermove's pointerType is "mouse".

Comment 13

[Jane]

re: Comment 11
I am in fact a user of XMouseButtonControl. It was one of the first potential causes I thought of when the FF141 issues started happening but closing it briefly didn't seem to help.

Sounds like I should try closing it then restarting Firefox to see if the issues manifest in the new FF instance.

Comment 14

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

Oh, the STR in comment 12 requires another trigger to reproduce this bug. Hmm. When I hover the pen, the mousemove caused by a mouse is dispatched by nsWindow::DispatchMouseEvent(). That's unexpected result in the widget level (I'm still not sure whether this is unexpected OS level behavior).

Comment 15

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

Hmm, I don't reproduce this bug with the pen for Surface. So, there are 2 causes of this bug, one is our bug, the other is the odd behavior of Wacom tablet driver.

Comment 16

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

When I see odd mousemove while using tablet pen, the log shows:

[Child 84292: Main Thread]: D/MouseLocation [ps=1ae02ff9000]got eMouseMove on widget:1ae014a5000 at {87916, 22475} (pointerId=136, source=MOZ_SOURCE_PEN)
[Parent 80236: Main Thread]: D/MouseLocation [ps=295a3e6f000]got eMouseMove on widget:2959fe2c000 at {31586, 10302} (pointerId=0, source=MOZ_SOURCE_MOUSE)
[Parent 80236: Main Thread]: D/MouseLocation [ps=295a3e6f000]got eMouseMove on widget:2959fe2c000 at {96424, 32674} (pointerId=136, source=MOZ_SOURCE_PEN)
[Child 84292: Main Thread]: D/MouseLocation [ps=1ae02ff9000]got eMouseMove on widget:1ae014a5000 at {87916, 22506} (pointerId=136, source=MOZ_SOURCE_PEN)
[Child 84292: Main Thread]: D/MouseLocation [ps=1ae02ff9000]got eMouseMove on widget:1ae014a5000 at {28799, 2108} (pointerId=0, source=MOZ_SOURCE_MOUSE)
[Parent 80236: Main Thread]: D/MouseLocation [ps=295a3e6f000]got eMouseMove on widget:2959fe2c000 at {31586, 10302} (pointerId=0, source=MOZ_SOURCE_MOUSE)
[Parent 80236: Main Thread]: D/MouseLocation [ps=295a3e6f000]got eMouseMove on widget:2959fe2c000 at {96390, 32708} (pointerId=136, source=MOZ_SOURCE_PEN)
[Child 84292: Main Thread]: I/MouseLocation [ps=1ae02ff9000]synthesizing eMouseMove to (28799,2108) (pointerId=0, source=MOZ_SOURCE_MOUSE)
[Child 84292: Main Thread]: D/MouseLocation [ps=1ae02ff9000]got eMouseMove on widget:1ae014a5000 at {87885, 22537} (pointerId=136, source=MOZ_SOURCE_PEN)

The odd mousemove comes from the parent process...

Comment 17

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

Oh, the symptom which I saw in my test suite may be different from this bug. It seems that my symptom is caused by the tooltip of the web page. However, I don't see tooltips in the Google search result page.

Comment 18

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

Err, no, I confirmed that odd WM_MOUSEMOVE comes from OS.

Comment 19

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

I reproduce same bug on Chrome too. So, I believe that this is a bug of Wacom tablet driver. Although, I'll post a test build to avoid this bug.

Comment 20

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

Here is a demo:
data:text/html,<script>addEventListener("load", () => { for (let i = 0; i < 200; i++) document.body.appendChild(document.createElement("div")); })</script><style>div { height: 32px; transition: background-color 1s ease; } div:hover { background-color: lightblue; }</style>)

I think when you see the cursor flicker, in this demo, you'll frequently see the highlit where the last mouse cursor position which you moved with the real mouse device and the current cursor position which you hover the pen over the tablet.

Comment 21

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

Attachment: Bug 1979332 - part 1: Add logging code of synthesizing `ePointerMove` r=edgar!,#dom-core

Comment 22

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

Attachment: Bug 1979332 - part 2: Filter out `WM_MOUSEMOVE` messages which are for temporarily restoring the mouse cursor r=#win-reviewers!,#dom-core

It seems that Wacom tablet driver sometimes synthesizes WM_MOUSEMOVE
at last mouse cursor location set by a real mouse while the pen tablet
overrides the mouse cursor position with its pen's position.

Currently, we ignore mouse move events from any input sources ("mouse"
and "pen") if the position is exactly same as the position of the last
dispatched eMouseMove.

Additionally, we should ignore mouse moves if the input source is
"mouse" and the position of the last dispatched eMouseMove caused by
the last WM_MOUSEMOVE.

NOTE: I tried to write a test using
nsIWidget::SynthesizeNativeMouseEvent and
nsIWidget::SynthesizeNativePenInput. However, I couldn't synthesize
a mousemove whose inputSource is "pen" and anyway,
SynthesizeNativeMouseEvent does not support to check the situation [1].

1. https://searchfox.org/mozilla-central/rev/820596a140570007ce22a6c137ce2520676cfffe/widget/windows/nsWindow.cpp#6186-6189

Comment 23

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

Oh, and I found another issue. Wacom's pen tablet notifies new pointerId when I leave the pen from the tablet and enter the tablet again. Then, both the main process and the child process do not remove the pointerId from sActivePointersIds. Therefore, if you use the table a lot in a browsing session, Gecko will have a too big hashtable.

Comment 24

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

Attachment: Bug 1979332 - part 3: Add logging code of `sActivePointersIds` r=edgar!,#dom-core

Comment 25

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

Attachment: Bug 1979332 - part 4: Make `EventStateManager::PreHandleEvent` notify `PointerEventHandler` of `eMouseExitFromWidget` if it sets the message to `eVoidEvent` r=edgar!,#dom-core

Currently, we remove a pointer from sActivePointerIds when

• eMouseExitFromWidget in EventStateManager::PostHandleEvent
• ePointerUp or ePointerCancel of a touch

However, EventStateManager::PreHandleEvent sets
eMouseExitFromWidget message to eVoidEvent if the pointer exits from
the toplevel widget or the puppet widget. Therefore,
EventStateManager::PostHandleEvent does not work for
eMouseExitFromWidget. Therefore, PreHandleEvent should do it
instead.

Comment 26

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

• x86
• x86_64
• Arm64

Could you check whether these test builds fix this bug in your environments? Thanks.

Comment 27

[Q]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #26)

• x86
• x86_64

Could you check whether these test builds fix this bug in your environments? Thanks.

I feel like this time firefox is recognize the tablet as touch instead of as mouse like in version 140. In the past the behavior had suddenly switched several times between mouse and touch, but I feel handling as in version 140 was just right for me.
Right now, I don't see any flickering, but if I hover my pen on a hyperlink and then lift the pen, the hyperlink is defocused and the URL at the bottom of the window doesn't show anymore.
One behavior that improved for me is that when I switch to telegram tab, I can paste stuff into the chat right away without having to tap once within the chat area first. That behavior was broken for me in version 141.
I'm using wacom CTH-301 which has no wacom driver.

Comment 28

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

Thank you for your testing!

(In reply to Q from comment #27)

I feel like this time firefox is recognize the tablet as touch instead of as mouse like in version 140.

I don't understand well, though. Gecko handles pen input as "pen". However, yes, it's similar to touch while your pen touches the tablet/digitizer. On the other hand, the pen doesn't touch the tablet/digitizer but hovers over that, it's handled like a mouse.

"pen" is always managed as a pen, not a mouse because it has a specific pointerId at least until it leaves from the tablet/digitizer.

Previously, we managed pointer events' boundary state only for the last active one, but started for preceding ones too. Therefore, if there are a lot of active pointers, the performance after a layout change or a scroll may get worse. However, it basically not happen, even in the realistic worst case, there could be a couple of pens and mouse at most. On the other hand, if Gecko fails to manage pointers left from active document, there could be a lot of zombie pointers and make the damege to the performance.

Right now, I don't see any flickering,

Thanks, the second patch tries to ignore the odd native mouse move messages coming from OS. They caused the flicker since the last active pointer is continuously switched between the last used pen and the mouse, and that caused hovering position is continuously changed between their last positions. Therefore, even if the cursor is not changed, CPU power is wasted to consider which content is under the last active pointer again and again.

but if I hover my pen on a hyperlink and then lift the pen, the hyperlink is defocused and the URL at the bottom of the window doesn't show anymore.

Good point... I think it's expected behavior from the code written for mouse point of view. Although we could make the behavior better for pen users.

One behavior that improved for me is that when I switch to telegram tab, I can paste stuff into the chat right away without having to tap once within the chat area first. That behavior was broken for me in version 141.

I think it's not related. The test builds are based on yesterday's nightly build, i.e., alpha of 143. So, various other fixes are also included.

I'd like to get more feedback from a couple of other users too before requesting review...

Comment 29

[Q]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #28)

I don't understand well, though. Gecko handles pen input as "pen". However, yes, it's similar to touch while your pen touches the tablet/digitizer. On the other hand, the pen doesn't touch the tablet/digitizer but hovers over that, it's handled like a mouse.

This is what I mean

• On firefox 140, when I long-hold on an image (=right click), firefox shows a denser version of the menu, similar to what you get when you right click with mouse (https://imgur.com/a/huho9NN)
• On your test build, when I long-hold on an image, firefox shows the bigger version of the menu, similar to what you get on touchscreen (https://imgur.com/a/O2S4G24)
• On firefox 140, I highlight text by double-tap on a word and start dragging right away (https://streamable.com/g60r9p)
• On your test build, I highlight text by double-tap on a word, release the pen and drag the marker (https://streamable.com/rd1wxp)

Comment 30

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

(In reply to Q from comment #29)

• On firefox 140, when I long-hold on an image (=right click), firefox shows a denser version of the menu, similar to what you get when you right click with mouse (https://imgur.com/a/huho9NN)
• On your test build, when I long-hold on an image, firefox shows the bigger version of the menu, similar to what you get on touchscreen (https://imgur.com/a/O2S4G24)

Thanks for the clarification, but I'm not sure why the test build changed the behavior. As far as I've checked, long press of a pen is handled as a contextmenu event in ourselves, not coming from OS. So, it depends on how our active pan and zoom control (APZC) receives the last trigger event. Oddly, the bigger menu is enabled only when the source event is a touch. So, it seems that it was intentionally changed, or is being changed (waiting for shipping) or a bug of APZC...

• On firefox 140, I highlight text by double-tap on a word and start dragging right away (https://streamable.com/g60r9p)
• On your test build, I highlight text by double-tap on a word, release the pen and drag the marker (https://streamable.com/rd1wxp)

Odd. I cannot reproduce it. The draggable selection range icons are called as "accsssible caret". They should appear only when the event source is touch by default.

• https://searchfox.org/mozilla-central/rev/2a8a30f4c9b918b726891ab9d2d62b76152606f1/layout/base/PresShell.cpp#8416-8421
• https://searchfox.org/mozilla-central/rev/2a8a30f4c9b918b726891ab9d2d62b76152606f1/layout/base/PresShell.cpp#771-776

When pen is pressed long time, indeed, we use a touch sequence and scroll by default. So, it's possible to trigger that, but I don't reproduce it. I guess you don't install the Wacom driver. That's the reason. I don't know why you don't use it, you can disable them from prefs:

• starting to scroll when pen is pressed long time and move
• showing accsessible caret by touch
• hiding accessible caret at mouse input
• enable accessible caret always

Comment 31

[Q]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #30)

When pen is pressed long time, indeed, we use a touch sequence and scroll by default. So, it's possible to trigger that, but I don't reproduce it. I guess you don't install the Wacom driver. That's the reason. I don't know why you don't use it, you can disable them from prefs:

• starting to scroll when pen is pressed long time and move
• showing accsessible caret by touch
• hiding accessible caret at mouse input
• enable accessible caret always

Okay, sorry, I just realized that my current behavior can only replicated on my current profile. Once I switch to another profile on the same firefox 140, the behavior changes to be the same as in your test build. So please assume that the comparisons in my previous posts are unreliable.

And about wacom driver, CTH-301 has no wacom driver, it's just a plug-and-play device.

Comment 33

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

(In reply to Q from comment #31)

And about wacom driver, CTH-301 has no wacom driver, it's just a plug-and-play device.

Thanks, I didn't know that.

Comment 35

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

New test builds:

• x86_64
• Arm64
• x86

Comment 36

[mzzla.20.tuner]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #35)

New test builds:

• x86_64
• Arm64
• x86

@masayuki: I tested the x86_64 build (about:support reports Firefox 143.0a1 build 20250806011904).

Short summary: the issue is still present.

Things I did:

1. Unplug tablet, start test build, open https://tqdm.github.io/docs/tqdm/, place cursor ~in the middle (so that it will pass over text while scrolling), scroll with my touchpad.
   Result: cursor is unaffected by scrolling. This means it will not change unless after the scrolling stops it is over a text area.
2. Plug in tablet, start test build, open https://tqdm.github.io/docs/tqdm/, place cursor ~in the middle (so that it will pass over text while scrolling), scroll with my touchpad.
   Result: cursor is unaffected by scrolling. This means it will not change unless after the scrolling stops it is over a text area.
3. Plug in tablet, start test build, open https://tqdm.github.io/docs/tqdm/, place cursor ~in the middle (so that it will pass over text while scrolling), scroll with my tablet.
   Result: cursor is affected by scrolling. This means it will rapidly change between text and pointy cursor even a short amount of time after the scrolling stops.
4. Continue with https://tqdm.github.io/docs/tqdm/, place cursor ~in the middle (so that it will pass over text while scrolling), scroll with my touchpad.
   Result: cursor is affected by scrolling. This means it will rapidly change between text and pointy cursor even a short amount of time after the scrolling stops. Note that this is caused by the scrolling with the touchpad. If I just wait there is no rapid cursor change.
5. Wait for a roughly one minute. Continue with https://tqdm.github.io/docs/tqdm/, place cursor ~in the middle (so that it will pass over text while scrolling), scroll with my touchpad.
   Result: cursor is unaffected by scrolling. This means it will not change unless after the scrolling stops it is over a text area.
6. Continue on page about:support. Use tablet for scrolling.
   Result: cursor is affected by scrolling. This means it will rapidly change between text and pointy cursor even a short amount of time after the scrolling stops.

Other observations:

• The effect also happens when hovering with the mouse over the opened tabs
• It seems to build up over time - while a short interaction with the tablet seems to "wear off" more usage will consistently produce the effect also over longer periods of time

I did two profiling sessions:
(1) Not affected session
Tablet was not used after the start of Firefox.
https://share.firefox.dev/40SO4FD

(2) Affected session
Use the tablet to scroll around for maybe 15 seconds.
In the session only the touchpad was used to move the cursor and scroll around.
https://share.firefox.dev/4mx6151

Anything else I can help with to pinpoint the issue?

Comment 37

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

Thank you for your test. Sounds like basically you don't have major problems with the test build, right?

However, I wonder, it's the interesting case that the last mouse cursor was specified by a pen, but scrolling with touchpad without native mouse move. I think I need to check the behavior but it shouldn't block to fix this bug.

Comment 38

[mzzla.20.tuner]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #37)

Thank you for your test. Sounds like basically you don't have major problems with the test build, right?

However, I wonder, it's the interesting case that the last mouse cursor was specified by a pen, but scrolling with touchpad without native mouse move. I think I need to check the behavior but it shouldn't block to fix this bug.

No, there were no major problems with the test build but it didn't fix the problem.

Comment 39

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

(In reply to mzzla.20.tuner from comment #38)

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #37)

Thank you for your test. Sounds like basically you don't have major problems with the test build, right?

However, I wonder, it's the interesting case that the last mouse cursor was specified by a pen, but scrolling with touchpad without native mouse move. I think I need to check the behavior but it shouldn't block to fix this bug.

No, there were no major problems with the test build but it didn't fix the problem.

Oh? Really? Hmm, anyway, I'll land the patches, and let's clone this bug to fix the remaining issues if there are.

Comment 40

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

Ah, you filed bug 1981343 and marked as a dup of this bug. So, if you still see the bug on your side, feel free to reopen bug 1981343 (i.e., your bug report).

Comment 41

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/05022d5218a8
https://hg.mozilla.org/integration/autoland/rev/d09cc56e9866
part 1: Add logging code of synthesizing `ePointerMove` r=edgar
https://github.com/mozilla-firefox/firefox/commit/672ba0896ced
https://hg.mozilla.org/integration/autoland/rev/8fdf6c76f1c6
part 2: Filter out `WM_MOUSEMOVE` messages which are for temporarily restoring the mouse cursor r=dom-core,win-reviewers,edgar,gstoll
https://github.com/mozilla-firefox/firefox/commit/e5a6115fece8
https://hg.mozilla.org/integration/autoland/rev/3083b7770e2d
part 3: Add logging code of `sActivePointersIds` r=edgar,dom-core
https://github.com/mozilla-firefox/firefox/commit/2c07754dd22f
https://hg.mozilla.org/integration/autoland/rev/bb0918ef6fa3
part 4: Make `EventStateManager::PreHandleEvent` notify `PointerEventHandler` of `eMouseExitFromWidget` if it sets the message to `eVoidEvent` r=edgar,dom-core

Comment 42

[Jane]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #35)

New test builds:

• x86_64

Thank you.

I'm one of the non-Wacom, no-tablet users but do use X-Mouse Button Control. I've been using the test build all day and so far the problem has not reoccurred. Fingers crossed.

When fixes are accepted, will they not hit Firefox main release channel until FF143? Wondering how long I should "run ahead" of the mainstream version. Cheers.

Comment 43

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

(In reply to Jane from comment #42)

I'm one of the non-Wacom, no-tablet users but do use X-Mouse Button Control. I've been using the test build all day and so far the problem has not reoccurred. Fingers crossed.

Thank you for your testing!

When fixes are accepted, will they not hit Firefox main release channel until FF143? Wondering how long I should "run ahead" of the mainstream version. Cheers.

Today, I landed the patches. So, it'll be shipped starting form 143. In 142, the release drivers already WONTFIX'ed in the flags. So, unless the number of reproducible environments is much increased by something changed outer, 143 will be the first version of that. 143 will be shipped on September 16. So, I recommend to use beta 143 which will be shipped on August 19. I think you can use Firefox sync to migrate your normal profile to the beta profile.

Comment 44

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

(On the other hand, I'm not sure why you guys think bug 1967878 started making the cursor flickering. The root cause is odd behavior of the external app or driver (or Windows itself). Therefore, that should've already been reproducible even before the fix of bug 1967878. The patches for bug 1967878 indeed may made the pointing device handling at a scroll or a layout change slower, so, is the slow down causing the flickering?? That does not make sense, there might be another reason which I've not found.)

Comment 45

[mzzla.20.tuner]

[:masayuki]: I didn't get if the test build you provided should have fixed the rapid flickering of the cursor (it didn't). So from my perspective the cause is not yet solved. Even with the current behavior of the tablet drivers the issue was not present in the past. I first noticed it recently and it basically prevents me from using FF with my tablet which is my only real pointing device. If somebody tells me how to bisect FF versions I could find the version that introduced the rapid flickering. As you seem to view bug #1981343 as independent I will reopen it and continue the discussion there if not advised otherwise.

Comment 46

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/d09cc56e9866
https://hg.mozilla.org/mozilla-central/rev/8fdf6c76f1c6
https://hg.mozilla.org/mozilla-central/rev/3083b7770e2d
https://hg.mozilla.org/mozilla-central/rev/bb0918ef6fa3

Comment 47

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

FYI: This bug will be used to manage regressions caused by the 4 patches. Therefore, do not comment here like "I still reproduce this bug". Instead, comment in bug 1981343 with attaching a log file, see bug 1981343 comment 5 for getting how to get the log file.

Comment 49

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

Well, probably, the odd mouse move events are not synthesized by the Wacom driver, but it may be caused by Windows itself. The intermittent failure of bug 1967609 is caused by similar mysterious pointer move events during synthesizing native touch events by ourselves.

Comment 50

[Jaroslav Haken [:Kraken]]

I can confirm that v143.0 (latest version installed today) fixed this problem for me.

Thank you very much for the support and for keeping Mozilla product awesome!