1675414 - With WebRender enabled, when pressing arrow keys in scrollable textarea, text cursor doesn't move until it blinks

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect)

Description

[nyanpasu64]

Attachment: firefox textarea bug.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

I've seen this issue on Windows and Linux, and it occurs in clean/dirty profiles only with WebRender enabled (gfx.webrender.enabled/all).

• Open a website with a textarea.
• Type enough text into the textarea so a scrollbar appears.
• Press arrow keys or Ctrl+Arrow keys.

Actual results:

If you press an arrow key with the cursor visible, it remains in place until it disappears, remains invisible for 1 second, and then reappears in the right position corresponding to the arrow keys pressed. If you press an arrow key while the cursor is invisible, it reappears immediately.

The issue persists when you unfocus/refocus the textarea, switch tabs, or duplicate the tab.

Expected results:

Pressing arrow keys repaints the text cursor's position, regardless if it's visible or invisible in the flash cycle.

Unfortunately this bug is very inconsistent. Not all textareas trigger the bug (for example Bugzilla doesn't).

I've attached a file that reproduces the bug on my machine (Arch Linux running KDE with Yaru GTK theme, at 125% DPI scaling, both clean and dirty Firefox profiles), but may not work on others. Even on this page, I've managed to make the bug not occur by typing into the form state, which persists across reloads, until I pressed Enter in the address bar. And the bug no longer occurs if I delete some HTML elements located above the textarea.

Comment 1

[Dzmitry Malyshau [:kvark]]

Jeff, this sounds like an annoying issue for users. I'm not seeing this effect on Linux/NV with WR. However, I did experience something similar previously when writing long-ish github comments. Will try to reproduce some more.
Do you know how we are triggering a refresh with regards to user input?

Comment 2

[nyanpasu64]

I tried my attached HTML file on Windows, on Firefox 82.0.2 (64-bit) (slightly outdated). The first time I tried it, the bug did not show up. On my second test hours later, the bug does occur (but the faster flash cycle with 0.5 seconds visible/hidden makes the bug harder to follow). However I do not get the bug in private windows or a clean profile.

Could there be a possible connection to saved form state? I don't know if it seems connected.

Comment 3

[Glenn Watson [:gw]]

I was able to reproduce locally, thanks for the excellent test case!

mozregression points to the change in [1]. I was able to confirm that this does affect whether the bug occurs. However, that patch is unrelated, it just exposes an existing bug. Patch coming shortly which fixes the underlying issue.

[1] https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=99a82cb34de1fb50533829a271506d94da191744&tochange=3afdf3a5bec4902b80f5e67d93ca9f7f9f12edbd

Comment 4

[Glenn Watson [:gw]]

Attachment: Bug 1675414 - Fix incorrect skipping of composites in some cases.

In the following circumstances, WR was failing to detect a
composite was required:

• There is a picture cache slice that is smaller than a single tile.
• The position of that picture cache slice is changed.
• No other content invalidations occur.

This clip rect in the composite descriptor must include the
device_valid_rect rather than the tile device_rect. This ensures
that in the case of a picture cache slice that is smaller than a
single tile, the clip rect in the composite descriptor will change
if the position of that slice is changed. Otherwise, WR may conclude
that no composite is needed if the tile itself was not invalidated
due to changing content.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dd3121343b47
Fix incorrect skipping of composites in some cases. r=nical

Comment 6

[Cosmin Sabou [:CosminS]]

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

Comment 8

[Bogdan Maris, Desktop Test Engineering]

I tried to reproduce this on my machine both on Windows 10 and Ubuntu 18 with webrender enabled but I could not reproduce using an old Nightly and 82.0.2 so I can't verify this is fixed. nyanpasu64 or Glenn could you please verify this is fixed using latest Firefox beta version?
https://www.mozilla.org/en-US/firefox/channel/desktop/

Comment 10

[Glenn Watson [:gw]]

Yes, I can confirm that this is working correct for me with the current beta.

Comment 11

[Bogdan Maris, Desktop Test Engineering]

(In reply to Glenn Watson [:gw] from comment #10)

Yes, I can confirm that this is working correct for me with the current beta.

Thanks so much, marking this as Verified fixed.

Comment 12

[nyanpasu64]

IIRC I'm not getting the bug working, but I'm no longer on the same font configuration so I'm not sure, and I don't have Firefox 84 around to test. Anyway the bug's been verified, so I'll just clear the needinfo request.