Post not yet marked as solved
We believe that this issue is resolved in iOS 17.5, please test against the latest developer seed to see if your extension still experiences this issue. If it does, please let us know using http://feedbackassistant.apple.com/ and share the Feedback ID here.
Post not yet marked as solved
I would like to specify Connection: close for a request that I load in WKWebView - which actually CAN be done by setting the value on the request that is loaded (and it actually works). However, the documentation at https://developer.apple.com/documentation/foundation/nsurlrequest#1776617 states that it shouldn't be used because the URL loading system handles persistent connections for you. So - my question is how can I indicate to the URL Loading System that I do NOT want to use persistent connections for this particular request? Or - am I safe to just set the header even though it's listed as reserved (because - as mentioned - it does work)?
Post not yet marked as solved
Since updating to iOS v17.4.1 our safari extension no longer functions as it used to We are experiencing issues where our content script is not getting initialized, On devices running iOS 17.4.1, the content script included in our extension does not appear to run. There are no logs from the content script in the console, whereas on other versions and devices, it operates as expected. Our Extension relies con communication between the background and content scripts in order for us to render various popups to our users, based on our logs as of iOS 17.4.1 this communication is not successful, we can see messages being sent from the background script but as mentioned above nothing on the content script side. This behavior happens majority of the time and on random sites, sometimes opening the same site in a new tab would work but not always. There are also times where we would only receive our popups after opening the safari menu and interacting with our extension via this menu. Please assist with a way forward
Post not yet marked as solved
I'm not sure if I just missed a recent breaking change, but we are having an issue with the camera in our single page app on iOS 17.4.1 in Safari. We can open the camera and display it to the user using getUserMedia. However, if the path of the site changes at all (for example, the user clicks a button to opens a sidepanel which results in the path in the browser changing) the camera goes black, even if the video element is still being displayed. I can see in the browser that the camera has stopped, and the user has to re-enable it manually by tapping Start Using Camera. Any idea's what could be going on here?
Post not yet marked as solved
Does IOS 17.5 beta2 resolve this issue?
Post not yet marked as solved
Found a bad quick fix: if cases don't matter in username, you can just give each entry a different variation. For example user123, User123, uSer123, ... Not the solution one would want, but it works for now
Post not yet marked as solved
M1 Air, Sonoma., Books.app. How to open an inspector? old method defaults write com.apple.iBooksX WebKitDeveloperExtras -bool YES doesn't work
Post not yet marked as solved
I have the same problem now. Anyone fixed this ?
Post not yet marked as solved
I was also unable to download the container from my iPhone 13 Pro on iOS 17.4.1, using Xcode 15.3. Here is the brute force solution I used... I added this temporary code to my AppDelegate didFinishLaunchingWithOptions, which removes the folder containing the non-transferable file and exits (gracefully, but using a private API). if true { if let directoryURL = FileManager.default .urls(for: .libraryDirectory, in: .userDomainMask) .first?.appendingPathComponent(WebKit) { do { try FileManager.default.removeItem(at: directoryURL) let selector = Selector(terminateWithSuccess) UIApplication.shared.perform(selector, with: UIApplication.shared, afterDelay: 0) } catch { /* can’t remove item (error) */ } } } The container can now be downloaded until such time as the application uses the WebKit again, which will re-create this non-transferable file. Come on, Apple ! 👉 Make sure you switch from true to false before uploading your app to the App Store !
Post not yet marked as solved
Hi again. Does anyone have any news about this? Safari Safari 17.5 beta went out and release notes mention nothing related to fullscreen. Previous Safari 17.4 release notes contanis 8 fullscreen mentions, but none seems related to this issue. For that matters, I cannot seems to find release notes for 17.4 intermediate beta releases, and the (in)famous statement Fixed multiple issues by disabling support for the Fullscreen API on iOS is absent in final release notes, so I might guess that statement has been reverted? Still, I cannot figure out what to do of the last comment above by Apple Staff, the one at the bottom of page 1, starting with Safari's Fullscreen API implementation was updated [...].
Post not yet marked as solved
At my work we are making a React App with Tailwind CSS. ever since the new update, safari has been going dark seemingly randomly across the interface. Has anyone else experienced this or found out what may be causing safari to do this?
Post not yet marked as solved
same problem since 17.4.1, there are many redundant thin lines on many pages!!!
