Hi, fellow Firefox user!
I’m sorry to bother you, but this is important...
-
Firefox sometimes doesn’t send data. This breaks PingGraph.
-
On some machines (Windows laptops?), any user input (moving your cursor, typing on your keyboard) causes
WebSocket.bufferedAmountto increase endlessly. -
This is unfixable and results in incorrect measurements while f.e. playing osu!, even if the browser window isn’t focused!
-
This is beyond frustrating. WS buffering is a normal thing as per spec, but this is a horrible browser quirk.
-
Your displayed ping might be much worse than what it really is.
-
Web browsers allow websites to perform multithreaded, high performance tasks in the background using the Worker API.
-
Intensive tasks on the main thread (rendering…
Hi, fellow Firefox user!
I’m sorry to bother you, but this is important...
-
Firefox sometimes doesn’t send data. This breaks PingGraph.
-
On some machines (Windows laptops?), any user input (moving your cursor, typing on your keyboard) causes
WebSocket.bufferedAmountto increase endlessly. -
This is unfixable and results in incorrect measurements while f.e. playing osu!, even if the browser window isn’t focused!
-
This is beyond frustrating. WS buffering is a normal thing as per spec, but this is a horrible browser quirk.
-
Your displayed ping might be much worse than what it really is.
-
Web browsers allow websites to perform multithreaded, high performance tasks in the background using the Worker API.
-
Intensive tasks on the main thread (rendering and user interactions) shouldn’t impact any background threads, unless your device can’t keep up at all.
-
... except on Firefox, where drawing too many squares causes background worker threads to lag behind. Given that
WebSocket.onmessageseems to run very late in that situation, I wonder if both this and the earlier buffering issue are quirks caused by how Firefox handles networking events internally. -
PPS should be exactly 100, not fluctuating.
-
setIntervalis unreliable on Firefox. It’s not meant to be accurate in any browser, but the only other alternative is meant for animation, not networking. -
I had to come up with my own ugly workarounds to keep PPS somewhat close to 100 on FF. The current version uses
Math.random()on top of two timeouts with the magic number of 15.3ms. -
The graphics might glitch. Epilepsy warning here.
-
CanvasRenderingContext2Dsometimes draws squares not according to spec. Lines are supposed to be centered to half-pixels, but Firefox doesn’t care. But only sometimes. -
Firefox 133.0 should fix this.. hopefully. It also happened on Linux though, but in any case, I hope my workaround will hold up.
-
... but even with newer versions of Firefox, the screen can glitch and flicker uncontrollably in ways which may possibly trigger seizures for people with photosensitive epilepsy.
-
Overlay Mode (Picture in Picture) is weird.
-
There are no plans to implement the PiP WebAPI because Mozilla are happy with their own limited PiP feature. The relevant bug (1463402) has been closed as WONTFIX years ago with zero updates to it oh hey, there’s a Request for Mozilla Position for the new Document PiP API.
-
In their own words from 2020: "Firefox’s implementation has a number of distinct advantages over Chrome’s approach"
-
This one makes me laugh. Yeah, sure, I guess not implementing it at all is a distinct advantage. /s
-
I’m stubborn enough to at least give FF users the best alternative I can. Sorry not sorry for the unique user experience!
-
But how? (tech details, PC only)
-
Firefox shows a PiP button in some videos of size 140x140 or larger. I’m styling the video element to hide itself, while positioning it in such a way that you’ll click on the invisible button. This is beyond nasty, but hey, it works for now.
-
The user can move the PiP button to the left side, or disable it outright, which breaks that workaround.
-
It fires two non-standard events on the video element:
-
MozTogglePictureInPicture, which is barely documented and implied to be "chrome-only" (not Google Chrome, but XUL Chrome). But oops, content JS can listen for it too. -
MozStopPictureInPicture, which isn’t even documented at all and is yet another leaky implementation detail. And opposed to the toggle event, this one only fires if the user exits PiP from the video element itself - not when the PiP window gets closed! -
Content JS cannot toggle PiP via those events, as Firefox check the
isTrustedproperty ("did the user actually click on the button, or is the page lying?"). -
Firefox doesn’t let websites know how big the PiP window is, meaning that scaling needs to be configured manually.
I want Firefox to succeed, so this all hurts to see. I’m trying to keep this as functional as I can in FF. I also know that Mozilla is in a pickle in 2017 2020 2024 CURRENT YEAR, and thus other things are prioritized over this (hopefully the Mozilla graveyard won’t grow much more). Maybe someone at Mozilla ends up using this as a TODO list, or maybe Servo ends up magically catching up. But for now, if you want to use this, please be aware of that list of bugs.
Maybe open the page in another browser and install it as a PWA or something, idk.
settings
Graphics Sound Effects Volume
%
about
This tool is just a basic ping graph, monitoring the latency and packet loss of your internet connection. Compared to something like Speedtest by Ookla, which is ideal for measuring how big your internet pipe is ("how fast can I download / upload?"), this tool is great for measuring how stable your internet pipe is ("can I play games / join voicechat / watch streams without problems?").
It uses a handful of servers around you to measure latency via TCP (time delay), and the server this website is hosted on to measure packet loss via UDP (connection stability).
keyboard
-
+and-to zoom in and out,0to reset zoom. -
Por double-click to toggle overlay mode. -
Por double-click to toggle overlay mode. -
Not supported in your browser.
meanings
-
b buf: Bytes Buffered (sending) -
= 0b is best - your device can send data flawlessly.
-
> 0b means that your device needs to process other data first.
-
PPS: Pings Per Second (network) -
= 100pps is best - one square is 10ms.
-
Fluctuations usually mean your device is busy.
-
FPS: Frames Per Second (display) -
Higher is better... in games.
-
If PingGraph uses too much power, turn on powersaving mode to reduce FPS.
-
ms: Milliseconds (1/1000 of a second) -
Consistency is good to avoid stuttering and errors.
-
Lower is better. A tickrate of 64 = one tick every ~15ms.
-
TCP: Reliable internet (web data) -
= 100% is best.
-
< 100% means some connection is failing.
-
UDP: Low latency internet (game data) -
↑🟢 ↓🟢: Everything is fine.
-
↑🟢 ↓❌: Packet Loss. You’re not receiving data from the server.
-
↑❌ ↓❌: Full Packet Loss. Your connection might be blocked.
-
???: WebRTC / UDP is unavailable - mobile or limited internet?
thanks
- udping by xkeeper for the original Lua version and some SFX.
- packetlosstest.com for the WebRTC inspiration.
- Speedtest by Ookla for being the speed test. Unbiased, of course.
- Nerd Fonts for collecting so many icons into one easy-to-use library.
- PeerJS for making WebRTC easy. Had to mod it tho ^^’
- scroll-into-view-if-needed for the great
boundaryimplementation. - Valve Corporation for the Half-Life 2 sound effects.
free-time hobby project hotglued together with <3 and 🚰Hydration™, by jade