xpra icon
Bug tracker and wiki

Opened 4 months ago

Closed 4 months ago

#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
  • 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)

Xpra HTML No Paints.png (555.4 KB) - added by J. Max Mena 4 months ago.

Download all attachments as: .zip

Change History (5)

Changed 4 months ago by J. Max Mena

Attachment: Xpra HTML No Paints.png added

comment:1 Changed 4 months ago by 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

comment:2 Changed 4 months ago by Antoine Martin

Status: newassigned

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 4 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena
Status: assignednew

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)
Last edited 4 months ago by Antoine Martin (previous) (diff)

comment:4 Changed 4 months ago by J. Max Mena

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.