Stop blaming Safari, start measuring it
When something breaks in a web app on an iPhone, the first thing that comes to mind is, this is Safari’s fault. Or Apple will fix it one day, and until then we either ignore the issue or go online and dig out a workaround and move on.
I am in that same boat, but this year I spent time on media bugs that had been sitting in open source projects. None of them was waiting on Apple, but for someone to measure them on a phone and share the numbers so a fix can be done.
The first was in LiveKit, the video library used to create my own teleprompter app. Now, when the camera starts recording, the first set of frames come through with the wrong size and layout, and any application that reads the track in those first moments will get the wrong size and layout of what they will get if they wait just a second more.
Now this is not new, because three other developers had reported this issue over the past year that I searched. The usual guesses in the threads where this was reported had most fingers pointed at Safari.
My measurement using my iPhone 15 logged that the track was wrong for 112 milliseconds in one run and 139 in another, then corrected itself at the first painted frame. I reported this to LiveKit, and an engineer there reproduced it at about 400 milliseconds on an iPhone 11.
Now, the other thing is, this error also showed up on Android, which shows that it was never only a Safari problem. Now that there was a number and a test page to actually track the issue, a report and a fix became a PR and was later merged. What is interesting is how I knew to measure this. It was because I have an old Samsung A14 that I use as a music playe. It is slow and when I loaded my page on it, I noticed for less than a second the image was landscape then it flipped portrait. I tried it again holding the phone portrait and it happened again.
I continued on my media app production and I stumbled on another issue, while testing using the Shaka Player. On Safari, when the player switched to a different quality in the middle of a video that was playing, it jumped back a couple of seconds. Another search had people suspect WebKit, but my experience on the first issue made me know it is important to measure this. And it turned out to be two things together. First, Safari does behave oddly at that point, and Shaka also looked back two seconds when it switched. But instead of waiting for Safari to fix this, I continued the test on Shaka to see how this can be better managed. I tried different fix versions until I hit one that passed 8 out of 8, did a PR and the maintainers merged it and it went out in their next release. The Safari part went to Apple as a WebKit bug with a test case.
The third was smaller and it was on mediabunny, a library for working with media in the browser, which wrote the wrong codec string. Again, the first instinct was that Safari was being Safari. It was a one-line mistake in the string and it was fixed and merged. None of this needed special access to Apple for a fix, it just needed measurement, patience and a small page to run tests and log the reports.
The browser reports what you asked for, not always what is true at that moment, and in these cases, the gap was a fraction of a second. The labels also do damage, the moment someone says it is a Safari bug, people stop looking for why and just search for a workaround. Maintainers wait for Apple, contributors assume there is nothing they can do, and use a workaround to hide the problem.
Measuring is important, because when you report a bug as the camera is wrong sometimes, that goes nowhere. A report with a page, a device, a version and a number in milliseconds is something an engineer can pick up, reproduce and start working towards a fix. So the next time you run into a bug on Safari, while using your Mac or your iPhone, load it on a page and measure it, if it is the browser Apple gets a report, if not you have found a fix.
The post Stop blaming Safari, start measuring it appeared first on SD Times.
Tech Developers
No comments