I'm trying to run a MacOS shortcut using the "Run JavaScript on Active Safari Tab" action. I consistently get the error "Make sure that 'Allow JavaScript from Apple Events' is enabled in the Develop menu in Safari." The Develop menu in Safari does not contain this switch (in Tahoe 26.5.1), but if you go to Developer Settings... a dialog opens that includes the required switch. I've ensured that the switch is set on, but I continue to get the runtime error in the shortcut JavaScript. What am I missing?

Safari continues to display a "Fraudulent Website Warning" for openvan.camp despite the domain being clean across all major security databases for over a week. Chrome, Firefox, and all other browsers open the site without any warnings. Domain: openvan.camp Warning appeared: March 18, 2026 Warning type: Fraudulent Website Warning (red screen) Current security database status: Google Safe Browsing: ✅ Clean (transparencyreport.google.com) Google Search Console: ✅ No security issues Spamhaus DBL: ✅ Removed from blocklist Fortinet FortiGuard: ✅ Category "Travel" VirusTotal: ✅ 0/65 vendors URLVoid: ✅ 0/35 engines Steps taken: Removed the third-party ad network (Adsterra) that caused the original flag — March 18, 2026 Migrated hosting to Scaleway (AS12876, France), IP: 151.115.84.228 Configured SPF, DKIM, DMARC records Created functional abuse@ and postmaster@ role accounts Submitted review via websitereview.apple.com — no response after 5 days What we believe is happening: Apple's Safe Browsing database appears to have an independent entry for this domain that has not been updated despite all underlying security databases clearing the flag. Safari's warning persists even after deleting ~/Library/Safari/SafeBrowsing/ cache and re-downloading the database — which confirms this is not a local cache issue. Steps to reproduce: Open Safari on macOS or iOS Navigate to https://openvan.camp/ Safari displays "Fraudulent Website Warning" Open the same URL in Chrome — no warning Expected behavior: No warning should be shown. The domain is legitimate, clean, and verified. Has anyone experienced a similar issue? Is there any additional channel to escalate beyond websitereview.apple.com?

Has anyone else observed intermittent first-navigation failures in Safari on iOS 26 when HTTP/3 0-RTT resumption is available? Environment: iPhone 16 Pro, iOS 26.5.2 (23F84), Mobile Safari Wi-Fi with native IPv6 Cloudflare-proxied HTTPS hostname Normal browsing, not Private Browsing Reproduced almost daily on the first visit; an immediate reload succeeds Safari shows its native “cannot open the page because the server cannot be reached” page. The origin is healthy and neither the origin nor Cloudflare HTTP/security analytics records a corresponding HTTP failure. We captured the iPhone network interface over USB and compared a failed navigation with the successful reload. Failed navigation: DNS A, AAAA and HTTPS/SVCB answers completed normally. The HTTPS record advertised h3 and h2 with IPv4 and IPv6 hints. MobileSafari/WebKit opened several QUIC connections across the available IPv4 and IPv6 endpoints. Nearly all sent QUIC Initial packets plus 0-RTT application data. The edge replied promptly with Initial, Handshake and protected packets on both address families. Several flows did not settle and the edge retransmitted repeatedly. Safari also established a TCP/TLS fallback and received data, but still declared the navigation failed. Successful reload: One IPv4 QUIC connection. Full handshake, without 0-RTT. Normal bidirectional protected traffic and the page loaded. Control tests: Another proxied hostname succeeded with a full HTTP/3 handshake and no 0-RTT. A direct, non-proxied hostname succeeded over IPv6/TLS. HTTP/3 requests from the same Safari version otherwise received normal 200/204/302/304 responses. This looks like a CFNetwork/Network.framework/libquic session-resumption or connection-racing recovery issue rather than a WebKit rendering or origin-server problem. The encrypted capture does not let us determine whether the early data was accepted or rejected by the edge. Feedback filed: FB23764937. Important reproduction note: 0-RTT has now been disabled on the affected production zone while HTTP/3 remains enabled. Therefore that hostname can no longer reproduce the original 0-RTT path. This is an intentional mitigation; it will not be re-enabled on production solely for testing. Questions: Has anyone seen the same first-load failure followed by a successful reload on iOS 26? Is there a recommended way to collect CFNetwork/libquic diagnostics for a failure that occurs before an HTTP response exists? Should Safari replay the navigation after 0-RTT rejection or use the already-successful TCP/TLS fallback in this situation? A raw packet capture is available to Apple through the private Feedback report on request, but is not posted publicly because it contains client network identifiers.Has anyone else observed intermittent first-navigation failures in Safari on iOS 26 when HTTP/3 0-RTT resumption is available? Environment: iPhone 16 Pro, iOS 26.5.2 (23F84), Mobile Safari Wi-Fi with native IPv6 Cloudflare-proxied HTTPS hostname Normal browsing, not Private Browsing Reproduced almost daily on the first visit; an immediate reload succeeds Safari shows its native “cannot open the page because the server cannot be reached” page. The origin is healthy and neither the origin nor Cloudflare HTTP/security analytics records a corresponding HTTP failure. We captured the iPhone network interface over USB and compared a failed navigation with the successful reload. Failed navigation: DNS A, AAAA and HTTPS/SVCB answers completed normally. The HTTPS record advertised h3 and h2 with IPv4 and IPv6 hints. MobileSafari/WebKit opened several QUIC connections across the available IPv4 and IPv6 endpoints. Nearly all sent QUIC Initial packets plus 0-RTT application data. The edge replied promptly with Initial, Handshake and protected packets on both address families. Several flows did not settle and the edge retransmitted repeatedly. Safari also established a TCP/TLS fallback and received data, but still declared the navigation failed. Successful reload: One IPv4 QUIC connection. Full handshake, without 0-RTT. Normal bidirectional protected traffic and the page loaded. Control tests: Another proxied hostname succeeded with a full HTTP/3 handshake and no 0-RTT. A direct, non-proxied hostname succeeded over IPv6/TLS. HTTP/3 requests from the same Safari version otherwise received normal 200/204/302/304 responses. This looks like a CFNetwork/Network.framework/libquic session-resumption or connection-racing recovery issue rather than a WebKit rendering or origin-server problem. The encrypted capture does not let us determine whether the early data was accepted or rejected by the edge. Feedback filed: FB23764937. Important reproduction note: 0-RTT has now been disabled on the affected production zone while HTTP/3 remains enabled. Therefore that hostname can no longer reproduce the original 0-RTT path. This is an intentional mitigation; it will not be re-enabled on production solely for testing. Questions: Has anyone seen the same first-load failure followed by a successful reload on iOS 26? Is there a recommended way to collect CFNetwork/libquic diagnostics for a failure that occurs before an HTTP response exists? Should Safari replay the navigation after 0-RTT rejection or use the already-successful TCP/TLS fallback in this situation? A raw packet capture is available to Apple through the private Feedback report on request, but is not posted publicly because it contains client network identifiers.

When trying to log into the Codex Plugin from Xcode, on the auth.openai.com site I can not progress. No option will progress from that page. Not: Continue with eMail Continue with Microsoft Continue with Apple Continue with Google Continue with phone number Is this a Safari (27.0, 22625.1.22.11.4) issue, or an OpenAI issue?

My Entitlements file contains the following (removed some non related entries): <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.associated-domains</key> <array> <string>webcredentials:app.mydomain.org</string> <string>applinks:*.mydomain.org</string> </array> </dict> </plist> Now when I tap on a link such as abc.mydomain.org, the app is not opened. If I change the generic applinks key from *.mydomain.org to a specific domain, this works correctly and it opens the app as expected. (This makes me think the website part of the AASA file is correct). Since I need to support a lot of subdomains (think about hundreds in the near future), I really need the wildcard to work. Do you have any tips on how to make this work?

I have been working with visionOS 27's website environment features, and I have found when entering a website environment, leaving the website environment, waiting 10 seconds, and then trying to re-enter the website environment, the attempt fails. The thrown error reports: AbortError: Immersive request was superseded by another request Strangely, if I try to immediately re-enter the website environment, I succeed. I have to wait several seconds before trying to re-enter the environment to experience the failure. The workaround is to reload the page. Anyone know why this is occurring or how to avoid it? Anyone know a more graceful workaround than asking the user to reload the page? I have filed a feedback on this: FB23208345

Hello, Safari on iOS is showing a “Fraudulent Website Warning” for our domain: https://doobler.ru/ We are trying to understand how to properly diagnose this and request a re-evaluation. The website has a valid HTTPS certificate and does not currently appear to be flagged by the reputation tools we checked, including Google Safe Browsing / Search Console / VirusTotal. However, some iPhone users still see the Safari warning, while others do not. What we have checked so far: HTTPS certificate is valid No mixed-content or obvious redirect issues found Google Safe Browsing does not show the domain as unsafe Google Search Console does not show security issues VirusTotal does not show active malware/phishing detections The warning appears only for some users/devices We submitted a review request through Apple’s Website Review form, but have not received any response yet We would like to know: Is there any way to confirm whether the warning comes from Apple’s own reputation system, Google Safe Browsing, or another provider used by Safari? How long does Apple Website Review usually take for Safari fraudulent website warnings? Is there a recommended process for requesting re-evaluation if the warning appears to be a false positive? Are there specific technical signals Safari checks that we should verify, such as redirects, third-party scripts, domain reputation, or brand/phishing heuristics? This is affecting real users, so any guidance on the correct escalation or diagnostic path would be appreciated. Thank you.

1. System/device combinations where the issue does not occur: Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max 2. 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>

Hi, We are distributing pk pass files via a web browser. When a user taps Add in the system pass preview, the pass is added successfully, the preview is dismissed, and the user remains in the browser. From a user experience perspective, we would like to better guide users to their newly added pass in Apple Wallet. Is there a supported API, URL scheme, or documented mechanism that allows a web-based flow to transition the user to the Wallet app after a pass has been added? If direct app transitions are not supported in this scenario, what is the recommended best practice for helping users locate and open their newly added pass in Wallet? Thank you for your guidance.

In visionOS 26 (with Website Environments enabled), there was a two step action to enable the environment: click button on the left of the address bar (1 in image), then click "Open Website Environment" (2 in image). This example was shown again this year in Build next-generation experiences with visionOS 27. But I do no see this working in visionOS 27. Instead, I've needed to add a button for the user to open (and optionally close) the website environment. Is adding a button/control to the web page the new way to activate website environments?

We found an issue where the DetailURL configured in a Declarative Device Management OS update declaration is displayed on the device’s Software Update screen, but tapping the link does not open the URL on some iOS versions. This issue appears to occur specifically on iOS 26.4. The same behavior could not be reproduced on iOS 17.x or iOS 18.x devices using the same MDM command configuration and the same URL. Environment: MDM command: Declarative OS Update command Command configuration: Target OS Version: 26.5 Build Version: 23F77 DetailURL: Appleデバイスのソフトウェアアップデート宣言型構成 - Apple サポート (日本) Device requirements: Supervised iOS device Managed by MDM Connected to Wi-Fi OS update available No Safari restriction or browser launch restriction configuration profile applied Reproduction Steps: Prepare a supervised iOS device managed by MDM. Send a Declarative Device Management OS update command with the following configuration: Target OS Version: 26.5 Build Version: 23F77 DetailURL: Appleデバイスのソフトウェアアップデート宣言型構成 - Apple サポート (日本) After the command is applied, open the device Settings app. Go to General > Software Update. Confirm that the URL configured in DetailURL is displayed on the Software Update screen. Tap the displayed URL. Expected Result: The displayed DetailURL should open in Safari or the default browser. Actual Result: On iOS 26.4 devices, the URL is displayed on the Software Update screen, but tapping the link does not open Safari or navigate to the URL. On other tested iOS versions, the URL opens correctly. Test Results: Reproduced / Not working: iPhone 15 Pro, iOS 26.4: reproduced 3/3 iPhone 17e, iOS 26.4: reproduced Not reproduced / Working: iPhone SE, iOS 17.7: Safari opens successfully iPhone 14 Pro Max, iOS 17.6.1: Safari opens successfully, 0/3 reproduced iPhone 12 Pro, iOS 18.7.7: Safari opens successfully iPhone 11 Pro Max, iOS 18.7.8: Safari opens successfully, 0/3 reproduced Additional Notes: We confirmed that Safari usage restrictions and browser launch-related configuration profiles were not applied on the affected test device. A sysdiagnose was collected from the affected iPhone 15 Pro running iOS 26.4. From the logs, it appears that the Settings app / Preferences attempts to open Safari, but the URL cannot be opened. The log suggests that an invalid or unexpected URL may be passed from the Settings app when the Software Update screen link is tapped. This issue does not appear to be specific to the MDM server implementation, because the same Declarative OS Update configuration works correctly on iOS 17.x and iOS 18.x devices. Based on current testing, this may be an iOS 26.4-specific issue with how the Software Update screen handles the DetailURL link.

Environment: MacBook Air M4 macOS 27 Beta Safari Safari Technology Preview Issue: I am experiencing an issue where mouse/trackpad clicks are intermittently ignored near the bottom portion of a webpage. The trackpad hardware appears to be functioning normally, as physical clicks are registered and the issue does not occur consistently across all browsers. Steps to Reproduce: Open Safari or Safari Technology Preview. Navigate to a webpage with interactive elements near the bottom of the visible page. Attempt to click links, buttons, or text fields located in approximately the bottom quarter of the browser window. Observe that clicks are sometimes not registered. Resize the Safari window so that the affected area is no longer located in the bottom portion of the screen. Attempt the same clicks again. Expected Result: Clicks should be consistently registered regardless of their position within the webpage. Actual Result: Clicks in the lower portion of the webpage are sometimes ignored. Resizing the window may temporarily resolve the issue. Additional Information: The trackpad itself appears to function normally. Physical clicks are detected. I have observed the issue in both Safari and Safari Technology Preview. I tested the same website in Perplexity Comet, where the issue does not appear to occur. This suggests the issue may be related to Safari’s rendering, hit-testing, event handling, or window management rather than the website itself. Has anyone else been able to reproduce this on macOS 27 Beta?

After enabling WebXR following instructions from https://developer.apple.com/forums/thread/732629, I can successfully run WebXR, but it is limited to VR. I cannot get AR running. If I try await navigator.xr.isSessionSupported("immersive-ar"), the result is false. But if I try await navigator.xr.isSessionSupported("immersive-vr"), the result is true. I double checked that I specifically checked the box "WebXR Augmented Reality Module" in the Safari feature flags. Any idea how to enable WebXR AR mode? Thanks in advance!

Safari on iOS 17, when entering characters into text input box after deleting characters, the layout is off. Here's the HTML: <body> <div id="J001" style="display: inline-block;"> <div id="J001__0" style="display: inline-block;"> <input id="J001__0__input" style="display: inline-block; height: 28px; padding:2px; border:1px solid gray;"></div> <div id="J003__0" style="display: inline-block;"> <button id="J003__0__btn" style="display: inline-block; height:34px;">a</button> </div> </div> </body> Enter "A" into text input box. Delete "A" with the backspace(x). Enter "A" into text input box, the button position will be shifted down. iOS 17 の Safari にて、テキスト入力ボックスで文字を削除した後、文字を入力するとレイアウトが崩れます。 テキスト入力ボックスに「A」と入力します。 バックスペース(x)で「A」を削除します。 テキスト入力ボックスに「A」と入力すると、ボタンの位置が下にずれます。