1986188 - Broken hand icon for url/button/etc

Status: UNCONFIRMED

(Core :: Widget: Win32, defect)

Description

[Ilya]

Attachment: 1.gif

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

Steps to reproduce:

On Firefox 141+ hovering over items that should force the cursor into a hand - url's, buttons, other elements.

Standalone installations of 140, Nightly, Beta or Waterfox shows no issues. Standalone 141+ has the issue.

Actual results:

Sometimes browser shows the hand and stays the hand.

Most of the time, especially after at least some activity ( 1-5 mins of usage ), it only appears for half a second or less, turns into default pointer cursor

Expected results:

It should stay a hand

Comment 1

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

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

Comment 2

[Greg Stoll :gstoll]

Hmm, I'm not able to reproduce this. Could you run mozregression to see when this was introduced? Also, could you paste the contents of about:third-party here? It's possible a third-party DLL is causing this. Thanks!

Comment 3

[Ilya]

Attachment: about-third-party

Comment 4

[Ilya]

Attachment: record-third-party-about-linked.gif

Comment 5

[Ilya]

Just sanity checking, this is firefox 142 with the linked about third-party. Extensions are installed but all are disabled. Reocurred after watching a youtube video, switching between different pages after about a minute or two after restarting the browser.

Comment 6

[Ilya]

Attachment: mozregression log

Comment 7

[Ilya]

Attachment: mozgression gui

Comment 8

[Ilya]

I can only be sure about "bad" verdicts, since the process is not foolproof. I usually spent 2 minutes watching a youtube video in background and in foreground, while scrolling/clicking content on other forums. Usually the issue is noticeable in first 30 seconds. The last 2 verdicts were around 10s into the testing.

Comment 9

[Greg Stoll :gstoll]

Thanks! Did mozregression produce a textual pushlog that lists the commits that are in that range?

Comment 10

[Ilya]

Here is the last (bad) build info, if this is what you meant

app_name: firefox
build_date: 2025-06-30 17:56:35.161000
build_file: C:\Users\Ilya.mozilla\mozregression\persist\1e474f87fb10-shippable--autoland--target.zip
build_type: integration
build_url: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/IdoHaDb0Q7GfYlC4tL-tbw/runs/2/artifacts/public%2Fbuild%2Ftarget.zip
changeset: 1e474f87fb109999db0030c4c916636d2732051d
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=77082e6a537a9021ae32c6797d9eb0c659a5e737&tochange=1e474f87fb109999db0030c4c916636d2732051d
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: IdoHaDb0Q7GfYlC4tL-tbw

Comment 11

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

Setting Regressed by field after analyzing regression range found by mozregression in comment #10.

Comment 12

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

:mak, since you are the author of the regressor, bug 1971994, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 13

[Marco Bonardo [:mak]]

I don't think it's even possible for my patch (replacing a stack variable with an owned pointer) to cause any of this, I suspect the regression range is wrong.
Maybe the issue is intermittent? Otherwise the only thing I could think about is some timing shift of the scheduler or the binary optimization... but that'd be odd.

Did you repeat the regression range check multiple times and it always confirmed that?

Comment 14

[Ilya]

Unfortunately i couldn't capture it after another attempt. What's even more annoying is that it was bugged in my current browser session. After a while away, restarting the PC in the same time period, i can now not replicate even in original firefox browser for about half an hour.
I've responded just to give response, but i'll monitor over the next few days, or maybe even a few hours for it to reoccur.

I can only be certain that the mogzilla regression route above had no false positives. There might be false negatives in the good results that made this point our to your commit.
I'm not certain what the procedures you have for this sort of thing so i'll just wait for response, if any.

Based on my current findings, we can rule out this at least

BAD 1aac6e358474c66f3d56d54be23b7e214cf051e6
GOOD 140