#1593 closed defect (fixed)
Spastic scrolling using Firefox HTML5 Client causes client to no longer paint
Reported by: | J. Max Mena | Owned by: | J. Max Mena |
---|---|---|---|
Priority: | major | Milestone: | 2.2 |
Component: | html5 | Version: | trunk |
Keywords: | Cc: |
Description
While doing some testing I found that over aggressive scrolling using Firefox as an HTML5 client (running Firefox remotely) causes the client to stop painting. The server shows prints that it's still receiving damages and sending them, and the client gets prints like normal, but no paints. All I see is a frozen window with leftover debug prints. I'll attach a screenshot of what I'm seeing, but the logs are really really inconclusive.
To repro:
- Start up a session (I used
xpra start :13 --bind-tcp=0.0.0.0: --start-new-commands=yes --start-child=firefox --start-child=xterm --no-daemon --start-via-proxy=no
)
- Go to a website in Firefox
- The Fedora Magazine homepage is just fine - https://start.fedoraproject.org
- Scroll spastically
Currently I'm using a trunk r16434 server/client and Firefox 52 - both client and server machines are running Fedora 25.
Attachments (1)
Change History (6)
Changed 5 years ago by
Attachment: | Xpra HTML No Paints.png added |
---|
comment:1 Changed 5 years ago by
comment:2 Changed 5 years ago by
Status: | new → assigned |
---|
I do see something odd with Firefox, though I couldn't reproduce the "delayed region timeout".
It looks like the paint events are queued somewhere and they just accumulate. To get them processed, moving the pointer around the window is enough and it starts catching up.
comment:3 Changed 5 years ago by
Owner: | changed from Antoine Martin to J. Max Mena |
---|---|
Status: | assigned → new |
I did see it once as per comment:2, but now I am unable to reproduce it. Typical Heisenbug.
I do get the occasional spinners if I scroll up and down like a madman, and things are falling behind a little bit - but never enough to cause real problems.
So I took a look at the code and found some potential explanations for the stuck display:
- maybe we didn't refresh the window after paint errors
- maybe some paint errors were getting lost, leaving the window in a paint-locked state
r16440 should fix both of these problems.
Another potential problem was how we use time, as this can also go backwards in Javascript (same as #1470 for python), so r16441 does a similar thing for Javascript and also adds a sanity check for the paint-lock (#1432): if it stays locked for more than 2 seconds, we free it. (it is only meant to prevent out-of-order paints - staying locked forever is much worse)
If you can still reproduce it, please capture the Javascript console output with debug enabled around the time of the problem, and please try to see if:
- moving the pointer around helps or not
- other windows are immune to the problem? (that this isn't a global client problem but a per-window locking issue)
- that maybe this only occurs with png and/or jpeg encodings and not rgb (or the other way around)
comment:4 Changed 5 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Upped server to r16446
I'm unable to reproduce this exact same issue, but I have gotten a number of
client crashes - will file a new ticket and close this one.
comment:5 Changed 17 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1593
Okay, after a couple minutes I'm now seeing these prints fill up the serverside prints: