Hello,
We’ve been using the CesiumJS WebGL library for several years, both on our website and within embedded WebViews in our iOS application. Since upgrading to iOS versions 18.2 and 18.3, we’ve started receiving numerous user complaints regarding application crashes on various iPad and iPhone models when loading CesiumJS.
The crashes occur as soon as the 3D view initializes, and the error consistently reported is:
"WebGL context lost"
This issue appears to be a WebGL-related crash potentially triggered by GPU memory handling or allocation limits. However, we are not detecting any abnormal memory consumption prior to the crash, and the same setup works perfect on older iOS versions and on all Android devices and versions.
Steps to Reproduce:
Open: https://www.flightradar24.com/30.47,-94.84/8
Click on any aircraft icon on the map.
In the aircraft details panel at the bottom, click on the “3D view” tab.
On iOS 18.2 or 18.3, the page will crash shortly after initializing CesiumJS WebGL.
Affected Devices:
This issue is occurring across a wide range of devices, including:
iPad 9th Generation
iPad Pro (11-inch, 2nd Gen)
iPhone SE (2020 and 2022)
iPhone 11, 11 Pro
iPhone XR
iPhone Mini
All of the above are running iOS 18.2 or 18.3. The problem does not occur on Android or previous iOS versions.
Request:
Has anyone else encountered similar issues with WebGL context loss after upgrading to iOS 18.2 or 18.3? Are there any known changes in memory limits or WebGL behavior in these recent iOS updates? We’d appreciate any insight or suggestions on workarounds or potential fixes.
Thank you!
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
We’re seeing an issue in our Safari Web Extension where not all cookies from the Set-Cookie response header are accessible. We are using macOS 15.4 and Safari 18.4.
In the webRequest.onHeadersReceived callback, the Set-Cookie header returned by Safari only includes some of the cookies set by the server. If multiple Set-Cookie headers are present, we seem to receive only a partial list, some cookies are missing entirely.
In Chrome and Firefox, the same callback provides all cookies set by the server without issue.
We are looking for assistance in fixing these issues and having our Safari Extension function the same as it does in Firefox and Chrome.
I'm not loving the huge Favorites icons in Safari on MacOS 26, is there a way to reduce the size of them so that we can see more favorites on the list without scrolling down?
How can I make a background image take the entire screen in ios26?
I've tried position fixed, sticky, env() css variables but nothing worked. It does it when in PWA mode, but I would like to do so in the browser too.
Whenever I make a safari view controller on XCode26 Beta 5, there appears to be a blurry white overlay overtop the controller. This worked fine in XCode26 Beta 2, with no code differences.
Anyone have any suggestions?
Device: iPhone 15pro, ios26.0 (23A 341)
IOS version: 26.0 (23A 341)
When using position: sticky; bottom: 0, the div is expected to stick to the bottom of the viewport when the browser toolbar hides while scrolling. However, it stops at the height where the toolbar was, instead of moving down with the disappearing toolbar.
In the image below, the red-bordered navigation shows the situation where it does not stick to the bottom.
i
When I open the browser in Safari on iOS 26, I want to specify the background color for the header notch (where the time, battery, etc. are displayed) and the footer indicator area.
Specifying the theme color in HTML as shown below did not change anything.
<meta name="theme-color" content="#ff0000">
<meta name="theme-color" media="(prefers-color-scheme: light)" content="#ff0000">
<meta name="theme-color" media="(prefers-color-scheme: dark)" content="#ff0000">
The HTML below specifies the background color as green, but is it necessary to specify the background color directly in the body like this?
Or is there some kind of metadata, like theme color?
<!doctype html>
<html lang="ja">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width,initial-scale=1" />
<meta name="theme-color" content="#ff0000">
<meta name="theme-color" media="(prefers-color-scheme: light)" content="#ff0000">
<meta name="theme-color" media="(prefers-color-scheme: dark)" content="#ff0000">
<title>サンプル</title>
</head>
<body style="background:#00ff00">
<main>
<p>テキスト</p>
</main>
<div
id="overlay"
role="dialog"
aria-modal="true"
data-test-id="health-warning-modal"
style="
color:#000000;
position:fixed;
inset:0;
z-index:30000;
background:#2563eb;
display:grid; /* 初期表示：表示中 */
align-items:center;
justify-content:center;
overflow-y:auto;
"
>
<div
style="
padding:60px 16px;
display:flex;
flex-direction:column;
gap:20px;
width:100%;
box-sizing:border-box;
"
>
<p
style="
font-weight:700;
text-align:center;
margin-top:20px;
font-size:28px;
line-height:1.4;
"
>
オーバーレイ
</p>
</div>
</div>
</body>
</html>
I have a hybrid mobile app which loads web server screens in its iframe(which is under the WKWebView); an https request is initiated from the mobile app to the web server which returns the html page to be loaded in the iframe.
The calls which are initiated from outside the iframe have cookies maintained in their requests, while the ones initiated from inside the iframe(web server page) loose the cookies and do not inherit them in IOS beta 18 while It worked fine in the previous IOS versions.
Anybody has infos about this or similar cases?
It is outrageous that Apple continue to fail to implement the Fullscreen API web standard for web apps on iPhone only, which is so important to accessibility and web app functionality.
The only possible reason for this block is commercial: to promote iOS apps instead of browser based web apps.
To quote a client from a major agency just now - a typical enquiry :
We value accessibility greatly, and we noticed that the embedded player is missing a full screen button on iPhone.
Everything else works perfectly fine, including a full screen button that appears on the mobile webpage on android devices.
Is there any way we can include a button to enable full screen view for our viewers in your player that are going to watch it on iOS devices?
To which, as usual, we have to reply:
Apple unfortunately block fullscreen mode from being used with all web applications on iPhone.
Apple will allow this to be displayed fullscreen on MacBooks and iPads, but currently not on on iPhone - so we have to hide the fullscreen button there.
So fullscreen works on all devices and browsers apart from on iPhone.
As you've seen with Android, all other devices and browsers follow the universal 'Fullscreen API' web standard to allow full screen.
You're probably familiar with seeing the fullscreen button on normal linear videos on iPhone.
These use Apple's native video player, which doesn't let buttons and scripts be used on top of it - just a single video, not an interactive web application.
Our player looks like a video player but it is actually a web app combining multiple different video clips connected together by code and styling.
They block it on iPhones for reasons known only to them, but the assumption is that it is to incentivise people to make iOS apps instead of web apps.
The web development community is hopeful that Apple will change this unfortunate restriction soon, but we have been waiting a long time in vain.
We have to send this to a lot of people. It's a very bad look for Apple.
In less than a month it will be 2025. We have been waiting years for this.
The web standard documentation showing universal support on other devices and browsers is here:
https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API
This is not acceptable. It is time for Apple to stop blocking this important accessibility web standard for commercial reasons - only on iPhone. To whoever is in charge of these decisions in the Safari/Webkit team: Please just enable Fullscreen API for web apps on iPhone as soon as possible.
When I'm inspecting a WKWebView in a simulator and the WKWebView loads a local URL with a port number, I've found that most features of Safari dev tools that worked in iOS 17 are broken in iOS 18. Here are the steps I'm taking:
Set up a WKWebView with isInspectable = true that loads a local URL, e.g. https://www.local.mydomain.com:3000
Install a self-signed SSL certificate on a simulator for www.local.mydomain.com
Run my app on the simulator
The WKWebView loads successfully
In Safari on my Mac, I can select the WKWebView and open dev tools to inspect it
If the simulator is on iOS 17, this works fine, no issues.
But if the simulator is on iOS 18, Safari dev tools are mostly broken. I can tell that there is a connection to the WKWebView because the Network tab logs the requests that I expect. But I cannot use any of the other dev tools features: Elements, Sources, Console, etc.
Has anyone else encountered this? Is there a workaround?
Topic:
Developer Tools & Services
SubTopic:
General
Tags:
Xcode
Safari Developer Tools
Safari and Web
Simulator
Hi all,
Chrome has it already - animation-timeline aka scroll-animations.
I can nowhere find any informations on what's the status in Safari/Webkit.
Seems like they do not have it on the agenda at all?
Does anyone know anything - I wanted to push a feature request for that - but also seem there is no feature request list anymore for webkit.
See: https://www.w3.org/TR/scroll-animations/
Cheers and kind regards!
We are experiencing an issue with Safari in all versions from 18.0 to 18.5 that does not occur in version 17. It affects both iPhones and Macs. And does not happen in Chrome or Windows.
The problem is impacting our customers, and our monitoring tools show a dramatic increase in error volume as more users buy/upgrade to iOS 18.
The issue relates to network connectivity that is lost randomly. I can reliably reproduce the issue online in production, as well as on my local development environment.
For example our website backoffice has a ping, that has a frequency of X seconds, or when user is doing actions like add to a cart increasing the quantity that requires backend validation with some specific frequency the issue is noticable...
To test this I ran a JS code to simulate a ping with a timer that calls a local-dev API (a probe that waits 2s to simulate "work") and delay the next HTTP requests with a dynamic value to simulate network conditions:
Note: To even make the issue more clear, I'm using GET with application/json payload to make the request not simple, and require a Pre-flight request, which doubles the issue.
(async () =&gt; {
for (let i = 0; i &lt; 30; i++) {
try {
console.log(`Request start ${i} ${new Date().toLocaleString()}`);
const res = await fetch(`https://api.redated.com:8090/1/*****/probe?`, {
method: 'GET',
mode: "cors",
//headers: {'Content-Type': 'text/plain'},
headers: { 'Content-Type': 'application/json' },
});
console.log(`Request end ${i} ${new Date().toLocaleString()} status:`, res.status);
} catch (err) {
console.error(`Request ${i} ${new Date().toLocaleString()} error:`, err);
}
let delta = Math.floor(Math.random() * 10);
console.log("wait delta",delta);
await new Promise(r =&gt; setTimeout(r, 1000 - delta));
}
})();
For simplicity lets see a case where it fails 1 time only out of 10 requests.
(Adjusting the "delta" var on the time interval create more or less errors...)
This are the results:
The network connection was lost error, which is false, since this is on my localhost machine, but this happens many times and is very reproducible in local and production online.
The dev-tools and network tab shows empty for status error, ip, connection_id etc.. its like the request is being terminated very soon.
Later I did a detailed debugging with safari and wireshark to really nail down the network flow of the problem:
I will explain what this means:
Frame 10824 – 18:52:03.939197: new connection initiated (SYN, ACK, ECE).
Frame 10831 – 18:52:04.061531: Client sends payload (preflight request) to the server.
Frame 10959 – 18:52:09.207686: Server responds with data to (preflight response) to the client.
Frame 10960 – 18:52:09.207856: Client acknowledges (ACK) receipt of the preflight response.
Frame 10961 – 18:52:09.212188: Client sends the actual request payload after preflight OK and then server replies with ACK.
Frame 11092 – 18:52:14.332951: Server sends the final payload (main request response) to the client.
Frame 11093 – 18:52:14.333093: captures the client acknowledging the final server response, which marks the successful completion of the main request.
Frame 11146 – 18:52:15.348433: [IMPORTANT] the client attempts to send another new request just one second later, which is extremely close to the keep-alive timeout of 1 second. The last message from the server was at 18:52:14.332951, meaning the connection’s keep-alive timeout is predicted to end around 18:52:15.332951 but it does not. The new request is sent at 18:52:15.348433, just microseconds after the predicted timeout. The request leaves before the client browser knows the connection is closed, but by the time it arrives at the server, the connection is already dead.
Frame 11147 – 18:52:15.356910: Shows the server finally sending the FIN,ACK to indicate the connection is closed. This happens slightly later than the predicted time, at microsecond 356910 compared to the expected 332951. The FIN,ACK corresponds to sequence 1193 from the ACK of the last data packet in frame 11093.
Conclusions:
The root cause is related to network handling issues, when the server runs in a setting of keep-alive behavior and keep-alive timeout (in this case 1s) and network timming issue with Safari reusing a closed connection without retrying. In this situation the browser should retry the request, which is what other browsers do and what Safari did before version 18, since it did not suffer from this issue.
This behaviour must differ from previous Safari versions (however i read all the public change logs and could not related the regression change).
Also is more pronounced with HTTP/1.1 connections due to how the keep-alive is handled.
When the server is configured with a short keep-alive timeout of 1 second, and requests are sent at roughly one-second intervals, such as API pings at fixed intervals or user actions like incrementing a cart quantity that trigger backend calls where the probability of failure is high.
This effect is even more apparent when the request uses a preflight with POST because it doubles the chance, although GET requests are also affected.
This was a just a test case, but in real production our monitoring tools started to detect a big increment with this network error at scale, many requests per day... which is very disrupting, because user actions are randomly being dropped when the user actions and timming happens to be just near a previous connection, where keep alive timeout kicks-in, but because the browser is not yet notified it re-uses the same connection, but by the time it arrived the server is a dead connection. The safari just does nothing about it, does not even retry, be it a pre-flight or not, it just gives this error.
Other browsers don't have this issue.
Thanks!
Hi Folks,
do you know what happend with the "shape detection API" feature flag on Safari 18.X (IOs 18.X)?... in previous versions (17.X) i enabled the "shape detection API" feature flag and was able to detect codes like mentioned here...
https://developer.mozilla.org/en-US/docs/Web/API/Barcode_Detection_API#browser_compatibility
I built a PWA (Service Worker) with Angular 18 and facing this issue immediately after updating to IOS 18.0 (I enabled/disabled the flag, restartet the device several times... no success at all)
Do you have an Idea what changed or how i can enable that feature again?
Thx a lot in advance..
Cheers Martin
browser.runtime.onMessage in content script intermittently fails on iOS 18.5 (Safari Web Extensions)
Hi everyone,
I’m encountering a critical reliability issue with message passing in my Safari Web Extension on iOS 18.4.1 and iOS 18.5.
In my extension, I’m using the standard messaging API. The background script sends a message to the content script using browser.tabs.sendMessage(...), and the content script registers a listener via:
browser.runtime.onMessage.addListener(handler);
This setup has been working reliably in all prior versions of iOS. However, after updating to iOS 18.4.1 and 18.5, I’ve noticed the following behavior:
✅ The content script is successfully injected, and onMessage.addListener is registered (I see logging confirming this).
✅ The background script sends the message using the correct tabId (also confirmed via logs).
❌ The content script’s onMessage listener is not consistently triggered.
⚠️ This issue is intermittent, sometimes the message is received, sometimes it is silently dropped.
❌ No exceptions or errors are thrown in either script, the message appears to be sent, but not picked up from the content script message listener.
Summary:
Content scripts injected via manifest continue to receive and respond to chrome.tabs.sendMessage() calls even after the user has navigated away from the original page, causing messages intended for the current tab to be handled by zombie contexts from previous pages.
Environment:
Safari/iOS Version: 18.5
Extension Manifest: Version 3
Expected Behavior:
When a user navigates from Page A to Page B:
Page A's content script context should be destroyed.
chrome.tabs.sendMessage(currentTabId, message) should only reach Page B's content script
Only Page B should be able to respond to action button clicks (or other background to content messages).
Actual Behavior:
When navigating from Page A to Page B:
Page A's content script context persists as a "zombie".
chrome.tabs.sendMessage(currentTabId, message) reaches zombie context instead of the Page B's one. Hence, it looks like the extension is broken because the content script does not respond to the background messages.
Details:
Tab ids are properly recognized by both background and content script
The problem does not always occur; it occurs on random occasions. It's quite easy to have it reproduced.
It can be reproduced easier if user clicks ext icon during site loading (before it fully loaded), triggering ActionClick (ext icon click) event and then sending a msg upon it to the content script
Regardless of whether the content script is injected into the tab using manifest.json, registerContentScripts, or executeScript, the problem is still there
Once the problem occurs, e.g. user is on macys.com but zombie injected content script believes it's google.com (a previous page), even refreshing the tab doesnt change anything - zombie context is still there (thinking it's still google.com) . Changing a domain to something completely different one could help though. Then going back to macys.com could still lead to the described issue.
A zombie content script does not have access to the page's console function and others.
Example communication
Sending following message from the background to the content script using chrome.tabs.sendMessage()
{
"tab": {
"id": 155,
"active": true,
"url": "https://www.macys.com/",
"title": "Macys.com"
}
}
Results in the content-script zombie context response (the url is taken from the window.location.href)
"message": {
"type": "ActionClicked",
"data": {}
},
"response": {
"data": {
"windowUrl": "https://www.google.com/",
"contentReached": true,
"timestamp": "1,753,138,945,272",
}
}
}
Topic:
Safari & Web
SubTopic:
General
Tags:
Safari Developer Tools
Safari
Safari and Web
Safari Extensions
our company created a web safari extension.
before iOS 26 (beta) release we would archive our extension and install to our devices no problem.
since iOS 26 (beta) (we also tried in beta 4 23A5297m) the extension would archive perfectly but when installing the extension would just not run. its found in settings under safari extension, but when enabled the extension and open safari it will show error message "Ext" is no longer available.
to rule out all code issues, we built a new project from scratch with a new bundle id, tried to archive with no problem, but when installed in an iphone 16 with iOS 26 BETA (23A5297m) same error ocurs it installs but when opening safari it will give an error message saying extension is no longer available.
attached in the google drive link is a zip file of the new project, a zip file with a succesfull build of the ipa file with enterprise distribute, a video of the entire proccess and the error that the iphone gives.
also attached a log file from the iphone that includes the install and the crash of the app.
within the logs there is a log saying Error occurred during transaction: The provided identifier "dev.sacal.ext" is invalid.
before ios 26 the exact steps worked perfectly.
https://drive.google.com/file/d/1PYDOv8IRvRY_ouqiOc0sJdcfh0CHbL72/view?usp=sharing
Hi there!
I'm new to App Development and I'm running into the following error when playing audio on a website loaded through a WKWebView:
0x112000cc0 - ProcessAssertion::acquireSync Failed to acquire RBS assertion 'WebKit Media Playback' for process with PID=70.197, error: Error Domain=RBSServiceErrorDomain Code=1 "(originator doesn't have entitlement com.apple.runningboard.assertions.webkit AND originator doesn't have entitlement com.apple.multitasking.systemappassertions)" UserInfo={NSLocalizedFailureReason=(originator doesn't have entitlement com.apple.runningboard.assertions.webkit AND originator doesn't have entitlement com.apple.multitasking.systemappassertions)}
Looking through this forum, it seems more people have this issue, yet no one has found a solution (or posted it...). The solutions that I did find (Background Modes capability, webView.configuration.allowsInlineMediaPlayback = true), did nothing.
To make sure the issue had nothing to do with my own code, I created an empty project to reproduce the issue. I'm not sure on the best way to share it, but it's a small file (forgive me, I have no clue what it does, actually chatGPT made it for me. My real application is a WebApp wrapped with Capacitor, so it handles all the Swift stuff)
import SwiftUI
import WebKit
struct WebView: UIViewRepresentable {
let urlString: String
func makeUIView(context: Context) -> WKWebView {
let webView = WKWebView()
webView.configuration.allowsInlineMediaPlayback = true
webView.configuration.allowsAirPlayForMediaPlayback = true
webView.navigationDelegate = context.coordinator
return webView
}
func updateUIView(_ uiView: WKWebView, context: Context) {
if let url = URL(string: urlString) {
let request = URLRequest(url: url)
uiView.load(request)
}
}
func makeCoordinator() -> Coordinator {
Coordinator(self)
}
class Coordinator: NSObject, WKNavigationDelegate {
var parent: WebView
init(_ parent: WebView) {
self.parent = parent
}
func webView(_ webView: WKWebView, didFailProvisionalNavigation navigation: WKNavigation!, withError error: Error) {
print("Web page loading failed: \(error.localizedDescription)")
}
}
}
struct WebViewDemo: View {
var body: some View {
NavigationView {
WebView(urlString: "https://www.w3schools.com/html/tryit.asp?filename=tryhtml5_audio_all")
.navigationBarTitle("Web View")
}
}
}
struct WebView_Previews: PreviewProvider {
static var previews: some View {
WebViewDemo()
}
}
Nothing special, right?
When I build the app and navigate to a website that has an tag (https://www.w3schools.com/html/tryit.asp?filename=tryhtml5_audio_all). I still see the error when I play the audio.
It plays nonetheless, but the error is there. I'm not at all interested in actually playing audio in the background/when the app is closed/suspended. I just want the error to go away!
I've tried different iOS versions (14,15,16,17), but the problem persists.
Anyone know what's happening?
In Safari Web Extensions on iOS 18, declarativeNetRequest Rulesets and Dynamic Rules take over twice as long to apply -- which causes rulesets to often fail to apply before sites load. In a boilerplate Xcode project you can note the time difference toggling the OISD (https://oisd.nl) ruleset on iOS 17 and iOS 18 simulators. Additionally, if you force quit Safari and reopen to a site with ads blocked by OISD list (e.g. espn.com) the content will be blocked in that initial state on iOS 17, but not in iOS 18 due to the latency.
Based on the boilerplate extension, this bug is impacting all Mobile Safari Extensions using declarativeNetRequest Rulesets and Dynamic Rules. We know several other extension developers dealing with this issue.
Our team wrote detailed reproduction steps in our Feedback Assistant ticket: https://feedbackassistant.apple.com/feedback/15196130 but have received no responses. I would attach a screen recording here but it won't allow me.
Topic:
Safari & Web
SubTopic:
General
Tags:
Extensions
Safari Developer Tools
Safari and Web
Safari Services
I'm converting a Chrome Extension to a Safari Web Extension, I found it's not easy to get favicon of current tab/url natively.
The tab object in Safari doesn't have favIconUrl.
{
	"id": 121,
	"index": 6,
	"active": true,
	"width": 1324,
	"audible": false,
	"url": "https://github.com/",
	"mutedInfo": {
		"muted": false
	},
	"windowId": 2,
	"title": "GitHub",
	"incognito": false,
	"pinned": false,
	"height": 935,
	"highlighted": true,
	"status": "complete"
}
		
2. I didn't find Safari has similar thing like chrome://favicon
3. I found Safari's favicon caches in ~/Library/Safari/Favicon Cache/favicons but have no idea how to use them in Safari Web Extension.
I’m experiencing a crash in WKWebView on iOS 26 Developer Beta 5 and Beta 6 with the following exception:
CALayer position contains NaN: [nan 65]
The crash occurs when the following CSS properties are applied to content displayed in WKWebView:
-webkit-user-select: none;
-webkit-touch-callout: none;
This issue happens consistently whenever these styles are set, leading to the crash inside WKWebView.
Is this a known bug in the current iOS 26 betas, or is there a recommended workaround?