Seeing an issue where document.cookie is returning an expired cookie. This cookie is correctly not sent in requests and is not displayed in the web inspector (Storage -> Cookies). Problem persists until safari is restarted. Affects the following user agents... Mozilla/5.0 (iPhone; CPU iPhone OS 15_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.3 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPhone; CPU iPhone OS 15_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.4 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPhone; CPU iPhone OS 15_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 Flipboard/4.2.140 Mozilla/5.0 (iPad; CPU OS 15_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/99.0.4844.59 Mobile/15E148 Safari/604.1 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.3 Safari/605.1.15 Mozilla/5.0 (iPhone; CPU iPhone OS 15_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/99.0.4844.59 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPhone; CPU iPhone OS 14_8_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPhone; CPU iPhone OS 15_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 Safari/604.1 [Pinterest/iOS] Mozilla/5.0 (iPhone; CPU iPhone OS 14_8 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPhone; CPU iPhone OS 15_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/19D52 [FBAN/FBIOS;FBDV/iPhone11,8;FBMD/iPhone;FBSN/iOS;FBSV/15.3.1;FBSS/2;FBID/phone;FBLC/en_US;FBOP/5] Was not able to reproduce on Safari 15.0 on OSX 10.15.7. Does not occur in desktop chrome or firefox. Seems OSX and IOS specific. Edit: the more I look at this it appears to be a webkit bug.

According to the release notes of STP, OffscreenCanvas has been implemented for a while. However, when I run JavaScript code, it fails because OffscreenCanvas is not a recognized command. I feel I’m missing something obvious here. Any help?

I am creating a react app and am making use of Webauthn to use TouchID or FaceID for user authentication. I have built my app so that when the button is clicked, navigator.credentials.create is the only call made. With attestation set to none, there are no issues however as soon as I set attestation to direct I get an alert saying 'The operation can't be completed' and 'NotAllowedError: This request has been cancelled by the user.' is logged to console. The issue only presents itself on Safari and iOS devices however works perfectly on other browsers like Chrome. Has anyone encountered a similar issue and possibly know how to resolve it? Thanks Shay

I am trying to replace gifs with mp4s on my website. Currently its working great in Chrome and Firefox, but the behavior is odd in Safari. <video autoplay loop muted playsinline defaultmuted preload="auto"> <source src="/path/to/video.mp4" type="video/mp4"> </video> This video is an h264 mp4 video with no audio track. Firefox, Chrome on my Macbook: Works as expected (autoplay's like it were a gif) iOS Safari without Low Power Mode: Works as expected iOS Safari with Low Power Mode: Autoplays but there is a play button on top that disappears when tapped. macOS Safari: Does not autoplay. A play button appears and it plays if clicked. I have been following https://developer.apple.com/documentation/webkit/delivering_video_content_for_safari as well as other guides on the internet and it still isn't working. I'm pretty sure there is a recent change responsible for this because it used to work in an older version of desktop safari.

I posted in the other but they removed it and told me to Post here but anyone know what might have changed or what new experimental feature was added to the list for safari the last two updates? I have been having massive slow or lagging and glitches with my games and safari after this last update. So trying to see which was was newly added.

I'm currently developing a React (non Native) PWA. It runs perfectly fine on Safari but if I add it to the home screen to run it on standalone mode the performance is much worse. I've had this issue on the iOS 16 betas and now on the official release too. If I go into Settings > Safari > Clear History and Website Data the performance improves but only for a while. Any ideas what could be causing this?

I'm porting a Chrome extension to Safari. All works well besides the auth flow, which uses SameSite=Strict cookies. On Chrome, such cookies are easily set and work as expected, but not on Safari. Now, as I understand, technically, requests from chrome-extension:// and safari-web-extension:// origins are cross-site in relation to the server, which makes me think that on Chrome, the SameSite=Strict attribute is simply ignored as an exception for extensions. With that said, the backend team wants to keep the attribute for security reasons and so removing it or replacing it with SameSite=None isn't an option. Is this an intended behavior of Safari or a bug? Is there a way to get around this without changing the attribute?

Safari is returning 0 for --safe-area-inset-bottom when I use getComptutedStyle method on Iphones running on ios +15 both on portrait and landscape mode when the toolbar is hidden. I can guess that it's desired when the address bar is on the bottom and is hidden, however, is it supposed to return 0 when the address bar is set to be on the top (like on the ios versions -15) and the toolbar is hidden? Is it intended or an overlook from Safari? Comparison between versions: Safari ios14 hidden top toolbar portrait --safe-area-inset-bottom : 34, Safari ios14 hidden top toolbar landscape --safe-area-inset-bottom: 21 Safari ios 15+ hidden top toolbar portrait --safe-area-inset-bottom : 0, Safari ios 15+ hidden top toolbar landscape --safe-area-inset-bottom: 0

Hi, We have recently noticed that the speech recognition API in Safari is extremely slow and inaccurate, specifically on iPhone 14 with iOS 16.1.1 … but works fine on iPhone 12 with the same iOS 16.1.1. Does anybody else run into the same issue or have any suggestions?

Open music.yandex.ru Open browser console Paste this code: navigator.mediaSession.metadata = new MediaMetadata({ title: "11111111111", artist: "222222222", album: "3333333333", artwork: [ { src: "https://avatars.yandex.net/get-music-content/5375761/c8e05100.a.19837155-1/200x200" } ]}); Open Now playing widget. Title, artist, album is set correctly. Cover not set. macOS 13.0.1 (22A400) Safari 16.1 (18614.2.9.1.12) Note! In macOS 12.6.1 Safari 15.6.1 (17613.3.9.1.16) all works as expected.

We have a Safari browser extension experiencing an issue we believe the be caused by an iOS bug. The issue is affecting physical devices, particularly iPads with low amounts of RAM. When RAM usage goes up, iOS appears to kill the Service Worker to free up memory. Then, even after the RAM usage has gone down, the Service Worker does not come back. The only way to bring it back is for the user to manually disable and re-enable the extension, meaning any functionality that required the Service Worker to function remains broken. We have been able to reliably reproduce this crash on multiple mobile devices We do not see any memory leaks or particularly high usage, but we do see low memory warnings. The worker appears to be killed when RAM usage hits approx. 80%. Note that this is NOT related to the normal lifecycle of a service worker, once the background process is killed the connection is completely severed and it can not recover on its own.

The Problem: I am building an app that uses PayPal for payments, and I set up universal links so that the user gets redirected into the app after the user has confirmed the payment at PayPal's site. Universal links are working in general. But here is what I have discovered: The following scenario works: The app opens the nextActionUrl from PayPal using SFSafariViewController. User has to log in and presses the login button. User presses the confirmation button on the PayPal site. PayPal redirects to the return_url that was provided when creating the payment intent. The browser closes, and the user gets redirected into the app. Now when the user has just recently logged into PayPal then PayPal does not show the login page, instead the user has to only press one button. This scenario fails: The app opens the nextActionUrl from PayPal using SFSafariViewController. User does not have to log in and presses the confirmation button on PayPal site. PayPal redirects to the return_url that was provided when creating the payment intent. The browser opens the website behind the universal link instead of redirecting to the app. This scenario also works: The app opens the nextActionUrl from PayPal using SFSafariViewController. User does not have to log in, but actively logs out. User has to log in and presses the login button. User presses the confirmation button on the PayPal site. PayPal redirects to the return_url that was provided when creating the payment intent. The browser closes, and the user gets redirected into the app. This happens consistently and reproducible. Some additional details: I am developing the App using Flutter I set up the Runner.entitlements as follows: ... <key>com.apple.developer.associated-domains</key> <array> <string>applinks:sub.example.com</string> </array> ... I set up the Info.plist as follows for deep links with different schema: ... <key>CFBundleURLTypes</key> <array> <dict> <key>CFBundleTypeRole</key> <string>Editor</string> <key>CFBundleURLName</key> <string>sub.example.com</string> <key>CFBundleURLSchemes</key> <array> <string>web+example</string> </array> </dict> </array> ... I set up the apple-app-site-association file on the website at https://sub.example.com/.well-known/apple-app-site-association as follows: { "activitycontinuation": {}, "webcredentials": {}, "applinks": { "apps": [], "details": [ { "appID": "XXXXXXXXXX.com.example.example", "paths": [ "/*" ] } ] } } To open the urls from Flutter I am using the package url_launcher and simply call await launchUrl(nextActionUrl) What I've tried and what I've learned: I tried many things, before I discovered this consistent behavior. For example: I connected my device to the mac and opened the console for it in xcode to see how the logs look like when it works and how it looks like when it does not work. I found out that when it works there is a log entry that requests the switch to my App from the SpringBoard-process: [Received trusted open application request for <applicationId> from <FBProcess: ...], but in the cases where it does not work there isn't a rejected request or anything. The SafariViewController does not even seem to try to go the universal link route and instead opens the link as a website directly. For even more logs, I pressed and hold the volume buttons and clicked the lock screen button until a haptic feedback occurred. After that, I extracted the syslogs that were generated from the settings/privacy section via AirDrop on to the mac. I took a look at the swcutil_show.txt file and the universal link is definitely set up correctly there. I also skimmed around in the other logs, but I couldn't find anything helpful. I have inspected the url_launcher package to see how it works for iOS and if there may be something wrong, but I didn't really find a problem. I only discovered that the package is using the SFSafariViewController and after some googling I've read the WKWebView would be more suitable, but it didn't seem to be the problem. I googled a lot and found many problems related with setting up universal links correctly, but no topics about universal links sometimes working and sometimes not. The only thing close I found was that a universal link won't redirect you to your app if you type it into safari directly but if you click it for example from an email. The work-a-round that works... After I confirmed that it consistently works after logging in first, my theory was that it needs at least one navigation between opening the PayPal site in the browser and PayPal redirecting to the universal link. To confirm my theory, I created an intermediate page that redirects the user immediately after the load event to the PayPal site, and I was disappointed. It didn't change anything. Then I thought: Maybe it's the User-Interaction that is needed, and I change the intermediate page to only redirect if the user presses a button. And from there on, redirecting to the App using a universal link always worked. But this isn't a nice solution - at max, this is an ugly work-a-round that may help someone. My question(s) Now I am not sure if this is a bug on Apple's side since I didn't find anything on the web or maybe even something strange on PayPal's side? Am I doing something wrong? Did someone experience the same thing and has a solution? Thank you for your time and hopefully for your input on this!

Hi, I am trying out push notification for IOS 16.4 beta Simulator using Xcode 14.3 beta (14E5197f). Inside my JS code I have the following: Notification.requestPermission((permission) => { console.log(permission); }).catch((error) => { deviceNotSupported(); }); } Unfortunately "permission" always returns "denied". Please kindly assist

I managed to get my Progressive Web App to send notifications to users via Web Push. However, it seems that the definable actions are not working. In Chrome, there is a button in the notification. If you click it, you get an overview of the available actions that the user can click. When I look at the notification on iOS, I only see the "View" action. My self-defined actions seem to be ignored and not displayed. Also, the "notificationclick" event should be executed by the browser as soon as the notification is clicked. In the Serviceworker I listened to the event and tried to link to a specific page of the PWA. In Chrome and Firefox this works fine. In Safari / iOS I only get to the start page of the PWA. Are the notification actions not yet supported with WebKit 16.4 ?

version: iOS 16.4(20E5239a) both on my iphone and Simulator，Safari -> develop shows "no inspectable applications"

Hello, Safari Desktop: Version 16.4 (18615.1.26.11.22) EDIT: This is related to the Macbooks "Low Power Mode" being set to "Only on Battery" and the power adapter not being connected. My battery is at 41%. The programatic playing of videos gets blocked even though the browser settings specifically should allow all video plays. The video is muted. Once I click anywhere inside the body the play no longer gets blocked. notallowederror: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission The behaviour is the same when I select the default option "Stop Media with Audio". I was not able to see this behaviour in previous Safari versions. On iOS this issue is not present. Is anyone else experiencing the same issue? This seems to be a bug? Thank you

Hello, I'm working for an IT company which edit Web apps and we use HTML tags with type="date" and type="time". Actually, we've got different problems on Safari (what I read was that these problems appeared with Safari 16). For and , the User Agent of Safari create tags inside tags (with pseudo-class "-webkit-datetime-edit-day-field" for instance) to display "ghost"/faked data when the value is empty or NULL (in fact, Safari display the current date, in the local format, in ). This behavior is really problematical for us because these inputs don't have to be filled every time (they are not required and don't have the attribute "required"), but they appear filled to our users... When you submit the form, the value is really empty (no value returned and that is what we want) but "something" is always displayed. We found a CSS trick to hide these things to our users but I think it's not normal, isn't it ? Can we block this Safari behavior ? Second problem : for , they are not editable anymore if their value is empty (we detect it thursday, April 6th 2023). However, if we put a specific value when we load the page, then we delete this value in the form, and then we change the value without loosing the focus of the input, it works. If we loose the focus, we can't click on the input to change its value or something else. Do you know the reason why ? For now, we are forced to change the type of these inputs to type="text" when users are on Safari in Javascript... Nevertheless, the official documentation (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date and https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time) talks about compatibility between and Safari. Any idea ? Thank you for your time.