1758357 - Cursor blinks/disappears on OnlyOffice since FF92 on Acer Laptop

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect, P2)

Description

[Merome]

Attachment: Video Capture of the bug

Steps to reproduce:

• Open a OnlyOffice Sheet with FF92 or later on an Acer TravelMate P215-53 under Windows 10 (sample file here : https://cloud.agglo-montbeliard.fr/index.php/s/rDnrymiPMjamANf )
• Move the mouse over the cells of the sheet

Actual results:

The cross cursor is blinking disappearing while the mouse move. When you stop moving the mouse, the cross cursor is visible.

Expected results:

The cursor should be visible during mouse moves, as it was/it is with :

• All precedent versions of Firefox on this Acer TravelMate P215-53 (FF 91.02 is the last functional version tested)
• All other browsers tested on this same machine (no problem with Edge, Chrome...)
• Firefox 92 and later on this same machine but with Ubuntu instead of Windows 10
• All other combination of machine/OS/browser

Summary :

The problematic combination is :
FF 92 and later + Acer Travel Mate P215-53 + Window 10

If you change any of this parameter, it works again. Note that all of our Acer Travel Mate P215-53 are affected, not only one machine. We have dozens of those and OnlyOffice is our Office Suite :/

Comment 1

[Merome]

Workaround : active mouse trail in windows parameters

[HKEY_CURRENT_USER\Control Panel\Mouse]
"MouseTrails"="2"

Comment 2

[Hani Yacoub, Desktop QA]

I Couldn't reproduce the issue on a Dell G5 on latest Firefox versions, as described in the description it seems only reproducible on Acer TravelMate P215-53.
I will set "Core: Layout" component, it could be a good starting point so the engineering team could take a look at this issue.

Comment 3

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

The severity field is not set for this bug.
:emilio, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Without being able to reproduce this seems pretty hard to make progress on, but the fact that it only repros on Windows smells like this is probably an issue at the Widget level.

Reporter, since we can't repro but you mentioned this working on versions prior to 92, is there any chance you could run mozregression on that machine to see what change introduced the issue on Firefox's side?

Thanks.

Comment 5

[Merome]

I will try to do that and post results here. Thanks for your work.

Comment 6

[Merome]

Mozregression is a fantastic tool !

It found that the correction of Bug #1724120 caused the regression on this particular machine. As it's related to a mouse cursor issue, it seems to be a good guess.

Tell me if I can help further.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Interesting! Let me check what could cause that...

Comment 8

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

Set release status flags based on info from the regressing bug 1724120

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1758357 - Fix PuppetWidget::SetCursor to avoid sending cursor updates to the parent process over and over. r=dholbert,mstange,mhowell

I accidentally regressed this in bug 1705877, so we'd always
force-update the cursor :(

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1758357 - Don't call SetCursor redundantly on Windows. r=mhowell,cmartin

Bug 1724120 apparently regressed this, which is a bit surprising because
the redundant ::SetCursor() call is already there. The real fix is the
one above, however I think this change is still worth it. Make cursor
updates avoid redundant ::SetCursor() calls the same way other widget
back-ends do (always except for mUpdateCursor, which is set on scale
changes and so on).

Depends on D141863

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9269074 [details]
Bug 1758357 - Fix PuppetWidget::SetCursor to avoid sending cursor updates to the parent process over and over. r=dholbert,mstange,mhowell

Beta/Release Uplift Approval Request

• User impact if declined: Moving the mouse and specially custom cursors will cause a lot of extra IPC messages.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Custom cursors keep working, which they should.
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): One-liner that was removed on bug 1705877 accidentally.
• String changes made/needed: none

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Trivial one-liner.
• User impact if declined: none
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Trivial one-liner

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7649fcd2f281
Fix PuppetWidget::SetCursor to avoid sending cursor updates to the parent process over and over. r=mstange

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2d5dc5c2afd8
Don't call SetCursor redundantly on Windows. r=cmartin

Comment 14

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/7649fcd2f281

Comment 15

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/2d5dc5c2afd8

Comment 16

[Donal Meehan [:dmeehan]]

Comment on attachment 9269074 [details]
Bug 1758357 - Fix PuppetWidget::SetCursor to avoid sending cursor updates to the parent process over and over. r=dholbert,mstange,mhowell

Approved for 99.0b8. Thanks.

Comment 17

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/c598a609660e

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9269074 [details]
Bug 1758357 - Fix PuppetWidget::SetCursor to avoid sending cursor updates to the parent process over and over. r=dholbert,mstange,mhowell

Approved for 91.8esr.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/d277a0b059e9

Comment 20

[Donal Meehan [:dmeehan]]

Uplift in comment 17 was not the attachment originally requested.
Uplifted the correct patch after confirming both attachment 9269074 [details] and attachment 9269075 [details] were ok for a beta uplift
https://hg.mozilla.org/releases/mozilla-beta/rev/a341dea87dd8

Comment 21

[Emilio Cobos Álvarez (:emilio)]

Can we back out from beta the accidentally uplifted patch https://hg.mozilla.org/releases/mozilla-beta/rev/c598a609660e for causing bug 1761408? It's probably trivial to fix but I'd rather let it ride the trains normally.

Comment 22

[Donal Meehan [:dmeehan]]

:emilio I will back this out in the next uplift batch, coming shortly. Thanks for the information.

Comment 23

[Emilio Cobos Álvarez (:emilio)]

Thanks! (Sorry Donal, would've ni?d you but your ni?s were blocked :))

Comment 24

[Daniel Bodea [:danibodea]]

I've attempted reproduction with Nightly v92.0a1 20210712215604 and Release v92.0 on both Window 10 and Ubuntu 20/22 and aarch64 build on Yoga. I could not observe any issues like the one described. Seems to be specific to the system it was reported on.

Comment 25

[Donal Meehan [:dmeehan]]

Backed out the patch from attachment 9269075 [details] for causing bug 1761408
https://hg.mozilla.org/releases/mozilla-beta/rev/7213cc30753b

Comment 26

[Monica Chiorean]

Merome, since we we do not have Acer environment can you please confirm whether issue is still reproducing on your side on latest Beta (https://archive.mozilla.org/pub/firefox/candidates/)? Thank you.

Comment 27

[Merome]

I've just tried 101.0b9 (64 bits) on a problematic Laptop, and it's a success : problem is solved in this version.
Many thanks to all developers involved in this issue.

Comment 28

[Monica Chiorean]

Marked as verified, based on comment#27.