Your connection was interrupted. A network change was detected. ERR_NETWORK_CHANGED This started to happen on my Chrome/Brave Browser just after I updated my MacOS to developer beta (Version 15.0 Beta (24A5279h)).

Hello, I've encoutered an issue with Safari App Extensions. My extension prints lots of suspect error logs in the Xcode console and inside Console.app. This happens basically whenever I make any interaction with the App Extension or with Safari. The most common and predictable error log I get is: No current extension context; trying most recent context (Subsystem: com.apple.SafariServices) However, I also sometimes get the following error messages, albeit less frequently, which may be related: No extension context for best match No extension context for remote object Error connecting back to host for remote object: NSCocoaErrorDomain, code: 4099 No known extension contexts for profile 00000000-0000-0000-0000-000000000000 Most recent extension context B7223E12-B563-45E0-97F8-50500BC6B994 does not have connection back to host; trying best match context I haven't been able to find anything about these error logs in Apple documentation or on the Internet, so I did a bit of empirical investigation. I reproduced the bug in the following basic scenario: I've created a new Safari App Extension project in Xcode by going to File > New > Project > Safari Extension App. I've selected "Safari App extension" for the type and "Swift" for the language. The project comes by default with a "SafariExtensionHandler.swift" file, which includes the following code: override func validateToolbarItem(in window: SFSafariWindow, validationHandler: @escaping ((Bool, String) -> Void)) { validationHandler(true, "") } No issues so far. If I add the following call: override func validateToolbarItem(in window: SFSafariWindow, validationHandler: @escaping ((Bool, String) -> Void)) { validationHandler(true, "") SFSafariApplication.getActiveWindow { window in // code } } There are still no error messages logged in the Console. However, if I do this instead: override func validateToolbarItem(in window: SFSafariWindow, validationHandler: @escaping ((Bool, String) -> Void)) { validationHandler(true, "") DispatchQueue.main.async { SFSafariApplication.getActiveWindow { window in // code } } } Then my Xcode console starts being spammed with "No current extension context; trying most recent context" error logs. With some more testing, it seems that the most common/predictable situation that causes the error log seems to be when calling any Safari API (e.g. SFSafariApplication.getActiveWindow{} or even SFSafariApplication.setToolbarItemsNeedUpdate()) outside of a direct method call provided by the Safari App Extension API. So making API calls directly from inside validateToolbarItem(in:, validationHandler:) or messageReceived(withName:from:userInfo:) calls is fine, but anything else causes "No extension context" logs. The bug even reproduces if you make a Safari API call directly inside of an @IBAction method call caused by a button click inside the Safari popover of the Safari App Extension. With this being the case, it seems to be impossible to make clean Safari API calls in an asynchronous or proactive way, which is problematic for our app extension use case and which seems to defeat the purpose of some of the API calls like SFSafariApplication.setToolbarItemsNeedUpdate(). Also, this seems to be a new issue. I've tested these scenarios on various macOS versions that I had on hand (specifically, on macOS 10.15 Catalina, macOS 13 Ventura and macOS 14 Sonoma) and the bug seems to reproduce only on macOS 14 Sonoma. The Safari App Extension behaves as expected on previous macOS versions, with no suspect error logs. Does anyone know what this issue is about?

Hello, I'm trying to learn swift and making the Landmarks tutorial I found a problem with the map view. The error read as follow: "'init(coordinateRegion:interactionModes:showsUserLocation:userTrackingMode:)' was deprecated in iOS 17.0: Use Map initializers that take a MapContentBuilder instead." My code is: import MapKit struct MapView: View { @State private var region = MKCoordinateRegion( center: CLLocationCoordinate2D(latitude: 34.011_286, longitude: -116.166_868), span: MKCoordinateSpan(latitudeDelta: 0.2, longitudeDelta: 0.2) ) // The error happens here! var body: some View { Map(coordinateRegion: $region) } } #Preview { MapView() } Any suggestions about hot to solve this will be appreciate it. Thanks, BR Skalex

As I wanted to transfer my existing tabgoups from my iPhone/Mac to my new iPad (strange that it’s not working on its own) I shared the tabgroup as a message and opened it on my iPad. From that moment on I had shared tabgroups with a blue dot behind the individual tabs in the tabgroups and a menu bar on the top of each tab where I was able to discontinue the sharing. After a short while a noticed all tabs in the tab groups consisting of more than 400 tabs multiplied 5x. I am using iOS 18 beta on the iPad and iOS 17.6 on my iPhone. My MacBook Pro from 2016 wasn’t used during the sharing process, but after the Desaster started I disabled tab groups on safari settings in hopes of conserving the tab group without the multiplies on my MacBook. On my MacBook i opened safari and clicked on the shared Tabgroups whereat a warning poped up that MacOsx 13 or later is required for using shared tabgroups nonetheless all tabs are multiplied… please help 😀

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

I see that on some sites (possibly many) the passkeys verification freezes when devtools are opening. I tried to debug and see that it hangs in navigator.credentials.get. STR: Go to https://passkeys-demo.appspot.com/ Enter random username and click Next Enter password and click Next Create a Passkey. Sign out. Select USE ONE BUTTON SIGN-IN INSTEAD Open dev tools. Try to Sign in with passkey. Expected result: User successfully logged in - technically navigator.credentials.get returns credentials. Actual Result: navigator.credentials.get stucks in infinite loading and nothing happened - no any errors. My assertion options looks like: { "challenge": "K8WztCaAZM5-ST7r198F6UD4iLZ09IINHSiDJBgHHq4", "allowCredentials": [], "timeout": 60000, "userVerification": "preferred", "rpId": "passkeys-demo.appspot.com" } In source code on this demo site the code options.allowCredentials = []; <---- breakpoint hit here // Invoke WebAuthn get const cred = await navigator.credentials.get({ publicKey: options, // Request a conditional UI mediation: conditional ? 'conditional' : 'optional' }); const credential = {}; <---- breakpoint NOT hit here (after removing breakpoint above and after macOS touch ID is completed)

Currently, we are developing an iOS app that includes Safari extensions. However, we are encountering an issue on iOS 17.5.1 where Safari extensions are automatically disabled. Even though the toggle for "Extensions" under "Settings" ⇒ "Safari" remains enabled, Safari does not recognize the extensions and they do not function as expected. In our developing app, this issue does not occur on other iOS versions such as 17.4.1 and 16.1.2, where the extensions work properly. If there are any specific implementation-level solutions available, I would appreciate any guidance on resolving this problem.

I run the following code on iOS Safari: const stream = await navigator.mediaDevices.getUserMedia({ video: { width: 960, height: 540, }, }); const { width, height } = stream.getVideoTracks()[0].getSettings(); console.log(`${width} * ${height}`); // 960 * 540 setTimeout(() => { const { width, height } = stream.getVideoTracks()[0].getSettings(); console.log(`setTimeout: ${width} * ${height}`); // setTimeout: 540 * 960 }, 600); The width and height of width and height of the video track obtained by synchronously are different from those obtained by asynchronously. This is my test result and userAgent: Can someone help with this issue?

Running extension either on physical device or simulator. When trying to get the console log in Safari > Develop > Device > The main page shows but when launching the popup.js extension it doesn't show in order to see console. Works fine iOS 17* Not available iOS 18 FB14109978

We are using aws amplify for our social logins with signInWithRedirect. When a user selects apple login on iphone and cancels the appleId popup, the user can't click any social login buttons anymore, including the apple one. Refreshing the page resolves this.

I implemented a universal link according to this guidance. https://developer.apple.com/videos/play/wwdc2019/717 However, my universal links seem to never work. apple-app-site-association https://hajimenavi.web.app/.well-known/apple-app-site-association Xcode settings The link I am trying to open https://hajimenavi.web.app/familyId/ZBEJSJXyPNT7G team id I validated with apple's analyzation that the server has no problem (with Setting app>Developer>Universal Links analysis. What else should I check?? I am wasting a whole day with this. Please please help.

In the iOS18 beta, under Safari, the first-level simplified code of the Chinese Wubi input method cannot type Chinese characters.

We’ve received a lot of user complains after the latest iOS 17.4 update. Our Safari extension does not work as reliably as it used to be (sometimes it’s just not loaded, or very slowly). Is this a known issue? Are any workarounds available? On iOS 17.5 the problem seems to be fixed, but I’m still wondering for a workaround because we dont know how long until 17.5 is released.

Hello there! At our company we have started to deal with an issue in the latest iOS (17.5) version. It looks like the background script of the extension becomes unresponsive after a short amount of time (around 30 seconds) after performing more than one request to it within a range of 1 - 4 seconds. How it can be tested? Pretty simple example: // content.js const t = 4000 // Using less than 4000ms makes background script unresponsive async function requestNext() { return browser.runtime.sendMessage({ greeting: "getNext" }) } setInterval(async () => { const n = await requestNext() console.log("current is: " + n) }, 4000) // background.js let counter = 0 browser.runtime.onMessage.addListener((request, sender, sendResponse) => { console.log("Received request: ", request); if (request.greeting === "getNext") { counter++ sendResponse(counter); return true } }); Whenever the browser.runtime.sendMessage is executed too fast the background script will stop working. As far as we have been able to check this only can be reproduced after 17.4.1

I am re posting this issue, as a solution still hasn't been provided. please see this original feedback ticket for all the details FB13744621 Any solution or workaround would be appreciated. Thanks

I'm experiencing a Safari Web Extension issue where the non-persistant background script seems to crash after 30 seconds even when the content script is messaging it. Here is a minimal-reproducible example. When running in an emulator, the background script will stay responsive forever. However, when running on a physical device, the background script becomes non-responsive after 30 seconds of activity. It never becomes responsive again until I toggle the extensions enable/disable toggle, after which it stays active for 30 seconds and then crashes again.

We had developed an iOS Safari web extension (which uses non-persistent background scripts) that functioned properly until iOS 17.3. However, I've encountered inconsistent behavior on iOS 17.4.1, 17.5, and 17.5.1. Upon further debugging, I noticed that the background scripts often become idle and are unloaded frequently. They are not loaded again even for the registered webNavigation events and only trigger when interacting with the extension popup menu. This is also mentioned here. I had tried this in both manifest versions 2 & 3. I had tried using service_worker for background scripts. But, none of it seems to resolve this issue. Could you please clarify if this is a bug or an intended behavior? Our extension relies on webNavigation events without users having to interact with the popup menu often.

I want to execute the modifyHeaders method using a Safari extension. However, it doesn't work when I execute it in Safari. It works in Chrome. Why is that? I used this document as reference: Part of manifest.json "declarative_net_request": {         "rule_resources": [{             "id": "ruleset",             "enabled": true,             "path": "rules.json"         }]     },     "host_permissions": [ "<all_urls>" ],     "permissions": [         "declarativeNetRequestWithHostAccess"     ] rules.json [     {       "id": 1,       "priority": 1,       "action": {         "type": "modifyHeaders",         "responseHeaders": [           {             "header": "Content-Disposition",             "operation": "remove"           }         ]       },       "condition": {         "regexFilter": ".*",         "resourceTypes": [           "main_frame",           "sub_frame"         ]       }     } ] [https://developer.apple.com/documentation/safariservices/safari_web_extensions/blocking_content_with_your_safari_web_extension]

Hi i need help, I‘m on macOS Sonoma 14.4 and My Integrated Wifi Chip is broken. I recently bought a BigTec 120 Wifi Stick but it isn‘t working. Maybe it isn‘t compatible with macOS but it could be that there is a „kext“ file for it. Tom

I had to close all application vs code xcode simulator and reboot everything and it started working. Thanks!