Bug 312727 – Jetsam on some De Correspondent articles - works fine in Chrome and Firefox, even on very memory limited devices

• Component: Layout and Rendering
• Status: NEW

[Roderick Gadellaa]

The company I work for (De Correspondent) published a rather long article a little over a week ago, and we've received numerous reports from our users that the page is crashing the Safari tab (when viewing the article on our website) and WKWebView (when viewing the article in our app, which uses WKWebView to render the page).

The issue is easily reproducible by quickly scrolling through the page, but even when flicking "casually", the issue often pops up. 

https://decorrespondent.nl/16856/hoe-de-groningse-gasbevingen-ontaardden-in-een-feitenvrij-compensatiecircus-van-miljarden-euro-s/f82c7f64-fbd8-06be-10a1-473b34774df0

Some of our readers report they can't reach the bottom of the page at all before the tab crashes and reloads. They then try to quickly get back to where they left off, which all but ensures that the tab crashes again (the faster they scroll, the higher the chance to trigger the crash).

Most reports are from iPhone 13 users, but we've been able to consistently reproduce the crash on every iPhone we threw at this page (including an iPhone 16 Pro).

Another (slightly older, but also long) article that caused similar problems:

https://decorrespondent.nl/16680/deze-journalist-woont-al-982-dagen-in-azc-s-door-heel-nederland-dit-is-zijn-dagboek/27df4950-4c04-04cf-25c2-a3b2d6f3a90b

As far as we can tell and reports we're getting, it's not just iOS 26 that is affected, but getting our hands on hardware with older iOS versions so we can test ourselves is not easy.

The same pages work fine on Android, both Chrome and Firefox:

* Pixel 9, Chrome & Firefox
* Pixel 7, Chrome & Firefox
* Pixel (OG, 2016), Chrome
* Moto X (2013!), Chrome [1]

This leads me to believe this is a WebKit-specific issue and not something we're doing wrong on our end (or at least hardware/memory limits shouldn't be the problem [1]). 

That said, if there's anything we can do to work around the issue on our end, I'd be very happy to hear it!

Thanks!

[1] Yes, I've tested this on a Moto X from 2013 🤪, with 2GB of RAM, running Android 6.0.1 and Chrome 109. It's not a pretty site (pun intended, sorry...) but the page works and doesn't crash.

[Alexey Proskuryakov]

Thank you for the report! I can reproduce this with iPhone 17 Pro, it actually is a jetsam (running over memory limit for the process).

It's quite possible that WebKit is doing something inefficiently here, however I'll also note that Moto X has 3.4x fewer pixels than iPhone 17 Pro, which reduces its memory use.

[Radar WebKit Bug Importer]

<rdar://problem/175122748>

[Roderick Gadellaa]

Thanks for the quick reply! (I was away for the week so mine took a bit longer).

One would hope that Apple's current flagship phone comes equipped with enough memory to beat a Moto X, but I see how "it runs on 2GB without issues" isn't entirely fair, either :)

Anyway. We would love to know what's causing the jetsam. I'm pretty sure *we* could do things more efficiently on our end, too. Any help in pinpointing where and what we can optimize is very welcome.

And happy to provide any additional info or anything from my end that would help WebKit find and/or resolve the issue.

Thanks again!

[Simon Fraser (smfr)]

A brief look suggests that the jetsam is caused by large amount layer backing store; there are lots of layers with `will-change: opacity, transform`, and some of these have animations which currently prevent WebKit from dropping backing store when an element is outside the viewport.

Use the `layers-inactive` class on `story__scene` to set display:none on the that scene or child elements.

Thanks! Will look into that ASAP!

[Roderick Gadellaa]

I've tried your suggestion (setting `display: none` instead of `will-change: auto` on `.story__scene.layers-inactive > .layer`), but the tab still crashes (I think it does take a bit longer, but I just did some quick testing, so no real measurements or whatever). 

I then completely disabled the Flourish iframes (by simply not initializing and injecting the iframes), which did seem to help a LOT. I was able to reach the bottom of the article and then scroll all the way up again without a crash. Many of these iframes have transforms and animations, so I imagine they eat up memory that WebKit has to hold on to as well. Since the iframes interact with the document (for their own scroll animations), I assume they need to run in the same process (and thus use the same memory pool).

Disabling the Flourish embeds is clearly not an option in prod, so I then tried the same `display: none` trick (with a placeholder `height: var(--last-known-height);`), but that still crashes the tab. I also tried `content-visibility: auto;`, but that doesn't prevent the crashes either.

I'll do some more testing and some attempts later this week, will report when I have more to share.

Thanks!