Spastic scrolling using Firefox HTML5 Client causes client to no longer paint

[J. Max Mena]

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.

[J. Max Mena]

Okay, after a couple minutes I'm now seeing these prints fill up the serverside prints:

2017-07-20 16:03:59,499 Warning: delayed region timeout
2017-07-20 16:03:59,499  region is 15 seconds old, will retry - bad connection?
2017-07-20 16:03:59,499  81 late responses:
2017-07-20 16:03:59,499   136 jpeg: 449s
2017-07-20 16:03:59,499   137 jpeg: 449s
2017-07-20 16:03:59,500   138 scroll: 449s
2017-07-20 16:03:59,500   139 jpeg: 449s
2017-07-20 16:03:59,500   140 jpeg: 449s
2017-07-20 16:03:59,500   141 jpeg: 449s
2017-07-20 16:03:59,500   142 jpeg: 449s
2017-07-20 16:03:59,500   143 jpeg: 449s
2017-07-20 16:03:59,500   144 jpeg: 449s
2017-07-20 16:03:59,501   145 png: 449s
2017-07-20 16:03:59,501   146 jpeg: 448s
2017-07-20 16:03:59,501   147 rgb32: 448s
2017-07-20 16:03:59,501   148 jpeg: 448s
2017-07-20 16:03:59,501   149 png: 448s
2017-07-20 16:03:59,501   150 png: 448s
2017-07-20 16:03:59,501   151 jpeg: 448s
2017-07-20 16:03:59,502   152 scroll: 448s
2017-07-20 16:03:59,502   153 jpeg: 448s
2017-07-20 16:03:59,502   154 jpeg: 448s
2017-07-20 16:03:59,502   155 jpeg: 448s
2017-07-20 16:03:59,502   156 rgb32: 448s
2017-07-20 16:03:59,502   157 rgb32: 448s
2017-07-20 16:03:59,502   158 rgb32: 448s
2017-07-20 16:03:59,502   159 rgb32: 448s
2017-07-20 16:03:59,503   160 rgb32: 447s
2017-07-20 16:03:59,503   161 rgb32: 447s

[Antoine Martin]

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.

[Antoine Martin]

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)

[J. Max Mena]

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.

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/1593