User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20160319124722 Steps to reproduce: I recently bought a fast desktop computer (running Arch Linux). Because Firefox can use a lot of RAM and CPU, when browsing the web on my laptop I find it faster to 'ssh' into the desktop and run Firefox remotely, using only the local X server. This usually works very well. I've noticed a couple of issues, however. Actual results: The most annoying thing is that whenever I open a page with video content (often by accident), the whole browser becomes unresponsive. It may take a minute before it responds to my request (via Ctrl-W or clicking on the close box) to close the tab. Meanwhile it keeps playing the video. I just noticed media.autoplay.enabled and will try setting it to 'false' as a workaround. Expected results: Note that the video plays fine (minus audio) and the connection to the X11 server is on a LAN, so it's unlikely that there is a problem with network bandwidth. More like something about how X events are being queued and processed, I don't know. Thank you!
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
You probably need gigabit Ethernet to make it work in any reasonable fashion.
When using a remote X server it may help to be more aggressive about uploading textures to the X server and compositing them remotely. You might need to write a patch yourself if you want it fixed.
Priority: -- → P5
Why would gigabit Ethernet help? As I said, video plays without glitches. The connection is via 'ssh', so it's not like TCP packets are being dropped because of video traffic - all the data goes sequentially on one stream. Is there some kind of buffer for outgoing display updates, which is too large or which is getting filled up too far in advance? Are there incoming events which are filling up an event queue so the button event has to wait? Note there are X11 functions like XMaskEvent which allow us to prioritize the receipt of certain events. I could agree that this might be a low priority bug, but it seems like more of a buffering issue than a network speed issue.
You need to log in before you can comment on or make changes to this bug.