The Safari bug that by no means was
In October 2021, Ian, a fellow frontend developer at GDS posted a message in our help channel for the GOV.UK Design System on Slack:
“Simply puzzled for those who had been conscious that the Safari Expertise Preview is performing some fairly unusual issues to the header, beta banner and buttons.”
Safari Technology Preview is a model of the Safari browser designed to ‘give an early take a look at upcoming internet applied sciences in macOS and iOS’. Most browser distributors present related variations of their browsers that builders can use to check new options.
Prompted by Ian’s message, we took a take a look at the Design System utilizing Safari Expertise Preview.
We might see the unusual issues that Ian had talked about occurring within the header, the beta banner, and the buttons. The final phrase inside every of those components was wrapping on to a brand new line when it didn’t must.
Safari’s desktop market share is about 15%. Moreover, each browser on iOS, together with Chrome, Edge and Firefox, makes use of the identical browser engine that powers Safari, which is named WebKit.
So if this bug was to make its means out right into a public launch of iOS, GOV.UK would appear to be this for anybody utilizing their iPhone or iPad to entry the Web in addition to anybody utilizing Safari on their Mac. A few third of all periods on GOV.UK are from customers on an iOS gadget.
We needed to report this bug to the WebKit workforce. To try this, we wanted to have the ability to give a great clarification of what it was we had been seeing and the circumstances that had been required for the bug to happen.
We might have simply raised a bug that mentioned ‘Some fairly unusual issues are occurring to the header, beta banner and buttons on GOV.UK in Safari Expertise Preview’.
Nevertheless, we knew from our personal expertise coping with bug stories that offering a extremely clear description of the bug would make it simpler for the WebKit workforce to know the issue, making it extra seemingly that the bug can be mounted shortly.
‘Textual content wraps unnecessarily’ appeared like a great begin – however, surprisingly, we had been solely seeing this difficulty happen on GOV.UK. Different web sites, together with the NHS web site which re-uses quite a lot of our frontend code, seemed effective.
By way of a trial-and-error strategy – disabling particular person options one by one – we discovered that there was one thing in regards to the font that we use that was inflicting this difficulty to happen. Altering the font to Arial made the issue go away.
However even then, it wasn’t occurring in every single place – after we checked out a set of checkboxes the textual content was wrapping unnecessarily throughout the legend, the labels for every checkbox and the main points ingredient, however not throughout the trace textual content.
We realised that it was occurring when components had been intrinsically-sized or ‘shrink-wrapped’. That is when the dimensions of a component is dictated by its content material. For instance, the dimensions of a button modifications to suit the textual content inside it.
So, ‘textual content wraps unnecessarily inside intrinsically-sized components when utilizing sure fonts’?
We thought this was a great description of the issue, however after we tried to create a minimal instance we discovered that there was one other factor that wanted to be true for the problem to happen.
In HTML, any further whitespace between phrases is ignored. This implies you may add further areas, and even new traces, between phrases with out affecting how they’re displayed within the browser.
The bug solely occurred if there was a brand new line someplace within the HTML for that ingredient.
We’d managed to get from ‘some fairly unusual issues are occurring to the header, beta banner and buttons’ to ‘textual content wraps unnecessarily inside intrinsically-sized components when utilizing sure fonts and the inside HTML of the ingredient incorporates a brand new line that’s not preceded by an area’.
As soon as we had a great understanding of the circumstances required to set off the bug, we reported it to the WebKit team on November tenth final 12 months.
We included hyperlinks to pages the place the problem was occurring, the model of Safari Expertise Preview the place we imagine the problem had been launched, and a minimal take a look at case that demonstrated the bug.
A number of days later a WebKit engineer responded to our bug report, saying “This can be a actually dangerous bug and we must always repair it instantly.”
After some investigation, they made a change to WebKit that mounted the bug, and in addition added a take a look at to stop the bug from occurring once more.
By January sixth the change had been accredited and merged, and was then included in Safari Expertise Preview 139 which was launched on twenty sixth January.
You is likely to be questioning what had brought about the bug to happen within the first place.
We actually had been, and so we requested the engineer from the Webkit workforce who mounted the bug if he might come and discuss to the frontend group at GDS about it, which he very kindly agreed to do.
He defined that that they had been refactoring among the code chargeable for laying out textual content on the web page.
To ensure that WebKit to put out the textual content on the web page, it must measure the width of the textual content. To do that, it makes use of knowledge from the font to seek out out the width of every character.
This contains the width of whitespace characters, like areas.
The font additionally has knowledge in regards to the newline character, together with its width. This doesn’t actually make sense – new traces don’t (or not less than shouldn’t) take up any house, however the font doesn’t deal with it in another way to another character. The creator of the font nonetheless has to incorporate a width for the brand new line character within the font’s knowledge.
And within the font we use on GOV.UK, the brand new line character has an even bigger width than an area character – which is outwardly uncommon.
The code to put out textual content for intrinsically-wrapped components has two steps – first, it measures the dimensions of the textual content and makes use of that dimension to position packing containers within the web page format.
Then, as a separate step, it places the textual content into these packing containers.
It’s necessary that these two steps each agree on the width of the textual content.
This bug occurred as a result of the 2 steps stopped agreeing.
Considered one of them incorrectly used the width of the brand new line character in its calculations, and so the field that it made was too small.
Then in step 2, when WebKit tried to place the textual content into the field it had simply created, it discovered that it didn’t match and so, the final phrase ended up compelled on to a brand new line.
We don’t routinely take a look at with Safari Expertise Preview or different ‘beta’ variations of browsers, so it was pure luck that Ian occurred to make use of it to check one thing else.
So far as we all know, we had been the one individuals to report this bug. If Ian hadn’t taken the time to tell us about this in our help channel, or if we hadn’t taken the time to analyze and report it, there’s a excessive probability that it might have made its means into public releases of Safari and iOS.
This isn’t the one bug that we’ve reported. We’ve reported over 70 bugs to completely different browser and assistive tech distributors over the previous few years, which we attempt to preserve monitor of utilizing this GitHub project.
Reporting bugs to browser distributors is a good way to assist make the net platform higher. You possibly can learn more about filing good browser bugs in this article from web.dev.