Users have reported "crashes" on mobile Safari when trying to close the banners of the German "Thank you" fundraising campaign (See T242589: Browser crashes when closing banner).
"Crash" means that mobile Safari becomes unresponsive when scrolling up: sometimes scrolling does not work at all, sometimes it "stutters" during scroll. When it has "crashed" in such a way, mobile Safari does not render new elements that were outside the rendered viewport. Using a cable connection and connecting the Safari web inspector on Desktop to an iPhone shows that Mobile Safari uses 100% CPU (and the web inspector becomes unresponsive).
I've investigated this issue and it boils down to three factors:
- This issue occurs only with the MinervaNeue skin, both on the mobile version of Wikipedia (unsing the m. subdomain) and with the Desktop version (using the &useskin=minerva parameter). Showing the same banner with the Vector skin does not lead to a crash when clicking the button.
- The Fundraising Ops Team requires us to position the banner at the top of the page (above the header element that contains the search/menu bar). The easiest way to accomplish this is to move the centralNotice element to be the first child of the body element. When we leave the centralNotice element in place (or at least inside the main element), Mobile Safari does not crash when clicking the close button.
- The issue only occurs on the "close" event handler (on the click event), not on the "expand" handler (another click event) handler or the form validation event handlers (also click events). Why the other handlers are unaffected is not clear to me. I've tried changing the class name of the element but that had no effect. Maybe the issue is related to an element's position in the DOM.
Since I'm not familar with the MobileFrontend/MinervaNeue code, I'm hoping someone can chime in and shed some light on this issue:
- Do you have ideas what could trigger this crash?
- Is there anything we can do differently (except not moving around the DOM node)?
- Was there any code deployed recently that could have created this behavior? We have not gotten complaints during the fundraising campaign (Nov 11 - Dec 25), so the error could be a recent phenomenon.
You can try for yourself with these test banners:
- https://de.m.wikipedia.org/wiki/Wikipedia:Hauptseite?banner=B19_WMDE_Mobile_Thankyou_Working&uselang=en&force=1 leaves the banner-position as-is, close button works
- https://de.m.wikipedia.org/wiki/Wikipedia:Hauptseite?banner=B19_WMDE_Mobile_Thankyou_Broken&uselang=en&force=1 moves the banner element to the top, close button crashes mobile Safari
- https://de.m.wikipedia.org/wiki/Wikipedia:Hauptseite?banner=B19_WMDE_Mobile_05_var&uselang=en&force=1 Last mobile fundraising banner also has that behavior.
The source code for the two test banners is tracked at https://github.com/wmde/fundraising-banners/tree/thankyou-fix
A workaround for the "banners must be positioned at the top" requirement would be to measure the height of the top bar and subtract it from our absolute/relative positioning of the banner, but I'd rather not do that, it feels hacky and might get into trouble with the width of the when it's no longer determined by the viewport.