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.

Although I have reduced my Mac's MTU to solve the MTU blackhole problem, Safari is quite slow if I enabled iCloud private relay (scenario 1). At the same time, Chrome functions normally. When I turns off iCloud private relay, the Safari's performance improves immediately. Packets captured by tcpdump at a LAN gateway (FreeBSD) shows iCloud private relay uses UDP protocol and doesn't fallback to TCP protocol. If the MTU blackhole is a problem, the connection will switch to TCP protocol, given prior tcpdump captures. I am waiting for macOS 27 Beta 5 but still no update released yet.

Environment macOS 26.5.1 (Build 25F80) Safari 26.5 Apple Pay JS API version 8 Using https://applepay.cdn-apple.com/jsapi/v1/apple-pay-sdk.js Reproduces on the staging website (Does not reproduce on the production website with non sandbox account) Signed into a Sandbox Tester Apple ID, with a test credit card registered exactly per Apple Pay Sandbox Testing — this is the only card in Wallet on the laptop Merchant validation is performed by our staging backend against our real (non-sandbox) merchant identity/certificate — i.e. a sandbox tester card being evaluated against a staging merchant session, which per the sandbox testing documentation is the expected/supported setup for testing on a live site without a separate merchant sandbox environment Summary After completeMerchantValidation() succeeds and the merchant session is accepted, the payment sheet still terminates with PKPaymentAuthorizationStateFatalError a few hundred milliseconds later, right after the native side logs a second "Evaluating merchant session using PROD trust policy." for the same session. The user sees "Payment failed" and the sheet closes. This happens on the very first attempt, with no user interaction beyond tapping the Apple Pay button — no shipping address is even selected before the failure. Since the sandbox tester card + production merchant session combination is the setup the sandbox testing guide describes, we'd expect the sheet to proceed to onpaymentauthorized (Apple's sandbox docs describe payments as being processed as $0 test transactions in this mode) rather than fail natively before that stage is ever reached. Steps to reproduce Visit an item page with an Apple Pay button. Tap the Apple Pay button to open the payment sheet. The sheet presents normally; no interaction with shipping address or payment method is required for the failure to occur. Within ~1 second, the sheet dismisses and displays a "Payment failed" error state. Minimal reproduction of the JS side const session = new ApplePaySession(8, { countryCode: 'US', currencyCode: 'USD', supportedNetworks: ['visa', 'masterCard', 'amex', 'discover'], merchantCapabilities: ['supports3DS'], total: { label: 'Merchant', amount: '10.00' }, }); session.onvalidatemerchant = async () => { const merchantSession = await validateMerchantOnServer(); // succeeds session.completeMerchantValidation(merchantSession); // accepted — see log below }; session.onpaymentmethodselected = () => { session.completePaymentMethodSelection({ newTotal: { label: 'Merchant', amount: '10.00' }, }); }; session.oncancel = event => console.log('cancelled', event); session.begin(); We reproduced this with both our full checkout implementation and this stripped-down request object (no shipping contact required, no line items) — same failure either way, which rules out anything about our order/line-item data. What we expected The sheet to proceed to the biometric authorization step and dispatch onpaymentauthorized once the user confirms. What actually happens The sheet fails immediately with a PKPaymentAuthorizationStateFatalError transition, even though every JS-side completion call (completeMerchantValidation, the payment-method selection) succeeded and returned PKPaymentAuthorizationStatusSuccess. System log (captured via log stream --info --debug --predicate 'process == "Safari" OR process == "passd" OR process == "com.apple.PassKit.PaymentAuthorizationUIExtension"') 21:50:41.544 PaymentCoordinator::beginPaymentSession() -> 1 21:50:41.570 Received prepareWithPaymentRequest: <private> 21:50:42.297 PaymentCoordinator::validateMerchant() 21:50:42.563 PaymentCoordinator::completeMerchantValidation() 21:50:42.564 Received merchant session update with status:PKPaymentAuthorizationStatusSuccess session:<private> 21:50:42.564 Evaluating merchant session using PROD trust policy. <- 1st occurrence, passes 21:50:42.572 PaymentCoordinator::didSelectPaymentMethod() 21:50:42.572 PaymentCoordinator::completePaymentMethodSelection() 21:50:42.653 Evaluating merchant session using PROD trust policy. <- 2nd occurrence 21:50:42.656 State machine change state from ClientCallback to PrepareTransactionDetails with param: <private> 21:50:43.391 Task Completed: <private> 21:50:43.393 State machine change state from PrepareTransactionDetails to PKPaymentAuthorizationStateFatalError with param: <private> 21:50:43.393 Error Payment failed with fatal error <private> 21:50:45.130 PaymentCoordinator::didCancelPaymentSession() The first "Evaluating merchant session using PROD trust policy." line passes (the flow continues to didSelectPaymentMethod). The second occurrence is immediately followed by Task Completed and then the FatalError transition, which suggests PassKit re-validates the merchant session's trust a second time right before PrepareTransactionDetails, and that second check is what's rejecting the session — even though the identical session object was accepted moments earlier at completeMerchantValidation(). What we've tried / ruled out Confirmed every JS completion method (completeMerchantValidation, completePaymentMethodSelection) is called and returns success — no 30-second timeout, no missing completion call, no thrown exception on our side. Reproduced with a minimal, hardcoded ApplePayPaymentRequest (fixed $10.00 total, no shipping fields) — rules out anything about our real order/line-item/sales-tax data. Reproduced on the main branch and independently on our staging deployment running unmodified code — rules out anything specific to our recent frontend changes. The <private> redaction in the system log prevents us from seeing what specifically fails during the second trust evaluation. Confirmed the sandbox tester card and its registration follow the sandbox testing guide exactly — it's the only card on the device, and no other Wallet cards are involved. Question What does PassKit's second "Evaluating merchant session using PROD trust policy" check (immediately before PrepareTransactionDetails) actually validate, beyond what's already checked at completeMerchantValidation() time? Is a sandbox tester card being evaluated against a production merchant session expected to pass this second check, or does sandbox testing per the linked guide require something additional on the merchant/session side (e.g. a specific field on the merchant session, or a specific environment value) that our backend isn't setting? Is there a way to get an unredacted reason for the rejection — e.g. via a private-data-enabled log profile or another diagnostic — since the redacted system log alone doesn't surface one?

Summary On iPadOS 27.0 (build 24A435), MobileSafari crashes with SIGABRT the first time the software keyboard is brought up by focusing a form field inside a web page. It happens on any website that has a text input: we reproduced it on our own web app, amazon.co.jp, Yahoo! Mail, Gmail, Rakuten, X, and two Japanese public-sector sites. No login is required to reproduce. Environment Devices: iPad mini (A17 Pro / iPad16,2) x2, plus a third iPad (reproduced on 3 devices) OS: iPadOS 27.0 build 24A435 — both the public beta and the RC build (releaseType "User"). Also reproduces after a full erase + clean install, so it is not device-state related. NOT reproducible on: iPhone (iOS 27, same build 24A435), Chrome on the same iPads, or the Xcode 27 Simulator. Steps to reproduce (no login required) Launch Safari and open any page with a login form (e.g. the amazon.co.jp sign-in page). Without logging in, kill Safari from the app switcher (or background it and go to the Home Screen). Launch Safari again; the same page is shown. Tap any text field (ID / email / password) to focus it. Safari crashes immediately. The essential condition appears to be: the FIRST keyboard activation in a freshly launched MobileSafari process is driven by focusing a form field inside WKWebView. If the keyboard has already been built once in that process (see Workaround below), the crash never happens. Crash details We collected five .ips crash reports from three devices and two unrelated websites (our web app and amazon.co.jp). lastExceptionBacktrace is identical across all five, down to the instruction offsets, so page content is not a factor. Key frames: The exception is thrown by NSISEngine (CoreAutoLayout) while -[TUIKeyplaneView prepareForSplitTransition] removes layout constraints in an inconsistent state (this split-keyplane path is iPad-only, which explains why iPhone is unaffected). The re-entrancy: Safari's AutoFill metadata round trip (WBSAutoFillJavaScriptInjectionController -> _SFFormAutoFillController beforeStartInputSession: -> TabDocument _beginAutomaticPasswordInteraction:) calls -[UIResponder reloadInputViews] from -[WKContentView _continueElementDidFocus:requiresStrongPasswordAssistance:] while -[UIKeyboard activate] is still on the stack. In all five reports, a com.apple.root.utility-qos thread is blocked in DISPATCH_WAIT_FOR_QUEUE doing dispatch_sync onto the main queue from -[UITextChecker initGlobalsWithAsynchronousLoading:] (a once-per-process initialization). Four of the five crashes occurred 1–6 seconds after process launch. After the crash, Safari itself sometimes fails to launch until you do Settings > Safari > Clear History and Website Data. Already ruled out (all verified on device) Settings > Passwords > AutoFill turned OFF: still crashes Split keyboard setting turned OFF: still crashes Full device reset + clean install of the RC build: still crashes Site-side causes: reproduces on completely unrelated sites; the crash fires before any login/auth JavaScript runs, and no page code appears in the stack Workaround (reliable, verified) Focus Safari's own address bar FIRST, so the keyboard is constructed through a native text field without the asynchronous AutoFill round trip. After that, focusing web form fields works normally for the lifetime of the process. This workaround is unavailable in SFSafariViewController / in-app browsers, where the crash also reproduces. Questions Can anyone else reproduce this on iPadOS 27.0 (24A435)? Confirmations/boosts appreciated — we want to know how widespread this is before the public rollout. Is there any site-side mitigation (markup, autocomplete attributes, JS) that prevents Safari's AutoFill round trip from re-entering keyboard construction? Standard autocomplete attributes did not help in our tests. Is this a known regression being tracked for an iPadOS 27.x update? Is there any mitigation for SFSafariViewController-based in-app browsers, where the address-bar workaround cannot be used? Filed via Feedback Assistant: FBxxxxxxxx (five .ips crash reports attached there).

Is it only on my personal M4 Pro, or can someone help confirm the error? Minimal, Reproducible Example (error appears after ~18secs): https://www.oslobalanse.com Exact Environment Details: MacBook Pro, 14", November 2024. 24GB, macOS is Tahoe 26.6.2 Expected results: A kind of film strip behaviour is expected. The images should glide or pan with constant speed across screen from right to left. Images should halt until fully overlapped on left or right screen edge depending on width of image (if larger or smaller than actual window size). The loop should be continuous. Actual results (so far only confirmed on Apple M4 Pro): The only visible error is the appearance of huge black spaces when the images disappear (see after approx 18 secs). The speed of movement is also no longer constant. This bad behaviour has so far only been confirmed on Apple M4 Pro. Console Output: There are no errors visibly shown. Troubleshooting Steps Taken: I have tried and confirmed the error both on version 26.3 and 26.6. The error has also been confirme on both Safari and in Chrome. I have disabled hardware acceleration on Chrome, but it did not help.

My domain vendezo.com is completely clean on Google Safe Browsing and VirusTotal, but Safari still shows a Deceptive Website Warning. Request through websitereview.apple.com was ignored. Please help

Device: iPhone 15, iOS 26.6, Safari. Also reproduced on Android Chrome, so this is not only WebKit, but the missing rotation flag part is. Setup: a web page asks for the front camera with getUserMedia, shows it in a video element, and records with MediaRecorder. Phone held upright. What happens: Requesting portrait dimensions (width 1080, height 1920) returns the sensor's wide preset, 1920 by 1080, unrotated. exact instead of ideal gives the same or an error. aspectRatio 9/16 gives the same. Requesting landscape numbers (width 1920, height 1080) lets Safari pick the preset and rotate the picture to match how the phone is held. Even then, the video track's getSettings() reports width 1920 and height 1080, while the frame Safari draws into the video element is portrait. The preview looks right. The track lies. MediaRecorder records the unrotated sensor buffer. On older iOS the file carried a displaymatrix rotation of minus 90 degrees and players honoured it. On 26.6 that flag is gone, so the file plays sideways. Thread 786803 has other people finding the same. Workaround that works in production: Ask for the camera in landscape numbers. Do not trust getSettings(). Draw one frame of the video element onto a 16 by 16 canvas scaled from the larger reported dimension and check which corner has paint. If the bottom left is painted and the top right is not, the picture is tall. If the drawn picture is portrait but the track says landscape, record a canvas stream of the drawn picture at its own size instead of the raw track. If they agree, record the raw track. Put the H.264 High profile first in your mime type candidates. isTypeSupported says yes to Baseline and High, and list order decides, so Baseline first gives soft video. Working code, MIT, with the dead ends left in as comments: https://github.com/lagudafuadtosin/web-teleprompter (src/lib/camera.ts) Full write-up: https://dev.to/lagudafuad/why-your-web-teleprompter-records-sideways-on-iphone-and-the-fix-549m Question for Apple: is the dropped displaymatrix on MediaRecorder output in 26.x intentional, and is there a supported way to read the capture rotation off the track?

I have found a possible performance issue with the Network Extension related to NEFilterPacketProvider. When a packet filter is disabled, my Mac gets the expected Internet upload speed. When an NEFilterPacketProvider is enabled, outbound/upload throughput drops substantially. The interesting part is that this is reproducible with a deliberately minimal test provider. The test provider only: receives packets; parses headers of several common protocols; writes diagnostic information using Unified Logging; allows all captured packets. It does not intentionally delay, modify, or drop packets, and it does not perform any other heavy processing or network activity. Reproduction Run a speed test at https://yandex.ru/internet/ with the packet filter disabled; Record the outbound/upload speed; Enable the NEFilterPacketProvider; Run the same test again; The outbound speed drops significantly; Disable the provider and repeat the test — the speed returns to the previous level; The effect is particularly noticeable on the outbound/upload direction; download performance is much less affected. For example: Configuration Download Upload Packet filter disabled ~700 Mbps ~600 Mbps Packet filter enabled ~700 Mbps ~110 Mbps I've submitted a Feedback Assistant report with a minimal reproducible sample - FB24686601. The sample is attached to the feedback. Has anyone else observed a similar outbound throughput reduction when NEFilterPacketProvider is enabled? I'm particularly interested in whether this is expected overhead of the packet-filtering architecture, a known limitation, or a possible macOS/Network Extension regression.

PDF files previewed from government websites are having passwords restrictions applied to all functions - view, print etc., this was a known error a few versions back but it seems to have been reintroduced in the iPadOS27 beta. It is reproducible and I have used a Linux machine to access the same file with no errors.