WebKit browser engine bugs

26 Oct, 2025

One important part of website development is testing on a wide range of browsers and devices. The same is true for this website, which I test on several configurations, many of which involve WebKit (I have... a few old iOS devices, but mainly old iPhones from before I became a Certified Android User™). Unfortunately, I am quickly learning that WebKit has quite a few bugs, some of which have been fixed, and some that remain to this day (as of writing). WebKit, in case you don't know, is Apple's take on a browser engine, used in their own Safari web browser (both macOS and iOS, including every third-party iOS web browser), and the engine that Blink (the browser engine used in Chrome and Chromium-based browsers) is based on.

Anyways, some of the bugs I've found that occured in WebKit but not Chromium or Firefox include browser elements disappearing when pausing animations (fixed in this commit, but also fixed in later WebKit versions), shatter animations not playing at all (accidentally fixed in this commit when optimising some animations, but still appears broken (heh) on newer iOS versions for some reason), straight up crashes (one of which is suspected to be caused by the previous commit – as of writing, I haven't investigated further yet), and the subject of today's blog: the colour filter on my Prophecy Pane Generator's panes' backgrounds disappearing after a few seconds on iOS Safari (until this commit fixed it).

The original (buggy) background

First off, to see the bugs in action on this page's examples, you'll need to read this on an iPhone or iPad, if you're not already. As of writing, this bug hasn't been fixed yet in WebKit, so all iOS versions that can use background-blend-mode are affected. The rest of this article assumes you're reading on iOS.

With that out of the way, here is the original buggy background (with the border gradient, etc. removed). Notice how the background sometimes stops being tinted blue periodically:

For reference, the original, unfiltered image is here.

My attempted "fixes"

I initially thought the bug in question was being caused by animating the background colour, so I tried setting it to a constant colour. The bug persisted:

I tried resizing the background image. This made the bug worse, now not filtering at all:

Making the div larger had the same effect, although the background was still being filtered some of the time depending on the specific width and height used:

I even tried removing the image-rendering CSS rule, before realising my older devices (that had no support for the rule) still had the same bug anyways:

Looking for similar bugs

At this point, I decided to have a look on WebKit's Bugzilla, looking for similar bug reports. Since I still didn't really know what was causing the bug, I had a look in the CSS and Animations bug lists, which I quickly gave up on due to the sheer volume of bugs. So I began searching some keywords of CSS rules I was using, until I found this bug report. The description seemed to somewhat align with the problems I had above, where larger elements (or smaller backgrounds) tended towards more buggy behaviour.

At last, the true cause

For the bug to trigger, all of the below need to be true:

• The element uses background-blend-mode with a background-color (ProphGen uses these to colour the background).
• The element's size is larger than 256px on at least one side (for ProphGen, this is true with a scale setting of 2x or greater, where the element will have a size of 300x180).
• The background image's size is smaller than 256px on one side (the background image that ProphGen uses has a size of 316x238).
• The background is set to repeat (all elements with a background image have this behaviour by default, and ProphGen needs this behaviour).

If all of the above conditions are true, the bug will show itself when trying to position the image so that the 256th (or later) row/column of pixels are shown in the element. This is why the bug only sometimes appears with the settings ProphGen uses, and appears more often with larger element sizes (or smaller background sizes)!

How I fixed it

To fix the bug, I simply inserted another div set to overlay the background image, then changed the background colour animation code to animate the overlay div's background colour instead. Then, instead of background-blend-mode, I used mix-blend-mode on the overlay div.

Here's the fixed background animation:

And with everything else (this is the same as the animation on the Prophecy Pane Generator page when JavaScript is disabled):

How do I apply this to my website?

Since I took the time to come up with a general solution on this bug report (linked to from the WebKit bug report), I will repeat it here, with some modifications. Given a HTML snippet like below:

<div class="filtered-bg">
	<h1>My cool website</h1>
	<!-- ... -->
</div>

And its associated CSS:

.filtered-bg
{
	background: #123456 url("bg.png");
	background-blend-mode: multiply;
	/* other CSS rules (size, position...) */
}

You will first need to move the contents of your div to a container (so the contents aren't also filtered):

<div class="filtered-bg-fixed">
	<div class="filtered-bg-content">
		<h1>My cool website</p>
		<!-- ... -->
	</div>
</div>

Then, change your CSS to:

.filtered-bg-fixed
{
	background: url("/prophgen/bg.png");
	position: relative;
	/* other CSS rules (size, position...) */
}

.filtered-bg-fixed::before
{
	position: absolute;
	left: 0;
	top: 0;
	right: 0;
	bottom: 0;
	content: "";

	/* your background-blend-mode goes here - they are
	 * all supported in mix-blend-mode as well */
	mix-blend-mode: multiply;
	background: #123456;
}

.filtered-bg-content
{
	position: relative;	/* needed for z-index to apply */
	z-index: 1;
}

You could also use another div instead of the ::before pseudo-element (I went this way for my Prophecy Pane Generator), but this way you can avoid bugs caused by accidentally putting the filter div in front of other elements. Unless you want to filter some content inside the element – it's your website, after all.

Either way, here's how both of the above look (with some extra margin and padding, but otherwise the same):

Again, both will look the same unless you view on iOS Safari (and possibly other iOS web browsers – I didn't test any).

Finally, a couple of notes about this solution:

• if your div you want to apply this to is not statically positioned (i.e. you have position set to anything other than static or relative), you may need to do more work to get the filter applied properly. I'll leave that as an exercise to the reader.
• If your original div had margin and padding set, you should move the padding to the content div (check the source code of the below samples for an example).

That's all for now. For those wondering what's happening to YAMDCC, I will eventually continue development of v2.0. I'm just enjoying developing this website more at the moment, which is a strong motivator. In any case, I'm happy that my Prophecy Pane Generator now works properly on the most common smartphone vendor in the world (at least as of writing). Speaking of that link, I find it very fascinating that the "Unknown" status jumped from 9 to 16% in a month (from August to September 2025).

Note: I use "iOS" in this article to refer to both iOS (the iPhone and iPod touch OS) and iPadOS. For the purpose of this blog, the differences don't matter – they both use WebKit as their browser engine, even on third-party web browsers (unless you live in the EU).

And before you ask, no, I will not be implementing code highlighting for the HTML and CSS above.