Hi everyone, I’m encountering a critical reliability issue with message passing in my Safari Web Extension on iOS 18.4.1 and iOS 18.5. In my extension, I’m using the standard messaging API. The background script sends a message to the content script using browser.tabs.sendMessage(...), and the content script registers a listener via: browser.runtime.onMessage.addListener(handler); This setup has been working reliably in all prior versions of iOS. However, after updating to iOS 18.4.1 and 18.5, I’ve noticed the following behavior: ✅ The content script is successfully injected, and onMessage.addListener is registered (I see logging confirming this). ✅ The background script sends the message using the correct tabId (also confirmed via logs). ❌ The content script’s onMessage listener is not consistently triggered. ⚠️ This issue is intermittent, sometimes the message is received, sometimes it is silently dropped. ❌ No exceptions or errors are thrown in either script, the message appears to be sent, but not picked up from the content script message listener.

Safari 26 close and Refresh buttons not working in Compact tab layout

When I download specific files (not limited to a single website), even if I find that the downloaded file size matches the original file size and the downloaded file size no longer changes, Safari still does not stop the download thread, but continues to wait indefinitely. This results in the Safari not terminating the download thread even after the file download is completed, making it impossible to complete the download; The file has not been landed and cannot be obtained. This prevents me from downloading some files. Please fix this problem. In addition, I found that in iOS 18.2, during the process of downloading files on Safari, the synchronization and backup flags appear in the upper right corner of the notification bar. I am not sure if this is an unexpected behavior, but the flag still lingers for a long time after manually canceling the download thread. (the download thread is waiting indefinitely) Feedback Number: [FB16124044]

Background On iOS 18.4 beta, setting a content inset on a WKWebView causes touch events inside the web view to be offset by the content inset amount. In other words, if the web view has a top content inset of 75 points, I must tap 75 points above the intended element for the touch to register correctly. This makes any web content unusable when a content inset is present. A sample app demonstrating the issue is available here: GitHub - iOS18.4-Webview-Bug. The issue does not occur in iOS 18.3 or 18.2. Bug Report The bug has been reported and fixed at WebKit Bug 289715 and also filed as rdar://147075945. Question Will the fix be included in the upcoming iOS 18.4 beta release (Beta 5) or soon thereafter?

Subject: Apple Pay JS - "Payment Was Cancelled by the User" Issue (Braintree + Server-Side Validation) Issue I am implementing Apple Pay using Braintree with server-side validation. However, when initiating the payment process, I receive the following error: [Log] Payment was cancelled by the user: (apple-pay-test-ucxp.onrender.com, line 286) Additionally, the console logs an ApplePayCancelEvent with: sessionError: {code: "unknown", info: {}} Despite successfully fetching merchant session validation data from the backend and completing merchant validation, the payment process does not proceed. Setup Details Payment Processor: Braintree (Apple Pay integration) Backend API: Fetching merchant session validation via createPaymentSessionGet Payment Processing: Using Braintree nonce tokenization Client-Side Code (Key Sections) session.onvalidatemerchant = async (event) => { try { const merchantSession = await fetch( "https://api.paybito.com:9443/ApplePay/api/apple-pay/createPaymentSessionGet", { method: "GET", headers: { "Content-Type": "application/json" }, } ).then((res) => res.json()); session.completeMerchantValidation(merchantSession); } catch (err) { console.error("Merchant validation failed:", err); session.abort(); } }; session.onpaymentauthorized = async (event) => { try { const payload = await applePayInstance.tokenize({ token: event.payment.token, }); const response = await fetch( "https://api.paybito.com:9443/ApplePay/api/braintree/process-payment", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ nonce: payload.nonce }), } ).then((res) => res.json()); if (response.success) { session.completePayment(ApplePaySession.STATUS_SUCCESS); } else { session.completePayment(ApplePaySession.STATUS_FAILURE); } } catch (err) { console.error("Payment authorization failed:", err); session.completePayment(ApplePaySession.STATUS_FAILURE); } }; Observations Merchant validation completes successfully. The error occurs before onpaymentauthorized executes. Session error code is unknown, making debugging difficult. Questions Has anyone encountered this issue before? Could this be related to how the validation session is fetched from the backend? Is there a way to obtain more meaningful debug information from Apple Pay? Any insights would be greatly appreciated!

I am posting here because we have an urgent issue affecting the operation of our service and are in need of a solution after our own analysis has come up with few answers. Beginning in iOS 18.2.x, we experienced exactly the same issue as the author of this thread, as we are also operating a service that allows for device certificate login for users configured to require one: https://developer.apple.com/forums/thread/767374 The author seems to have resolved the issue but the fix mentioned in the thread did not resolve our problem for iOS devices with iOS 18.2.x installed and the contents of that private support ticket are, of course, not visible to us. Furthermore, we have a different issue that surfaced with the release of iOS 18.3.x. Namely, the issue in iOS 18.3.x is more severe than the one in iOS 18.2.x, in that instead of simply taking a long time for the certificate/identity selection dialog to appear, it simply fails immediately and is returning a “no certificate selected” response to our server. One thing to note here is that, curiously, if we wait for several seconds (about 10-15 seconds) this behavior is not replicated. So, it seems there is potentially something going in the background, and the certificate selection process will only occur successfully like before if we wait. This is a very unideal workaround. After entering user credentials, we have the user navigate to a dedicated certificate authentication page. On the BIG IP side, upon users visiting this page, we have it configured to apply an SSL profile that contains appropriate CAs for the given user, and then requests to the browser that a new connection requiring a certificate be made. We are investigating this by checking logs in in a variety of places: We can verify in BigIP logs that a response is being returned to the server without a certificate included. For the sake of our application, this is handled as a “user did not select a certificate” event, and thus the attempted login is failed. Using the MacOS “Console” application, we are able to see the following logs from the “trustd” process of the target iOS 18.3.x device: Failure case: debug 11:19:49.648581+0900 trustd XPC [com.apple.WebKit[1034]/1#25 LF=0] operation: trust_evaluate (8) debug 11:19:49.648766+0900 trustd complex trust settings anchor Successful case (after waiting 10-15 seconds after initial login page load/before moving to certificate page): debug 11:26:02.803153+0900 trustd XPC [MobileSafari[1031]/1#169 LF=0] operation: trust_evaluate (8) debug 11:26:02.804219+0900 trustd non ev score: 121 <private> There appears to be no attempt by MobileSafari to initiate the display of a certificate selection window in the failure cases. The iOS device is swift to return a response with no certificate selected to Big IP, and the result of “no certificate selected” is thus propagated through Big IP and ultimately to our web service. Does anyone have any advice or information on the following? Recommended tools to gather more data that may be pertinent. Any ideas on changes in iOS 18.2.x+ that could have resulted in the behavior changing as described above? If more information is necessary, I will do my best to supply it. Thank you in advance!

Hi all, Chrome has it already - animation-timeline aka scroll-animations. I can nowhere find any informations on what's the status in Safari/Webkit. Seems like they do not have it on the agenda at all? Does anyone know anything - I wanted to push a feature request for that - but also seem there is no feature request list anymore for webkit. See: https://www.w3.org/TR/scroll-animations/ Cheers and kind regards!

hi Testing on OS26 Public Beta 6. In Safari, if you enter x homepage and scroll, the tab bar sticks to the bottom and moves. Make the keyboard appear in the search window When scrolling down on the Safari homepage again, the issue of not being able to stick to the bottom appears. Is it because the liquid glass UI was applied this time? and safari bug? Please let me know if I'm missing anything

We’re currently working on an OTT-based application where we integrate Google Ad Manager to serve video ads. As part of the ad experience, users often see a “Learn More” CTA (Call to Action) on these ads. As per our current requirement, when a user taps “Learn More” on an ad: • The link should open in Safari (i.e., an external browser) on iOS devices • The Safari browser should ideally open in portrait orientation, as the ad content and layout are optimised for portrait mode However, based on our understanding and technical constraints on iOS, it appears that: • Orientation control is restricted to the app’s own context. • Once Safari is launched via UIApplication.shared.open, we no longer have control over how it behaves in terms of orientation. • iOS system behaviour determines Safari’s orientation based on the device’s physical orientation and Safari’s own internal configuration. Could you please confirm if there’s any supported way (via SDK, deep link config, or otherwise) to enforce portrait orientation in Safari when opening such external URLs from within an iOS app? If this is not technically feasible, we would appreciate any best practices or alternatives you can suggest for ensuring a consistent user experience.

Device: iPhone 15pro, ios26.0 (23A 341) IOS version: 26.0 (23A 341) When using position: sticky; bottom: 0, the div is expected to stick to the bottom of the viewport when the browser toolbar hides while scrolling. However, it stops at the height where the toolbar was, instead of moving down with the disappearing toolbar. In the image below, the red-bordered navigation shows the situation where it does not stick to the bottom. i

We are using WebKit in our app and recently started noticing a crash occurring on iOS 17 and earlier versions. The crash log shows the following error: Thread 0 Crashed: 0 WebKit 0x00000001a38593cc WebKit::WebPageProxy::updateActivityState(WTF::OptionSet<WebCore::ActivityState>) + 220 (WebPageProxy.cpp:2544) 1 WebKit 0x00000001a39cb1e0 WebKit::WebPageProxy::dispatchActivityStateChange() + 132 (WebPageProxy.cpp:2653) 2 WebKit 0x00000001a3f541f8 WTF::Detail::CallableWrapper<WebKit::WebPageProxy::scheduleActivityStateUpdate()::$_5::operator()() const::'lambda'(), void>::call() + 52 (Function.h:53) 3 JavaScriptCore 0x00000001a48317ec void WTF::dispatchWorkItem<WTF::(anonymous namespace)::DispatchWorkItem>(void*) + 60 (WorkQueueCocoa.cpp:48) 4 libdispatch.dylib 0x00000001964f5dd4 _dispatch_client_callout + 20 (object.m:576) 5 libdispatch.dylib 0x00000001965045a4 _dispatch_main_queue_drain + 988 (queue.c:7898) 6 libdispatch.dylib 0x00000001965041b8 _dispatch_main_queue_callback_4CF + 44 (queue.c:8058) 7 CoreFoundation 0x000000018e623710 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 (CFRunLoop.c:1780) 8 CoreFoundation 0x000000018e620914 __CFRunLoopRun + 1996 (CFRunLoop.c:3149) 9 CoreFoundation 0x000000018e61fcd8 CFRunLoopRunSpecific + 608 (CFRunLoop.c:3420) 10 GraphicsServices 0x00000001d34d01a8 GSEventRunModal + 164 (GSEvent.c:2196) 11 UIKitCore 0x0000000190c5890c -[UIApplication _run] + 888 (UIApplication.m:3713) 12 UIKitCore 0x0000000190d0c9d0 UIApplicationMain + 340 (UIApplication.m:5303) After investigating, we found that this crash was addressed in this https://github.com/WebKit/WebKit/pull/24778 WebKit PR. However, our app is still crashing for users on older iOS versions where this fix is not available. Is there a known workaround to prevent this crash on affected iOS versions? Any guidance would be greatly appreciated.

Our app encountered a new crash since beta5(23A5308g) released last week,and it seems the crash is not solved yet in beta6(23A5318c).The crash stack below `-[UIView _backing_setPosition:] -[UIView setCenter:] -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] ___54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] -[_UIEditMenuContentPresentation _displayMenu:reason:] -[_UIEditMenuContentPresentation displayMenu:configuration:] ___58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke ___80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke ___109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke ___107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>::operator()(WebKit::DocumentEditingContext&&) WTF::Detail::CallableWrapper<IPC::Connection::makeAsyncReplyCompletionHandler<Messages::WebPage::RequestDocumentEditingContext, WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)> >(WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>&&, WTF::ThreadLikeAssertion)::{lambda(IPC::Connection*, IPC::Decoder*)#1}, void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) WTF::Detail::CallableWrapper<WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRefIPC::Encoder&&, WTF::OptionSetIPC::SendOption, std::__1::optionalIPC::ConnectionAsyncReplyHandler, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) IPC::Connection::dispatchMessage(WTF::UniqueRefIPC::Decoder) IPC::Connection::dispatchIncomingMessages() WTF::RunLoop::performWork() WTF::RunLoop::performWork(void*) _CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION ___CFRunLoopDoSource0 ___CFRunLoopDoSources0 ___CFRunLoopRun __CFRunLoopRunSpecificWithOptions _GSEventRunModal -[UIApplication _run] _UIApplicationMain main main.m start

I'm developing a web extension for Safari on iOS using MV3. The extension is working fine in Chrome, but in Safari I experience some seemingly random issues. I would like to debug it, but here is my problem. I have my iPhone connected via cable to Mac, and it works fine with XCode, so I assume this part is OK. I open Safari or Safari Tech Preview (doesn't matter) on my Mac, developers options are enabled, and in the Develop menu, under my iPhone section, there are things I can debug. There is an entry "[Ext name] - Extension Service Worker" but when I click it, it's empty. Web inspector pops up, but there are no network requests, no logs, nothing. I know the extension is working, because I can stream log to my HTTP server, but I don't see them here at all. I can use console to trigger commands like chrome.storage.local.get(null, console.log) and it shows my local store, so why I don't see any logs? Also, the background script is not visible in the Sources tab, just one weird request: navigator.serviceWorker.register('safari-web-extension://E3449EA7-EC25-4696-8E6C-[ID HERE]/background.js'); </script> Any ideas what went wrong? The entire team of 4 people has the same issue and we can't move forward because of that. Also, the Develop => Service workers or any other menu section doesn't show my service worker. Logs for websites running on my phone are visible and in general web inspector for them works fine.

Hi, I'm encountering an issue with the Clipboard API's writeText() method in Safari. It throws a NotAllowedError even when triggered by a user action (selecting an option from a <select> element). Is this expected? This issue seems specific to Safari, as the same code works perfectly in Firefox and Chrome. Perhaps I should send feedback to Apple, but I'd like to post it here first in case I misunderstand something. Problem In Safari, when I try to copy text to the clipboard using navigator.clipboard.writeText() within an input event listener attached to a <select> element, it fails with the following error: NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. Environment Safari 18.2 (20620.1.16.11.8) Technology Preview 210 macOS Sequoia 15.2 (24C101) Example I've created a minimal reproducible example on CodePen: https://codepen.io/mshibanami/pen/LEPdxXZ Here's the relevant JavaScript code from the example: selectElement.addEventListener('input', async (event) => { const selectedText = event.target.options[event.target.selectedIndex].text; try { await navigator.clipboard.writeText(selectedText); alert(`Text copied to clipboard: ${selectedText}`); } catch (err) { alert('Failed to copy text to clipboard: ' + err); } }); Firefox and Chrome handle this code without any issues, successfully copying the text to the clipboard, but not Safari. Possible Cause I suspect this issue might be related to WebKit's User Activation API. It seems like Safari is not correctly recognizing the input or change event on a <select> element as a valid user activation for the Clipboard API, even though it is initiated by a user gesture. Questions Is this behavior unexpected? Should Safari allow the Clipboard API to work in this context? (Technically, this might be expected as of now, as such events are not explicitly described in https://webkit.org/blog/13862/the-user-activation-api/.) Any insights or suggestions would be greatly appreciated. Thanks!

When CHIPS was introduced in 18.4 it worked well, however on 18.5 it does not appear to work. There do not appear to be release notes about this in 18.5, so can someone provide definitive if this is a defect that will be fixed, or have they already been deprecated?

After upgrading to Safari version 18, we encountered an issue with my extension’s background script not being able to access cookies. Previously, in Safari versions 17 and below, the extension worked as expected. Now, when the extension tries to retrieve cookies using browser.cookies.getAll(), it returns an empty list. However, if we open the extension’s developer tools, the cookies are visible and accessible. It seems that Safari only provides cookie data after the developer tools have been opened. However, after relaunching Safari and launching the extension without opening the developer tools, browser.cookies.getAll() still returns an empty list. Has anyone else experienced this? STEPS TO REPRODUCE Download this minimal app : https://www.icloud.com/iclouddrive/0bajlhnuQaG6T5NsFKXEB0U9Q#test%5Fcookies Compile test_mv2 extension (in test_cookies.getAll.zip). Launch test_mv2.app and activate extension. Click on the extension's button (browserAction). Open the developer tools. Observe an empty list of cookies. Click on the extension's button (browserAction). Cookies are retrieved as expected.

Hello Apple Developer Community, I'm experiencing an issue with PDF link interaction in WKWebView that appears to be specific to iOS 26. Problem Description: I'm loading a PDF in WKWebView.The links may vary widely and are not necessarily DPF, so I need to load them using WKWebView. On iOS versions prior to 26, links within the PDF are clickable and work correctly. On iOS 26, the same links are not clickable (no response when tapped). Expected Behavior: PDF links should remain clickable and functional across all iOS versions. What I've Tried: Tested opening the PDF directly in Safari on iOS 26 - links still not clickable This suggests the issue might be related to changes in the system's PDF rendering engine Reproduction Steps: Load the PDF URL in WKWebView Navigate to page 12 Attempt to tap the link Environment: Test Devices: iPhone 15(26.0 ) / iPhone 16 Pro Max(18.0.1 ) Xcode: 16.2 Questions: Is this an intentional change in iOS 26's PDF handling or WKWebView? If so, is there a new API or configuration to restore link interactivity? Any guidance or suggestions would be greatly appreciated!

This is my first time to post on this forum. If there are something we didn't notice, please tell me. Thanks. Background We're using canvas to provide a web component to marketing. https://demo.mescius.jp/spreadjs/BenchmarkSample/ Problem Recently we have met an issue from customer. He is using iPad 10th to access the web component but when he tries to scroll it and it's very slow on iPad 10th. His iPad OS version is 17.7 and this issue also can be reproduced on our iPad 10th with iPad OS 18.0.1. But if we use iPad 9th with iPad OS 17.7 and 18.0.1, things are fine and there isn't any performance issue. We developer took some time investigating and found it's because of iPad 10th's safari takes longer time to paint each frame. On iPad 9th, it needs nearly 10ms to paint each frame. But on iPad 10, it needs nearly 70ms to paint each frame. Also we can provide simple code for you to check the different. We tried to simulate the repaint when user is scrolling. You can see on iPad 9th, it will be 2~3ms but on iPad 10th, it will be more than 10ms for each frame. test-ipad10.html It has been happening on iPad 10th only with iPad OS 17.6/17.7/18.0. This will be a big problem for us because it means on the iPad 10th (the latest iPad, non Pro or Air), it can't be used. Question Is there anyone knowing similar issue with this one? And do you know how to solve it on iPad 10?

Hi all, With version 18.4 beta, I have a problem with the display of webviews in the app. In particular, the app of my bank has webviews inside it, and as they are not loading, I am unable to access it. Can you help me? Thank you.

Title: Content Overlapping Address Bar After Clicking Links in Safari, tested on iPhone 11 (iOS 18.1.1) Description: When browsing in Safari on iPhone (iOS 18.1.1), the one-tab bar (address bar) collapses as expected when scrolling down a page. However, after clicking on a link and loading the next page, the content appears to overlap the collapsed address bar. This results in parts of the content being hidden or obscured by the address bar, which affects the user experience, especially on mobile devices with limited screen space. This issue is reproducible on Next.js applications and can be observed on websites such as rotterdam.nl and halderberge.nl. Steps to Reproduce: Enable the One-Tab Bar: Go to Settings > Safari and enable the one-tab bar feature. Open the website rotterdam.nl or halderberge.nl in Safari on an iPhone 11 (iOS 18.1.1). Scroll down the page so that the top address bar collapses. Click on any link on the page to load a new one. Once the new page loads, observe that the content appears on top of the collapsed address bar, causing parts of the content to be hidden or obscured. Expected Result: The content should not overlap or be hidden behind the collapsed address bar after the page reloads. The layout should adjust properly without interference from the address bar, providing a smooth user experience. Actual Result: When the new page loads, the content overlaps or appears on top of the collapsed address bar, causing parts of the content to be hidden or obscured. Device(s) Affected: iPhone 11 running iOS 18.1.1. OS Version: iOS 18.1.1 Technical Notes: To address this issue, the following solutions have been attempted with no success: Viewport Meta Tag: <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" /> This was added to help ensure proper layout on mobile devices, but did not resolve the issue. CSS Safe Area Insets: body { padding-top: env(safe-area-inset-top); } This CSS rule was applied to account for the safe area and prevent content from being hidden under the address bar, but it did not solve the overlapping issue. Scroll Position Adjustment (for scroll-to-top button): Adjusting the scroll behavior by changing the scroll position to {top: 1} instead of {top: 0} was a successful workaround to keep the address bar collapsed when clicking the "scroll to top" button. However, this did not resolve the issue when navigating between pages or changing routes, where the content still overlaps the collapsed address bar.