We are trying to retrieve merchant tokens from ApplePay. We used the javascript codes from Apple Pay demo site to request for a recurring payment from the frontend. "recurringPaymentRequest": { "paymentDescription": "A description of the recurring payment to display to the user in the payment sheet.", "regularBilling": { "label": "Recurring", "amount": "4.99", "paymentTiming": "recurring", "recurringPaymentStartDate": "2023-08-11T11:20:32.369Z" }, "trialBilling": { "label": "7 Day Trial", "amount": "0.00", "paymentTiming": "recurring", "recurringPaymentEndDate": "2023-08-11T11:20:32.369Z" }, "billingAgreement": "A localized billing agreement displayed to the user in the payment sheet prior to the payment authorization.", "managementURL": "https://applepaydemo.apple.com", "tokenNotificationURL": "https://applepaydemo.apple.com" } Payment was successful, but merchantTokenIdentifier is not shown in the in decrypted ApplePay token, regardless of test card used. We tried Visa and MasterCard.

Currently, after installing our Safari Extension, users must manually enable it within Safari Preferences under Extensions settings. This involves: Navigating to Safari Preferences. Selecting Extensions. Checking the checkbox to enable the Extension. Clicking on “Always Allow on Every Website” to grant necessary permissions. We are seeking guidance or the possibility of introducing an automation feature that would streamline these steps. The goal is to reduce manual user interaction. Are there existing APIs or methods within Safari's framework that we could utilize to automate these setup steps? What are the best practices for ensuring a smooth setup process? Thanks.

以下是包含完整日誌的回報範本： Title: WKWebView File Upload Causes App Crash When Selecting Camera or Recording Options Body: Hello, I am experiencing a critical issue with WKWebView in our iOS app when handling file uploads. We are using the following HTML element to allow users to capture images or videos, select from their photo library, or choose a file from the file system: <input type="file" accept="image/*;capture=camera" id="cameraInput"> Issue Description: When a user selects the camera or recording option, the app immediately crashes and returns to the WKWebView screen. This issue does not occur when selecting a file from the photo library or file system. Logs: Below are the relevant logs captured when the issue occurs: Presenting view controller <_UIContextMenuActionsOnlyViewController: 0x1034349e0> from detached view controller <MailVwCtl: 0x103838800> is not supported, and may result in incorrect safe area insets and a corrupt root presentation. Make sure <MailVwCtl: 0x103838800> is in the view controller hierarchy before presenting from it. Will become a hard exception in a future release. RotateN2:<MailVwCtl: 0x103838800> RotateN2:<MailVwCtl: 0x103838800> RotateN1:<Mail2000ViewController: 0x10350b780> RotateN2:<Mail2000ViewController: 0x10350b780> RotateN2:<MailVwCtl: 0x103838800> RotateN2:<MailVwCtl: 0x103838800> RotateN2:<Mail2000ViewController: 0x10350b780> RotateN1:<Mail2000ViewController: 0x10350b780> RotateN2:<Mail2000ViewController: 0x10350b780> RotateN2:<Mail2000ViewController: 0x10350b780> RotateN2:<Mail2000ViewController: 0x10350b780> RotateN2:<Mail2000ViewController: 0x10350b780> Unknown chipRevisionID (0xffffffff) Attempted to change to mode Portrait with an unsupported device (BackWideDual). Auto device for both positions unsupported, returning Auto device for same position anyway (BackAuto). Attempted to change to mode Portrait with an unsupported device (BackWideDual). Auto device for both positions unsupported, returning Auto device for same position anyway (BackAuto). Attempted to change to mode Portrait with an unsupported device (BackAuto). Auto device for both positions unsupported, returning Auto device for same position anyway (BackAuto). Attempted to change to mode Portrait with an unsupported device (BackWideDual). Auto device for both positions unsupported, returning Auto device for same position anyway (BackAuto). RotateN2:<Mail2000ViewController: 0x10350b780> RotateN2:<Mail2000ViewController: 0x10350b780> RotateN2:<Mail2000ViewController: 0x10350b780> WillDsAr:<MailVwCtl: 0x103838800> RotateN1:<Mail2000ViewController: 0x10350b780> RotateN2:<Mail2000ViewController: 0x10350b780> DidDsAr:<MailVwCtl: 0x103838800> <Mail2000ViewController: 0x10350b780>:VwWillAppear:1:x0 willAr:1,Fm:0,20,375,792-<MailVwCtl: 0x103838800> willAr:1,Bd:0,0,375,792-<MailVwCtl: 0x103838800> <MailVwCtl: 0x103838800>:VwDidAP: VwDidAP:Bd:0,0,375,792-<MailVwCtl: 0x103838800> VwDidAP:Fm:0,20,375,792-<MailVwCtl: 0x103838800> VwDiDAP:SetFm:0,20,375,792-<MailVwCtl: 0x103838800> ToolVwSetVwSize0:main,0,24,w=375,h=668,stepInd=0 ToolVwSetVwSize0:toobar_self,0,692,w=375,h=66 ToolVwSetVwSize:w=375,h=792 ToolVwSetVwSize1:main,0,0,w=375,h=727 ToolVwSetVwSize1:ToolBar,0,727,w=375,h=792 RotateN2:<Mail2000ViewController: 0x10350b780> RotateN2:<Mail2000ViewController: 0x10350b780> <Mail2000ViewController: 0x10350b780>:VwDidAppear:1:x0 M2KVC_DidAp0:0.000000 0.000000 375.000000 812.000000 Additional Context: This issue is critical as it affects the user experience severely. Notably, we have a similar issue in our Android app using WebView. In that case, the file upload options for camera, recording, and file selection do not appear at all, restricting users to only upload files from the phone's storage. We would like to inquire whether there have been recent changes to the APIs related to WKWebView and WebView or any known issues that could be causing this behavior. We are also concerned this might be a side effect of recent bug fixes or updates to WKWebView. Additional Context: This issue appears to be specific to iOS 17. We have tested the same functionality on devices running iOS versions below 17, and the camera and recording options work as expected without any crashes. This suggests that the issue may be introduced in iOS 17. You can view a video demonstrating the issue at this link: https://share.icloud.com/photos/001voevXriVXsEUmhzGsFBtSA Environment: iOS version: 17.6.1&17.5.1 Device: iPhone 15 Pro Max& iPhone 12 WKWebView version: [Your WKWebView version, if known] App platform: iOS Xcode version: 15.1 We appreciate any insights or guidance you can provide on this matter. Thank you.

When using wkwebview to load a web page for audio and video calls in iPhone and Mac apps, the permission box will pop up every time after reconstruction of wkwebview, affecting the user's use, is there any way to make the permission pop-up box only pop up for the first time, like app permision pop-up window,instead of popping up every time. If you have previously authorized the permission, even after the app is restarted, do not pop up the permission prompt box in the webview.

Hello everyone, I am currently developing several Progressive Web Apps (PWAs) and I am wondering if it’s possible to programmatically open an installed PWA on iOS/iPadOS from another app or a link. My goal is to be able to launch an installed PWA directly from an action in another PWA, a web app, or a native app on iOS. For example, I’d like to know if this can be achieved via a deep link, a custom protocol (web+), or any other mechanism available on these platforms. Has anyone successfully implemented this feature or found a workaround to programmatically open an installed PWA on iOS/iPadOS? Thank you very much for your feedback and suggestions!

Hi, I need to automate for testing/verification the cookies that were saved in my WKWebView application. I have used Activity Monitor to try and find the cookies file path but do not see it. I can see my local storage files saved to /Users/test/Library/WebKit/com.foo.ui/WebsiteData/Default/random_uuid/LocalStorage/localstorage.sqlite3 so I looked for a cookies file around there and found nothing. Where are cookies saved to on disk?

Hello, dear Apple community I have WordPress website: https://fritzboxwelt.de/ I was using Google Chrome to access the website dashboard. For some reason, I shifted from Chrome to Safari, but now I am facing errors when logging in. What should I do now? Is it a website issue or my browser settings are not okay? It will be great to hear from you.

When we activate the developer options and right-click to select "Inspect," then navigate to the Network tab, we can view the request entries. However, upon clicking on an entry, I can see the headers, cookies, and other details, but one crucial aspect is absent: the request and response data. This seems like a fundamental feature—why is it missing? 🤔

Hi :) I am building browser extension that is integral part of our bigger web service. Since it needs to authenticate with our web application to use its api. Extension was originally developed for the Chrome and there everything works perfectly fine without any additional work. When I am authenticated on the platform I am able to use extension on any website and while making api calls from extensions background script to the platform backend the cookie is automatically attached to it. I just do fetch without any headers etc everything works out of the box. Then I used the xcrun safari-web-extension-converter and converted the chrome extension to safari. I tested local build as well as build submitted to test flight and none of these seems to work the same way as on chrome. Meaning I am not able to make this safari extension pick up the cookie from my web application. I found that if I disable: prevent cross-site tracking in Safari Settings it works. But obviously its not a solution for the normal users. Can anyone help me to make it work? I am not very familiar with apple dev environment.

<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Document</title> <style> .header { background-color: #fff; padding: .1rem .1rem; position: relative; width: 100%; } li { position: relative; line-height: .46rem; } .options { background-color: red; height: 4.8rem; height: 70vh; margin-top: -.01rem; max-height: 200px; overflow-x: hidden; overflow-y: auto; padding-bottom: .2rem; width: 100%; } .aaaa { max-width: 300px; max-height: 200px; } </style> </head> <body> <button id="aa_click">click</button> <div class="bbbbb"> <div class="aaaa"> <div class="header"> <h3>reason</h3><span class="close-pop"><i></i></span> </div> <div class="options"> <ul> <li class=""> <p class="optionItem">aa</p><i></i> </li> <li class=""> <p class="optionItem">bb</p><i></i> </li> <li class=""> <p class="optionItem">cc</p><i></i> </li> <li class=""> <p class="optionItem">dd</p><i></i> </li> <li class="selected"> <p class="optionItem">ee</p><i></i> </li> <li class=""> <p class="optionItem">ff</p><i></i> </li> <li class=""> <p class="optionItem">gg</p><i></i> </li> <li class=""> <p class="optionItem">sdf</p><i></i> </li> <li class=""> <p class="optionItem">aaa</p><i></i> </li> <li class=""> <p class="optionItem">aaa</p><i></i> </li> <li class=""> <p class="optionItem">aaa</p><i></i> </li> <li class=""> <p class="optionItem">aaa</p><i></i> </li> <li class=""> <p class="optionItem">aaa</p><i></i> </li> <li class=""> <p class="optionItem">aaa</p><i></i> </li> <li class=""> <p class="optionItem">aaa</p><i></i> </li> </ul> </div> </div> </div> <script> document.getElementById("aa_click").onclick = function () { let a = document.getElementsByClassName("bbbbb")[0]; let b = a.style.visibility if (b == 'hidden') { a.style.visibility = "visible"; } else { a.style.visibility = "hidden"; } }; </script> </body> </html> In iOS18 beta5, open this HTML with wkwebview, click the button to hide the list, and the webview will be terminated.If one of the following three conditions is triggered, the webview will not be terminated: Remove the elements in ul until the list is no longer slidable Remove the position:relative of the header element Remove the position:relative of the li element wkwebview error:

My Safari extension (based off a Chrome one) is working fine in a Mac OS Safari version but when I try to run it on the phone I'm experiencing some bugs in communication with the backend, which I cannot troubleshoot because when I click on Develop > my_phone > Safari Extension Background Content I don't see any logs in there. Where the background logs are supposed to appear? How can I find them? I don't see them in Xcode either.

Hi, I'm experiencing an issue with my Safari extension on iOS 18. When trying to access images using browser.runtime.getURL(), it doesn't work as expected. The same code works on iOS 17 and earlier versions. Here's my manifest file and code snippet. "web_accessible_resources": [ { "resources": [ "html/*.html", "images/*.png", "images/*.gif", "images/*.svg", "json/*.json", "fonts/*.ttf", "css/*.css" ], "matches": [ "<all_urls>" ] }, "images/fs_loading.svg", "images/status_protected.svg", "images/safe_check_icon.svg" ] `var status_ok_svg = browser.runtime.getURL("images/status_protected.svg");` Note: Image all are added in Images folder only

If a sufficiently long text in an HTML tag leads to a text wrap, the calculated values (y and width) of getBoundingClientRect for characters or words directly after the wrap are not correct, if the element or one of a parent is contenteditable="true" the y value has the value as if it were still before the break the width value spans the entire width, Here a code that reproduces this failure: https://stackblitz.com/edit/vitejs-vite-jwghts?file=src%2Fmain.ts,src%2FcalcLetterRects.ts,src%2Fstyle.css

On iOS18 Beta 3 Version, Unable to load a javascript file from Salesforce in the WebView. When trying to load a javascript file (static resource) from Salesforce in WebView. It's throwing below mentioned error. Error: Refused to execute https://*.my.salesforce.com/resource/1722959303321/T1C_Base__DealsLib/src/ace-lib.js as script because "X-Content-Type-Options: nosniff" was given and its Content-Type is not a script MIME type. The error is only happening after upgrading to iOS18 Beta. It was working fine before. Expected Behaviour: File should be loaded successfully Actual Behaviour: File is not loading Xcode Version: 15.3

I'm experiencing a Safari Web Extension issue where the non-persistant background script seems to crash after 30 seconds even when the content script is messaging it. Here is a minimal-reproducible example. When running in an emulator, the background script will stay responsive forever. However, when running on a physical device, the background script becomes non-responsive after 30 seconds of activity. It never becomes responsive again until I toggle the extensions enable/disable toggle, after which it stays active for 30 seconds and then crashes again.

We had developed an iOS Safari web extension (which uses non-persistent background scripts) that functioned properly until iOS 17.3. However, I've encountered inconsistent behavior on iOS 17.4.1, 17.5, and 17.5.1. Upon further debugging, I noticed that the background scripts often become idle and are unloaded frequently. They are not loaded again even for the registered webNavigation events and only trigger when interacting with the extension popup menu. This is also mentioned here. I had tried this in both manifest versions 2 & 3. I had tried using service_worker for background scripts. But, none of it seems to resolve this issue. Could you please clarify if this is a bug or an intended behavior? Our extension relies on webNavigation events without users having to interact with the popup menu often.

Hello there! At our company we have started to deal with an issue in the latest iOS (17.5) version. It looks like the background script of the extension becomes unresponsive after a short amount of time (around 30 seconds) after performing more than one request to it within a range of 1 - 4 seconds. How it can be tested? Pretty simple example: // content.js const t = 4000 // Using less than 4000ms makes background script unresponsive async function requestNext() { return browser.runtime.sendMessage({ greeting: "getNext" }) } setInterval(async () => { const n = await requestNext() console.log("current is: " + n) }, 4000) // background.js let counter = 0 browser.runtime.onMessage.addListener((request, sender, sendResponse) => { console.log("Received request: ", request); if (request.greeting === "getNext") { counter++ sendResponse(counter); return true } }); Whenever the browser.runtime.sendMessage is executed too fast the background script will stop working. As far as we have been able to check this only can be reproduced after 17.4.1

Running extension either on physical device or simulator. When trying to get the console log in Safari > Develop > Device > The main page shows but when launching the popup.js extension it doesn't show in order to see console. Works fine iOS 17* Not available iOS 18 FB14109978

Since probably the late iOS 17.4.x, 17.5.1 and still now in 17.6 beta our extension has been experiencing issues with the accompanying background script or service worker being permanently killed with no warning after about 30-45 seconds after initial installation (installation, not page load!). In all other browsers (including Safari on MacOS) unloading the service worker is part of the normal lifecycle to save memory and CPU if it is idle. In our extension the service worker is used only during the first 5-10 seconds of every page visit, so we are used to seeing it unload after that and consider this a good thing. However, normally, the service worker is able to wake back up when needed - which is no longer the case in iOS. Once dead, nothing a normal user would do can wake the service worker back up: No events like webNavigation or similar will trigger anymore Any attempt to call sendMessage to it from a content-script also does not wake up the service worker and instead returns undefined to the content script immediately Closing and opening Safari does not start it again The only two things that will give the service worker another 30-40 seconds of life is a reboot of the device or disabling and then re-enabling the extension. During those few second the extension is working perfectly. There are no errors or indications in the logs of what is going on and the extension works just fine in Chrome, Firefox, Edge as well as Safari on MacOS and Safari in the Mobile simulator. Only actual iOS devices fail. It seems like a temporary workaround is to change the manifest to not load the service worker as a service worker by changing "background": { "service_worker": "service.js" } to "background": { "scripts": ["service.js"], "persistent": false } With this change (courtesy of https://forums.developer.apple.com/forums/thread/721222) the service worker is still unloaded but correctly starts up again when needed. Having to make this change does not seem to be consistent with manifest v3 specs though (see this part in Chrome’s migration guide as an example: https://developer.chrome.com/docs/extensions/develop/migrate/to-service-workers#update-bg-field). According to the release notes of 17.6 beta this bug was supposedly fixed: “Fixed an issue where Safari Web Extension background pages would stop responding after about 30 seconds. (127681420)” However, this bug is not fixed - or at least not entirely fixed. It seems to work better for super simple tests doing nothing but pinging the service worker from the content script, but for the full blown extension there is no difference at all between 17.5.1 and 17.6. Has there been a change in policy about service workers and background scripts for Safari in iOS? Are anyone else seeing this issue? Also seemingly related: https://forums.developer.apple.com/forums/thread/756309 https://forums.developer.apple.com/forums/thread/750330 https://developer.apple.com/forums/thread/757926 https://forums.developer.apple.com/forums/thread/735307

I was able to obtain the URL in iOS 17+ and lower versions by using the browser.tabs.getSelected method in background.js, and it was successful. I upgraded to iOS 18 and now this function is returning 'Undefined'. As a result, the Safari Extension feature is broken. Is this browser.tabs.getSelected no longer available or deprecated as of iOS 18? As an alternative, browser.tabs.query functions. is a useful substitute for that.