Is ServiceWorker supported on WKWebView? As per Mozilla Developer Network(MDN Web) docs[1] its not supported, but our research shows that ServiceWorker becomes available for a domain in WKWebView 1) if the domain is allowlisted in app-bound domains[2] or 2) if app is registered as default browser(this can not be considered for our app as its not a browser).
How to enable ServiceWorker on WKWebView? Is adding domain as app-bound domain the right/only way to enable ServiceWorker on WKWebView? We didn't find any official documentation about this.
Can WebView get ServiceWorker support by default without enabling app bound domains since that is not an option for our app? Our app needs to support more than 10 domains. Powerful APIs such as JavaScript injection, cookie manipulation, event handlers are by default available to all domains/WebView instances even if App doesn't enable app-bound domains. Is it possible to do same for ServiceWorker?
If ServiceWorker can not be supported by default then can Apple provide a feature by which ServiceWorker will be enabled in App for all the domains?
Apple enforces maximum of 10 app-bound domains. Is it possible to remove this limit and provide a way to dynamically add to this list at the time of a request?
[1] https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker#browser_compatibility
[2] https://webkit.org/blog/10882/app-bound-domains/
Explore the integration of web technologies within your app. Discuss building web-based apps, leveraging Safari functionalities, and integrating with web services.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
System/device combinations where the issue does not occur:
Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max
System/device combinations where the issue does occur:
System versions:
Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340)
Simulator: iOS 26.0 (23A339)
Device models:
Physical device: iPhone 12
Reproducible in Safari, WKWebView, and UIWebView:
Yes
Actual behavior
In WebView (and identically in Safari):
Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected.
After the keyboard appears, the visualViewport position changes.
Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned:
When scrolling down, the position looks correct.
When scrolling up, the header/footer are visibly offset.
Steps to reproduce
Focus an input field → the keyboard appears
Dismiss the keyboard
Observe that visualViewport.offsetTop remains >0 (does not reset to zero)
position: fixed header/footer elements are misplaced relative to the screen
Expected behavior
After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0.
When scrolling upward, fixed elements should remain correctly positioned within the layout viewport.
Minimal reproducible demo
A simple HTML file containing:
A header and footer with position: fixed
An input element to trigger the keyboard
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" />
<title>H5 吸顶吸底页面 Demo</title>
<style>
* {
margin: 0;
padding: 0;
box-sizing: border-box;
}
body {
font-family: Arial, sans-serif;
height: 2000px; /* 设置内容高度 */
background-color: #f0f8ff; /* body 背景浅蓝色 */
padding-top: 120px; /* 预留 header 高度 */
padding-bottom: 60px; /* 预留 footer 高度 */
overflow-x: hidden;
}
/* 吸顶 Header */
header {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 120px;
background-color: #ff6b6b; /* 红色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 24px;
font-weight: bold;
z-index: 1000;
}
/* 吸底 Footer */
footer {
position: fixed;
bottom: 0;
left: 0;
width: 100%;
height: 60px;
background-color: #4ecdc4; /* 青绿色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 18px;
font-weight: bold;
z-index: 1000;
}
/* 输入框样式 */
.input-container {
margin: 100px auto;
width: 80%;
max-width: 600px;
text-align: center;
}
input[type='text'] {
padding: 12px;
font-size: 16px;
border: 2px solid #ddd;
border-radius: 8px;
width: 100%;
box-sizing: border-box;
}
input[type='text']:focus {
outline: none;
border-color: #4ecdc4;
}
</style>
</head>
<body>
<!-- 吸顶 Header -->
<header>吸顶 Header (120px)</header>
<!-- 主体内容 -->
<div class="input-container">
<input type="text" placeholder="请输入内容..." />
</div>
<!-- 吸底 Footer -->
<footer>吸底 Footer (60px)</footer>
</body>
</html>
My app Frax has long used a mechanism where a local webpage calls out to web-hosted content. In iOS 17.5+ (and iOS 18 beta) this has recently stopped working. The content fails to load, and the console log (running on iOS 17.6.1) contains:
nw_application_id_create_self NECP_CLIENT_ACTION_GET_SIGNED_CLIENT_ID [80: Authentication error]
Failed to resolve host network app id
followed shortly by:
Error acquiring assertion: <Error Domain=RBSServiceErrorDomain Code=1 "((target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.rendering AND target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.networking AND target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.webcontent))" UserInfo={NSLocalizedFailureReason=((target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.rendering AND target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.networking AND target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.webcontent))}>
0x128024480 - ProcessAssertion::acquireSync Failed to acquire RBS assertion 'XPCConnectionTerminationWatchdog' for process with PID=9736, error: (null)
This same code has worked reliably for years, and continues to work properly under iOS 16 and earlier. But there are increasing reports of this new error showing up around the web. Nothing in recent iOS 17 release notes sheds any light on what might have changed, and all my efforts to troubleshoot or mitigate this issue have failed. Any help on how to solve or work around this would be greatly appreciated!
Topic:
Safari & Web
SubTopic:
General
I’m experiencing an issue in WKWebView on iOS 26 Developer Beta 8. If a view's subview contains a WKWebView, using the CALayer's renderInContext method fails to capture the pixel at the current point, and the console outputs "unsupported surface format: &b38".
The following code snippet was functioning as expected on iOS 18 and iOS 26 beta 1. However, it no longer works in the latest beta.
Is this a known bug in the current iOS 26 betas, or is there a recommended workaround?
- (BOOL)isTransparentAtTouchPoint:(CGPoint)point layer:(CALayer *)layer {
unsigned char pixel[4] = {0};
CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();
CGContextRef context = CGBitmapContextCreate(pixel, 1, 1, 8, 4, colorSpace, (CGBitmapInfo) kCGImageAlphaPremultipliedLast);
CGContextTranslateCTM(context, -point.x, -point.y);
[layer renderInContext:context];
CGContextRelease(context);
CGColorSpaceRelease(colorSpace);
CGFloat alpha = pixel[3] / 255.0f;
return alpha < 0.01;
}
Since probably the late iOS 17.4.x, 17.5.1 and still now in 17.6 beta our extension has been experiencing issues with the accompanying background script or service worker being permanently killed with no warning after about 30-45 seconds after initial installation (installation, not page load!).
In all other browsers (including Safari on MacOS) unloading the service worker is part of the normal lifecycle to save memory and CPU if it is idle. In our extension the service worker is used only during the first 5-10 seconds of every page visit, so we are used to seeing it unload after that and consider this a good thing. However, normally, the service worker is able to wake back up when needed - which is no longer the case in iOS.
Once dead, nothing a normal user would do can wake the service worker back up:
No events like webNavigation or similar will trigger anymore
Any attempt to call sendMessage to it from a content-script also does not wake up the service worker and instead returns undefined to the content script immediately
Closing and opening Safari does not start it again
The only two things that will give the service worker another 30-40 seconds of life is a reboot of the device or disabling and then re-enabling the extension. During those few second the extension is working perfectly.
There are no errors or indications in the logs of what is going on and the extension works just fine in Chrome, Firefox, Edge as well as Safari on MacOS and Safari in the Mobile simulator. Only actual iOS devices fail.
It seems like a temporary workaround is to change the manifest to not load the service worker as a service worker by changing
"background": {
"service_worker": "service.js"
}
to
"background": {
"scripts": ["service.js"],
"persistent": false
}
With this change (courtesy of https://forums.developer.apple.com/forums/thread/721222) the service worker is still unloaded but correctly starts up again when needed. Having to make this change does not seem to be consistent with manifest v3 specs though (see this part in Chrome’s migration guide as an example: https://developer.chrome.com/docs/extensions/develop/migrate/to-service-workers#update-bg-field).
According to the release notes of 17.6 beta this bug was supposedly fixed:
“Fixed an issue where Safari Web Extension background pages would stop responding after about 30 seconds. (127681420)”
However, this bug is not fixed - or at least not entirely fixed. It seems to work better for super simple tests doing nothing but pinging the service worker from the content script, but for the full blown extension there is no difference at all between 17.5.1 and 17.6.
Has there been a change in policy about service workers and background scripts for Safari in iOS?
Are anyone else seeing this issue?
Also seemingly related:
https://forums.developer.apple.com/forums/thread/756309
https://forums.developer.apple.com/forums/thread/750330
https://developer.apple.com/forums/thread/757926
https://forums.developer.apple.com/forums/thread/735307
(1) Context: Our project has a login feature via WEBVIEW (using SFSafariViewController) and integrates PassKey on the Web side.
The app listens for a successful login by capturing the redirect URL via the delegate of SFSafariViewController.
(2) Issue:
On iOS < 18.4: The redirect URL is captured with full parameters returned.
https://xyz.com/home?session_state=...&code=...
On iOS ≥ 18.4: The redirect URL is captured successfully but missing parameters.
https://xyz.com/home
We currently suspect that the issue originates from the SFSafariViewController framework after the release of iOS 18.4.
Has anyone experienced a similar issue?
We would also appreciate support from the Apple team.
I'm testing web extension to safari on iOS. I've built and added extension application to simulator, but on safari settings shows no extensions.
I'm using Xcode 16.3 beta 2 with Simulator iOS 18.4 (22E5216h), tested on iPhone 16.
https://app.screencast.com/oUq4EMonmfT7u
https://app.screencast.com/MCquvHzmZi8QS
If you create a cookie and add to the WKWebViewConfiguration the completionHandler returns 'Cookies synced' suggesting cookie was added with success. However, upon inspection of app in Safari the cookie is not there. This is broken in iOS 18 beta and works in previous versions without issue. Did Apple change the WKWebView API and break this feature?
code snippet:
NSDictionary* settings = self.commandDelegate.settings;
WKWebViewConfiguration* configuration = [self createConfigurationFromSettings:settings];
configuration.userContentController = userContentController;
NSMutableDictionary *cookieProperties = [NSMutableDictionary dictionary];
[cookieProperties setObject:@"foo" forKey:NSHTTPCookieName];
[cookieProperties setObject:@"bar" forKey:NSHTTPCookieValue];
[cookieProperties setObject:@"mydomain.com" forKey:NSHTTPCookieDomain];
[cookieProperties setObject:@"mydomain.com" forKey:NSHTTPCookieOriginURL];
[cookieProperties setObject:@"/" forKey:NSHTTPCookiePath];
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
[configuration.websiteDataStore.httpCookieStore setCookie:cookie completionHandler:^{NSLog(@"Cookies synced");}];
WKWebView* wkWebView = [[WKWebView alloc] initWithFrame:self.engineWebView.frame configuration:configuration];
Topic:
Safari & Web
SubTopic:
General
Tags:
WebKit
Feedback Assistant
Safari Developer Tools
Web Inspector
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?
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
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!
Running a web server on localhost is breaking on the iOS Simulator. It is also blocking me from testing my mobile application.
Full Log:
Full Log
I don't know why but all of a sudden when I build the extension it just doesn't load in Safari. The build executes fine but the extension doesn't load. Sometimes, through trying different combinations of clearing the build folder, building, archiving, ... it suddenly loads. And the next time I build again it doesn't load properly. So I can't do any work on it or test anything.
I don't know why all of a sudden I am getting this behavior. It looks like engineers at Apple are constantly trying to overcomplicate a process that is at least ten times simpler in any other browser. This is ridiculous. Is this what our annual fee goes to? And they don't even provide any support for that. Several times I've tried to get some help here just to have to spend hours upon hours to figure it out by myself. I'm so tired of this.
If the Safari Technology Preview window is located on an external monitor with DisplayLink and the computer goes to sleep (screen saver), when it returns, it closes with an error.
If the window is located on another monitor that is connected by USB, it does not close.
Equipo: Macbook Pro M4 Pro
SO: MacOS Sequoia 15.6.1
Safari Technology Preview: Release 227 (preview version work fine)
DisplayLink Manager: 13.0.1 (build 46)
Hi, I am developing the Click & Read web add-on for Chromium, Firefox and Safari.
We use xcrun safari-web-extension-converter tool to generate the Safari add-on. The build on Xcode had no meaning errors/warnings, until we had to switch to a more up-to-date MacBook (required as deprecated Mac had no support for latest macOS and thus for Xcode compatibility !).
So now I build my add-on on an Apple M1 MB Air on Sequoia 15.0 with latest Xcode, but I encounter an error ? or warning ? :
NSBundle file:///System/Library/PrivateFrameworks/MetalTools.framework/ principal class is nil because all fallbacks have failed
Unable to create bundle at URL ((null)): normalized URL null
Unable to create bundle at URL ((null)): normalized URL null
Unable to create bundle at URL ((null)): normalized URL null
But it doesn't prevent the add-on build to complete as I am able to open it onto Safari. Then, when loading the add-on on a test web page, I get this error on safari console:
Error: Invalid call to runtime.connect(). No runtime.onConnect listeners found.
BTW, the same add-on Dist works as expected on Chrome or Firefox (on macOS).
So it seems the runtime listener runtime.onConnect.addListener isn't initiated on Background script...
Thanks for your feedback and help
Hi, I had been working on an extension without any issues, running it from Xcode and debugging locally in Safari. However, without making any code changes, and after uninstalling the extension, it stopped appearing in Safari after building for local debugging. Does anyone know what might be happening or how I can clean up the system?
Thanks a lot and best regards.
Topic:
Safari & Web
SubTopic:
General
Tags:
Xcode
Safari Developer Tools
Safari Extensions
Safari and Web
It seems Safari 18's fetch() does not include credentials even credentials: include and safari extension has host_permissions for that domain.
Is there anyone has this problem?
I try to request in popup.js like this:
const response = await fetch(
url,
{
method: 'GET',
mode: 'cors',
credentials: 'include',
referrerPolicy: 'no-referrer',
}
);
and it does not include the cookie from host_permissions.
Those code worked in Safari 17 (macOS Sonoma).
There is a change log in Safari 18 Beta mentioning that you can now via MDM control Safari's extensions state and make an extension be enabled after you've installed it - "Added support for Device Management of extension enabled state, private browsing state, and website access on Managed Devices. (113051857)"
However I could not find any documentation for it, I need to know what to set in my plist/mobileconfig file.
Does anyone know (or maybe apple is here as well and can help) where would this be documented?
Thanks!
Safari Version 14.0.1 (16610.2.11.51.8)
I am porting a Chrome/Firefox/Edge extension to Safari Web Extension. Mostly, the process was painless, I am, however, seeing quite different behavior in the tab ids generated by Safari compared to Chrome, Firefox, and Edge. My extension has callbacks for each of these browser.webNavigation events:
browser.webNavigation.onBeforeNavigate
browser.webNavigation.onCommitted
browser.webNavigation.onDOMContentLoaded
In each of these I rely on the tab id for various future tab targeting operations. When opening a new tab, the details object passed to each of these callbacks has a non-zero tabId on Chrome, Firefox, and Edge. However, in Safari, the tabId is always zero. To debug, I added one more callback:
browser.webNavigation.onCompleted
At this point Safari finally has a non-zero tabId in the details param. Needless to say this is causing some consternation with achieving the same outcomes as tab tracking on Chrome, Firefox, and Edge. It's like Safari is treating new tabs as "non tabs" until navigation completes. You can even see it when trying to get the tab by tabId=0:
browser.tabs.get(tabId) // tabId=0 here
	.then(tab => {
		// tab is undefined
	});
Seems like this might be a bug. I can't imagine why the behavior is so different from other browsers. Any ideas on how to work around?
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?