Firefox for Android still actively responds to WebSocket messages when on background
Categories
(Core :: DOM: Networking, defect, P2)
Tracking
()
People
(Reporter: saschanaz, Assigned: acreskey)
References
Details
(Whiteboard: [necko-triaged][necko-priority-queue])
(Filing as defect as this affects battery usage. Not sure where to file this, but let me start with necko team)
- Set up a local Deno server with the following script (sends websocket message every second):
Deno.serve((req) => {
if (req.headers.get("upgrade") != "websocket") {
return new Response(`
<!DOCTYPE html>
<div id="log"></div>
<script>
const onmessage = () => {
log.prepend(document.createElement("br"))
log.prepend(Date.now())
}
const setup = () => {
log.prepend(document.createElement("br"))
log.prepend(Date.now() + " connecting websocket");
socket = new WebSocket("/");
socket.onmessage = onmessage;
socket.onclose = setup;
socket.onerror = setup;
}
setup();
</script>
`, {
headers: {
"content-type": "text/html"
}
});
}
const userAgent = req.headers.get("user-agent")
const { socket, response } = Deno.upgradeWebSocket(req);
socket.addEventListener("open", () => {
console.log(`a client connected! ${userAgent}`);
});
const handle = setInterval(() => {
socket.send("ping");
}, 1000)
socket.addEventListener("close", () => {
console.log(`a client disconnected! ${userAgent}`)
clearTimeout(handle);
});
return response;
});
- Access the page on Firefox for Android and Chrome for Android
- Either turn off the screen or switch to other apps (e.g. start Slacking 🙂)
Expected: Throttling should happen as in Chrome. The page either:
- After some time logs the same timestamp multiple times, which means websocket messages are throttled instead of being processed real time)
- The page reloads (not sure why?)
Actual: The log says the processing happens realtime for all messages
Both browsers disconnects from the server if the screen is off for some time. Turning on the screen triggers reconnection only on Firefox.
|
Reporter | |
Comment 1•1 year ago
|
||
This probably affects Mastodon and Misskey where new posts are streamed through websocket.
|
|
Reporter | |
Comment 2•1 year ago
|
||
The same throttling doesn't happen on Chrome when switching to other tabs, interesting.
|
||
Comment 3•1 year ago
|
||
Need to find out how often Chrome processes network inputs, and how they do so
|
Assignee | |
Updated•4 months ago
|
|
|
Assignee | |
Comment 4•4 months ago
|
||
Running the same local Deno server with the latest Fenix nightly on my Samsung A54 this is what I'm:
Firefox connects and we see the log of timestamps.
When I switch apps on the device, the websocket connection is broken within 5-10 seconds:
from the server:
a client disconnected! Mozilla/5.0 (Android 16; Mobile; rv:149.0) Gecko/149.0 Firefox/149.0
This is the same behaviour I see in Chrome:
a client disconnected! Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Mobile Safari/537.36
Locking the screen also has the same effect -> client is disconnected.
In both Fenix 149 and Chrome mobile.
:saschanaz, can you re-run this test and tell me what you're seeing?
|
|
Assignee | |
Comment 5•4 months ago
•
|
||
On my older Pixel 6, (Android 12), I'm seeing that the websocket connection to both Fenix 149 and Chrome persists after changing apps.
Constant stream of updates from the server:
[1771433484295] sending ping
[1771433485298] sending ping
[1771433486299] sending ping
[1771433487301] sending ping
I would say that I'm not seeing evidence of throttling in either browser on this device.
edit:
After an extended period, both Fenix and Chrome will ultimately disconnect from the server if the screen is locked.
|
|
Reporter | |
Comment 6•4 months ago
|
||
On Android 16 on Galaxy S22 Ultra I can confirm that Firefox 147/149 now disconnects on switching app.
But something is broken, when it reconnects after switching back, somehow it creates two connections instead of one. Switching back and forth again, it becomes 4. And then 8. This doesn't happen on Chrome.
|
|
Assignee | |
Comment 7•4 months ago
|
||
(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #6)
On Android 16 on Galaxy S22 Ultra I can confirm that Firefox 147/149 now disconnects on switching app.
But something is broken, when it reconnects after switching back, somehow it creates two connections instead of one. Switching back and forth again, it becomes 4. And then 8. This doesn't happen on Chrome.
Yes - I see the same difference between Fenix and Chrome when backgrounded against this the test server.
But I believe it's because the test page creates new Websocket connections for both socket.onclose and socket.onerror
const setup = () => {
log.prepend(document.createElement("br"))
log.prepend(Date.now() + " connecting websocket");
socket = new WebSocket("/");
socket.onmessage = onmessage;
socket.onclose = setup;
socket.onerror = setup;
}
And Fenix is closing the connection with an error (and a close always follows, which is correct).
Chrome handles this as a close, without an error.
As far as I can tell, Fenix firing both onerror and onclose isn't incorrect per the spec, but please log in a separate bug if you feel otherwise.
I propose we close this bug as 'worksforme'
|
|
Reporter | |
Comment 8•4 months ago
|
||
Fair. Feel free to open the new bug yourself.
Description
•