I'm using navigator.geolocation.getCurrentPosition to retrieve the users coordinates in a PWA built with Nextjs. getCurrentPosition is called by clicking on a button. If getCurrentPosition is called afterwards, the cached value is returned. On Safari, If I refresh the page, or logout, login and call getCurrentPosition again, the getCurrentPosition error callback is called with an error code 2 - POSITION_UNAVAILABLE. After around five minutes, getCurrentPosition can be called again. Is there some kind of throttling restriction on Safari navigator.geolocation.getCurrentPosition?

Hi, I’ve encountered an issue with Safari’s behavior when Prevent Cross-Site Tracking is enabled in iOS, related to DNS filtering via an implemented NEDNSProxyProvider. Here’s a step-by-step breakdown: In Safari, when attempting to query a blocked domain (according to the filtering policy of the NEDNSProxyProvider), the page is blocked as expected. Closing Safari without closing the tab with the blocked domain. Reopening Safari – Expected result: The page remains blocked; Actual result: The page loads and bypasses the NEDNSProxyProvider (no logs are received for this flow). Tapping the refresh button causes the page to be blocked, as the DNS Proxy Provider intercepts the new request. Note: This issue is only reproducible in general tabs in Safari. In private tabs, a fresh DNS query is generated each time, and the blocking behavior works as expected. I also tested Google Chrome, where the domain is blocked consistently. I attempted to filter this issue via Content Filter, but the only connection received by NEFilterDataProvider is for com.apple.Safari.SearchHelper with ssl.gstatic.com. Could you advise on how to handle this behaviour? Would be grateful to hear any ideas

Enhancement in managing tabs in Safari It would really be awesome to bring the fascinating tab management feature of Arc Browser to Safari across iOS, iPadOS and macOS. Especially below listed features; Multitask Create Organize Rev Up Release Notes For further info , here is the official link of Arc Browser, https://resources.arc.net/hc/en-us/categories/16435255982103-Features.

Safari 18.2 on Sequoia 15.2 sends repeated Authorization header when iCloud Relay is enabled and the page is reloaded. Inside Safari Preferences -> Privacy -> Hide IP address -> from Trackers and Websites (ensure this is enabled) Visit a website that uses HTTP Authorization and authenticate oneself Reload website a couple of times and it will result in an HTTP 400 error due to repeat Authorization header sent by Safari

It's being a very long time that I discovery that in some web pages, that use function requestAnimationFrame will cause a lot of cpu, but very little in Chrome. I have already submitted this bug nearly two years ago without printout requestAnimationFrame, no one replied. I submitted again and mention requestAnimationFrame recently, hope there will be some response. If anyone interested in this issue and know some tech in javascript please help. You can enter https://www.baidu.com/ and click one of the topic in all the 百度热搜 which have 弹幕滚动(using requestAnimationFrame, and cause a lot of cpu usage) on right.

We have a web application that uses high resolution images to validate the authenticity of products. For this purpose we want to use the best camera to make the high resolution camera, on iPhone Pro devices this camera is the ultra-wide angle camera. The issue we have is how to confidently select that camera from the list returned by navigator.mediaDevices.enumerateDevices. We can't use the device ID as it change every time (and for every user), we could use the camera name but the string is translate to the device language which is very problematic. We could also just select a specific item in the list but we are not sure that the order is preserved and it makes it hard to deal with other iPhone models that don't have that ultra wide angle camera. Selecting a specific camera looks like an essential feature not only for us. What is the best option, we are looking for something that is future proof and easily scalable.

After updating Xcode to the latest version we observed that SFSafariViewController is not loading web pages on Xcode 16 Simulator with iOS 18, whenever it is presented the View Controller is empty (does not load any content) and the app freezes, but other screens that use WKWebView are working normally. Also, during tests on physical devices with iOS 18 it seems to work just fine, so it might be just a IDE version problem. Is anyone experiencing the same issue? If so, did anyone find a solution for it?

After updating my phone to iOS 18.2 2 days ago, I noticed that a website I'm working on that uses Rafael JS(https://dmitrybaranovskiy.github.io/raphael) to do some svg rendering which used to work before I updated just stopped working. I notice that Safari tries to load website tries to load 2 or 3 times before showing the error: A problem repeatedly occurred on <website> which I find really odd since this used to work before and I haven't made any changes to the code. This also happens in Chrome on iOS 18.2.

Hi, When we using Safari on MacOS with IPv6 we found that the XSRF-TOKEN can be set into the cookies. We have set-cookie in the authentication response headers 'Set-Cookie: XSRF-TOKEN=*******; SameSite=Strict; Secure'. It works by using Safari with IPv4. And also works with Chrome/FireFox with IPv4/IPv6. And also worked with Safari 15.6.1 over IPv6. May I know if this an issue or by design? Anyone aware of this? Thanks.

I’m trying to understand how the Reddit app knows to open in its anonymous mode when a link is opened from Safari’s Private Browsing mode. Does Safari explicitly pass any flag or metadata indicating the request originated from Private Browsing? Or is it inferred by the absence of shared cookies, session tokens, or other stateful data? If the detection is based on the absence of cookies, could this logic misidentify other stateless scenarios as ‘private’?

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.