We are currently implementing the payment flow, and for handling payment details — including card entry and validation — we are utilizing a WKWebView. The webview securely loads the payment provider’s page, ensuring sensitive information such as card numbers are entered and validated directly within the web context. I’d like to clarify that this change has not yet been released to Production. As part of a feature enhancement to our existing payment flow, we are transitioning to a new payment vendor, SnapPay. While trying to load the SnapPay URL embedded within an iFrame in our iOS app, I observed the following error in the Xcode console. While this error may be generic, I wanted to highlight it: 825a18 - [pageProxyID=7, webPageID=8, PID=67346] WebPageProxy::didFailLoadForFrame: frameID=24, isMainFrame=0, domain=NSURLErrorDomain, code=-999 Upon investigating, we compared the headers from our existing payment URL and SnapPay's URL, and found that SnapPay includes the following Content-Security-Policy (CSP) header: Content-Security-Policy: frame-ancestors ... "Content-Security-Policy" value="default-src 'self'; script-src 'self' https://hcaptcha.com https://.hcaptcha.com https://code.jquery.com https://www.gstatic.com https://code.jquery.com/jquery-3.3.1.min.js https://test.lightbox.cardx.com/v1/lightbox.min.js https://www.ssa.gov/accessibility/andi/ https://c.evidon.com 'unsafe-inline' 'unsafe-eval'; style-src 'self' https://hcaptcha.com https://.hcaptcha.com https://fonts.googleapis.com/css https://stage.snappayglobal.com/Resource/ https://www.ssa.gov/accessibility/andi/andi.css 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' *.googleapis.com *.gstatic.com ; connect-src 'self' https://demo1.cditechnology.com https:; form-action https://hcaptcha.com https: 'self' *.ipg-online.com secure.bluepay.com https://test.api.lightbox.cardx.com https://3ds-acs.test.modirum.com/ https://demo1.cditechnology.com/; frame-ancestors https://snappaydirect-perf.fiserv.com 'self' file: https: http; frame-src .snappayglobal.com 'self' https://hcaptcha.com https://.hcaptcha.com https: https://www.google.com .ipg-online.com secure.bluepay.com https://.cardconnect.com https://test.api.lightbox.cardx.com/ https://test.lightbox.cardx.com https://paywithcardx.com/payment/auth.cgi securepayments.cardpointe.com *.cardpointe.com https://3ds-acs.test.modirum.com/ https://www.yokohamatire.com http://uat1-txt.ad.portal.texas.gov https://uat1-txt.ad.portal.texas.gov " After multiple working sessions with the SnapPay team, we were able to confirm that when they disable CSP or remove the frame-ancestors directive, the iFrame loads successfully within our app. However, SnapPay cannot change on their CSP. To enable the iFrame to load in the iOS app, we added the following line of code: webView.configuration.preferences.setValue(true, forKey: "allowFileAccessFromFileURLs"). This resolved the issue with loading the iFrame. Note: the file being loaded is a local .html file,. Before submitting this update to the App Store, I’d like to confirm whether this usage of allowFileAccessFromFileURLs is acceptable for App Store review. I wanted to confirm that with this change is there a security concern for WKWebview?

Hi everyone, recently I used codex and GPT-5.2 to build a simple SSL certificate monitoring website, and I'd like to share some of my development experiences. The project link is at the end, but first, let's talk about the technical implementation. The Motivation I've encountered several service outages caused by expired SSL certificates in the past. Each time, I had to react after users reported the issue, which was very passive. While there are some monitoring tools on the market, they are either too heavy or lack the necessary features, so I decided to build my own. Technology Stack Next.js 16 + shadcn/ui + TypeScript I chose Next.js because: The development experience with App Router is excellent, with a clear mapping between routes and file structure. Server Components reduce the need for client-side JavaScript. Built-in features like image optimization and font loading are ready to use out of the box. shadcn/ui is a component library based on Radix UI, and its advantages are: Components are copied directly into your project, giving you full control. It uses Tailwind CSS, making style customization easy. It has excellent accessibility features. Drizzle ORM + PostgreSQL I've used Prisma before, but I tried Drizzle this time and found it to be more lightweight: Faster type generation. More intuitive SQL operations. Better query performance. better-auth Authentication System This is a recent discovery I made, and it's more modern than NextAuth: Better TypeScript support. A cleaner API design. Supports email/password and multiple OAuth providers (GitHub, Google). Some Challenges I Faced 1. The Complexity of Certificate Chain Validation At first, I thought checking an SSL certificate was simple—just get the certificate information. I later discovered that certificate chain validation is quite complex: You need to verify the signature of each certificate in the chain. You must check the integrity of the entire certificate chain. You have to determine if the root certificate is trusted (which browsers have built-in lists for). You need to handle cases where intermediate certificates are missing. The solution was to create a complete certificate chain extraction and validation module that includes: Extracting the full certificate chain from a TLS connection. Verifying the signature and validity period of each certificate. Detecting broken or incomplete chains. Visualizing the chain structure in a tree format. 2. Designing the Security Scoring System To help users quickly understand the security status of their certificates, I created a scoring system from A+ to F. The core logic is: Weighted score across four dimensions - Certificate Validity: 30% - Chain Integrity: 25% - Cryptographic Strength: 25% - Protocol Version: 20% If there are critical issues (e.g., expired certificate), the maximum grade is C The challenges were: How to allocate weights reasonably. How to design the penalty rules. How to provide valuable improvement suggestions. Ultimately, I adopted a layered scoring approach where each dimension is calculated independently and then combined with weights. 3. Hydration Issues with Multi-language Routing When supporting 6 languages, I encountered React Hydration errors: // ❌ Incorrect approach // app/[locale]/layout.tsx contained the <html> tag // This conflicted with the root layout // ✅ Correct approach // The root layout has only one <html> tag // Use a client component to dynamically update the lang attribute 4. Graceful Degradation for Redis Caching To improve authentication performance, I added Redis caching. But I had to consider: What happens when Redis is unavailable? How do you handle cache and database data inconsistency? The solution was: Automatically fall back to the database if the Redis connection fails. Actively invalidate the cache when the database is updated. Provide cache statistics API to monitor the hit rate. 5. PageSpeed Optimization Initially, the Lighthouse score was only in the 60s. The main problems were: Large JavaScript Bundle Used Next.js's dynamic imports to load components on demand. Removed unused dependencies. Enabled Tree Shaking. Image Optimization Used the Next.js Image component for automatic optimization. Added appropriate placeholders. Enabled lazy loading for images. Font Loading Used next/font for automatic font optimization. Reduced the number of font variants. Used font-display: swap to avoid layout shifts. Critical Rendering Path Identified critical CSS and inlined it into the HTML. Deferred loading of non-critical JavaScript. Optimized the loading order of third-party scripts. Third-party Script Optimization Deferred loading for Google Analytics, Crisp Chat, etc. Used the defer/async attributes. Considered using Web Workers for time-consuming tasks. After optimization: Performance: 60 → 95 Accessibility: 85 → 98 Best Practices: 90 → 100 SEO: 100 Some Technical Highlights Certificate Chain Visualization A tree structure is used to display the certificate chain, with expand/collapse functionality and color-coding for different statuses: Green: Valid Yellow: Expiring soon Red: Expired Security Issue Detection Automatically detects insecure cryptographic algorithms: MD5, SHA-1 signature algorithms. Weak ciphers like RC4, DES. Old protocols like TLS 1.0/1.1. Multi-channel Notifications Currently supports five notification channels: Email, Slack, Discord, Telegram, and Feishu. Users can freely combine them. Project Link https://guardssl.info Features: Free SSL certificate checking. Domain monitoring and expiration reminders. Security scoring and improvement suggestions. Multi-language support (Chinese, English, Japanese, French, Spanish). Feel free to try it out and provide feedback. We can discuss any questions you might have.

Safari Extension Error: “Non-persistent background content cannot listen to webRequest events.” after macOS 15.4 / Safari 18.4 Update We’re seeing the following error in the Safari Extensions tab after updating to macOS 15.4 and Safari 18.4: “Non-persistent background content cannot listen to webRequest events.” This error did not appear prior to the update, and we haven’t found any official documentation stating that webRequest API is no longer supported in Safari. In our extension (Manifest V3), we are using the webRequest.onHeadersReceived callback to intercept response headers and read updated cookies. While the functionality itself still works as expected. we’re able to access the response headers and this error is now shown in the Extension settings page. We are not seeing this issue in other browsers (Chrome, Firefox) using the same Manifest V3 setup. Is there any plan to deprecate webRequest support in Manifest V3 for Safari? We’d appreciate any clarification or guidance on how to handle this going forward.

Issue: On Safari, two Smart App Banners appear for the same webpage when the iOS app is installed. Cause: • Banner 1: Native Apple Smart App Banner, automatically triggered by Safari via AASA / Universal Links. • Banner 2: Smart banner injected by a third-party SDK (Branch.io). • Both operate independently, resulting in duplicate banners. Finding: Safari’s native Smart App Banner behavior is system-controlled and cannot be disabled programmatically using web rules or JavaScript while Universal Links are enabled. Question: Is this behavior expected by design? Is there any Apple-supported way to suppress the native Smart App Banner when using a third-party banner, or is the recommended approach to rely on only one banner system?

iOS18的app中加载了自己开发的H5页面，H5页面有个input输入框，每次输入框聚焦的时候，都会弹出键盘滑行键入的提示：“滑动手指将字母拼成词以快速键入”，应该怎么修改，达到不每次都弹出这个提示呢

We operate a native iOS app that authenticates users via the system browser using OIDC against a 3rd party SaaS authentication broker, which then performs authentication against the individual customer IdPs using SAML within the browser session, and then completes the OIDC login between the broker and our application. Our application initiates the OIDC login using ASWebAuthenticationSession, using the broker’s library, against the broker, and at that point the authentication workflow is handled by the broker. At the beginning of the login session, the broker sets a session-identifying cookie for their domain, before redirecting the user to their company’s identity provider to authenticate, which then redirects the user back to the broker. Intermittently, Mobile Safari does not include that previously set cookie on the final communication with the broker, when being redirected from the IdP as the final step of the SAML portion of the login workflow. When the cookie is missing, the broker cannot correlate the authentication response to the original request and the login fails, even though the user successfully authenticated at their identity provider. The same user can sometimes find success after retrying on the same device minutes later, without any changes. When we first started diagnosing this issue, we were seeing about a 20% rate of these errors across all Mobile Safari logins, which we can identify fairly conclusively (from provider logs, based on their guidance) as being caused by the session cookie set in one request not being provided on the subsequent request to the same domain. Our authentication broker provider has indicated, based on their server logs, and logs from an affected device, that this behavior is caused by Mobile Safari’s Intelligent Tracking Protection (ITP) causing Mobile Safari to not send the login session cookie to the broker when handling the SAML redirect from the IdP back to them. Our authentication broker provider recommended that we switch the SAML Request binding setting from POST to Redirect in the SAML configurations against our customer IdPs, which reduced the rate of these errors to about 5% for most of our customers. However, we have at least one customer which is still seeing about a 20% rate in these errors for Mobile Safari logins after this change, and even a 5% error rate seems high. Our authentication broker has not been able to suggest any further remediation options, and has suggested we contact Apple for assistance. Our questions are: Is it reasonable to assume that ITP is causing this issue? Is there any way to confirm, conclusively, that ITP has caused a previously-set cookie to not be provided on a subsequent request to the same domain, i.e. via device logs? If so, are there any steps which can be taken to reduce or eliminate this error? Changes to how ASWebAuthenticationSession is invoked? Changes to the Authentication Broker which would reduce the chance of ITP being triggered? Changes to the Customer IdP configuration which would reduce the chance of ITP being triggered?

Hello, We are developing a Safari Web Extension that uses a cookie-based authentication mechanism. The extension makes a request to an endpoint e.g. /login, and this endpoint expects a cookie (e.g., sessionId) to be included with the request. Everything works correctly when running in the default Safari profile. However, when I install and run the same extension in a new, non-default profile, the behaviour changes: The request to /login is still made The cookie sent is not as expected As a result, the response returns null user data I confirmed that logging into the site in the new profile (in a tab) works, but the extension does not appear to share the session/cookie state with the login tab We’ve tried explicitly setting "credentials": "include" in the request but that still didn’t share the cookie in the extension context in the non-default profile. My questions: Is there away to allow cookie-based session sharing between a tab and an extension in non-default profiles in safari? Would switching to a token-based auth mechanism (e.g., Bearer tokens ) be the recommended workaround? I’d appreciate any insights or guidance from those who’ve run into similar issues. 
 Thanks in advance!

Summary: We are facing a serious issue on iPhone where multiple passkey authentication problems occur when accessing passkey-enabled login pages via shortcuts placed on the iPhone Home Screen. These issues may also occur when opening the same pages directly in a standard browser window. However, launching the login pages from a Home Screen shortcut appears to increase the likelihood of encountering these issues. Affected Services (examples, not exhaustive): Amazon GitHub Adobe Observed Issues: Issue 1: A passkey authentication dialog/popup shows two times without any user operation: What happens due to this issue: Login does not complete after the first passkey authentication. A second passkey authentication UI automatically appears. Completing or canceling the second authentication allows the login to proceed. Issue 2: Login remains stuck until the user manually invokes passkey again What happens due to this issue: The login page does not advance after the first authentication. The user must tap the ID/username field again to manually trigger the passkey UI. Completing the second authentication enables login. Issue 3: Automatic second authentication occurs, but login still fails What happens due to this issue: A second automatic authentication UI appears. Login still does not complete. Tapping the ID field no longer opens the passkey UI; instead, the password auto-fill panel appears. Passkey login becomes impossible. Observed reproduction steps (not guaranteed but most consistently observed): On iPhone, navigate to a passkey-enabled login page (e.g., Amazon, GitHub, Adobe) using a browser. Create a shortcut from the browser's share menu and place it on the Home Screen. Launch the login page from the Home Screen shortcut. Tap the ID/username field to invoke the passkey prompt. Complete passkey authentication. → One of the issues described above occurs. Environment: Device: iPhone SE OS: iOS 18.6.2

Hello, can't find a better Forum and after all this is Apple Support here? Seems starting with iOS 26.2 RC2 our Newsletter is no longer rendered 'responsive' so with unuseable small font. Anybody any suggestion? Or maybe @apple fix the bug? Where would I even start to debug this? I don't have any iphone at hand so i only got screenshots from users. Our where can i contact the actual apple support? correct: invalid:

Dear Apple Developer Support, I’m developing a Chromium-based iOS browser and want to open the Safari settings page (Settings → Apps→ Safari) like Chrome’s “Import data from Safari” feature, where clicking “Go to settings” opens the Safari settings page. To reproduce this behavior in Chrome: 1.In Chrome, search “Import password from Safari.” 2.Restart Chrome. 3.Go to Chrome → Settings → Safari import → Import to Chrome → Go to settings. 4.You will see it opens Settings → Apps → Safari. Please see the attached file for steps to trigger this feature in Chrome. My attempt with App-Prefs:root=SAFARI only opens the Settings main page ,Is there a public API to open the Safari settings page directly? Look forward to your reply,many thanks

This is a really strange issue on iOS Safari. Under certain conditions a basic input element will not be focusable or show the on screen keyboard. I can reproduce the issue with a very simple HTML file by dynamically adding an anchor element with an href during a touch event. If you add a different element or an anchor without an href, there is no issue. Similarly, if you apply the same listener to a click event there is no issue. Reproducible in iOS Simulator 17.2 and 18.1 This HTML/JS showcases the problem: <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8" /> <title>InputIssue</title> <meta name="viewport" content="width=device-width, initial-scale=1" /> </head> <body> <div id="parent"> <input type="text" name="test" /> <div id="child"></div> </div> <script> document.addEventListener("touchstart", () => { const child = document.getElementById("child"); if (!child) return; while (child.firstChild) { child.removeChild(child.firstChild); } const link = document.createElement("a"); link.href = "https://test.com"; link.textContent = "test"; child.appendChild(link); }); </script> </body> </html>

Hello from Leipzig, Germany! I noticed that when vertically scrolling in Safari 26 on my Mac, the content of the website I am currently working on is visible in the tab and URL bar with a liquid glass effect. I then looked at various other websites. Some websites have an opaque top bar. Some websites have a transparent top bar where content is visible when scrolling. On the Apple website, the top bar is opaque in light mode but transparent in dark mode. Unfortunately, I can't find a way to control this behavior. Has anyone found out more about this?

正文：大家好， 当设备连接到没有互联网的 Wi-Fi SSID（例如，硬件设备的 AP）时，我看到 NSURLSession（multipathServiceType = NSURLSessionMultipathServiceTypeInteractive）和 WKWebView 之间的行为存在令人费解的差异。我正确启用了多路径授权，在这种情况下： NSURLSession 请求会自动回退到蜂窝网络并成功（无需用户干预，快速切换）。 WKWebView 加载失败或停滞：Web 内容未出现，即使系统网络路径得到满足并确认了真正的 Internet 可访问性，Web 视图似乎也没有使用蜂窝路径。 环境： iOS 版本：（例如 iOS 18.4） 设备：（例如 iPhone 15 Pro） 多路径权利：在应用程序中启用，使用 NSURLSessionMultipathServiceTypeInteractive 连接的 SSID：硬件设备 Wi-Fi，无需外部互联网 预期回退：一旦 Wi-Fi 没有互联网，就会自动到蜂窝网络，如 NSURLSession 所观察到的那样 我做了什么/观察到什么： 使用多路径的 NSURLSession 按预期工作：NSURLSessionConfiguration *cfg = [NSURLSessionConfiguration defaultSessionConfiguration];cfg.multipathServiceType = NSURLSessionMultipathServiceTypeInteractive;NSURLSession *session = [NSURLSession sessionWithConfiguration：cfg];NSURLRequest *req = [NSURLRequest requestWithURL：[NSURL URLWithString：@“https://www.apple.com/library/test/success.html”]];NSURLSessionDataTask *task = [session dataTaskWithRequest：req completionHandler：^（NSData *data， NSURLResponse *resp， NSError *err） { NSLog（@“NSURLSession result： %@， error： %@”， resp， err）; }];[任务简历];连接到设备 Wi-Fi（无外部 Internet）时，会话会悄悄地切换到手机网络并成功完成。 相同情况下WKWebView加载失败：[self.webView loadRequest：[NSURLRequest requestWithURL：[NSURL URLWithString：@“https://www.apple.com/library/test/success.html”]]];Web 视图要么显示负载失败，要么只是挂起，即使较低级别的监视报告网络路径已满足并且真正的 Internet 连接可用。 网络路径监控逻辑： 我使用 C API nw_path_monitor来监视nw_path_status_satisfied。 一旦观察到满意，我就会使用nw_connection（例如，连接 tohttps://www.apple.com/library/test/success.html）执行真正的连接检查，以验证真实的互联网流量是否可以通过蜂窝网络流动。 该检查通过，确认回退到手机网络，但 WKWebView 仍不会加载内容。同时，相同条件下的 NSURLSession 请求会立即成功。 示例日志记录跟踪：[+] nw_path_status_satisfied=1， hasWiFi=1， hasCellular=1 [+] Internet 连接测试：准备就绪（通过 nw_connection） [-] WKWebView 加载失败/停滞 [+] NSURLSession 请求成功完成 问题： 为什么当 Wi-Fi 没有 Internet 时，具有多路径服务类型的 NSURLSession 无缝使用蜂窝网络，但 WKWebView 不表现出相同的回退行为？WKWebView 是否不以相同的方式接受系统的多路径回退？在这种情况下，它是否使用不同的网络堆栈或忽略多路径授权？ 是否有一种受支持的方法可以强制 WKWebView 像 NSURLSession 一样运行？ 例如，我是否可以通过启用多路径的 NSURLSession 桥接内容，并通过自定义方案将其注入 WKWebView？ 是否有任何 WKWebView 配置标志、首选项或策略启用相同的自动接口切换？ 与原始 NSURLSession 相比，WKWebView 处理网络接换、路径满意度或多路径的方式是否存在已知限制或记录在案的差异？ 我排除/尝试过的： 已验证多路径授权是否包含且处于活动状态。 确认的网络路径“满足”，并且在调用 [webView loadRequest：] 之前，真正的 Internet 可访问性成功。 将 WKWebView 加载延迟到连接验证之后。 观察到 NSURLSession 请求在相同的连接条件下成功。 任何对内部差异、推荐的解决方法或 Apple 推荐的模式的见解，以使 Web 内容在“没有互联网的 Wi-Fi”+ 自动回退到蜂窝场景中变得健壮，我们将不胜感激。 谢谢！

Hello Community, My application was rejected by Apple App Review, citing Guideline 4.7 and "non-embedded," which I believe is incorrect. All transactions are signed and sent directly through the app with explicit user permission. Additionally, there's an issue with min apps where users can access the functionality via a browser to interact with the service. This feature has been part of my old application and hasn't changed in the new update. It’s the same functionality as used by popular wallets like Metamask Uniswap Coinbase Which also employ web3 technology. Over the past two weeks, I've tried to communicate with Apple's support team but have been ignored or received only generic rejection emails. This has left me frustrated and concerned about the time and resources I’ve invested in developing and supporting this app. Could you please help me find a solution? Your assistance would be greatly appreciated!

Video in Landscape takes 2 taps on X to close.This issue can be replicated on iphone 14 ios 18.5.There is no issue on iPhone 15 ios 18.5.

SwiftUI List Accessibility VoiceOver

WKWebview of iOS 18 includes Safari browser. When playing videos, some videos show "NotSupportedError: The operation is not supported.", but it is normal on iOS15 devices. The video link is as follows. Even if it is downloaded and referenced locally in HTML, it cannot be played, so it is ruled out that it is a network problem. https://ydtj-adas.oss-cn-shanghai.aliyuncs.com/e6yun.com/exam/exam/a35447b496b94e5e9a6aab27d62c867e.mp4 cannot be played https://ydtj-adas.oss-cn-shanghai.aliyuncs.com/e6yun.com/exam/exam/82d970957a7d4e8d88c13cd101143005.mp4 can be played

Merhaba ben Müslüm İkuz blog sayfam için Safari tarayıcıdan siteye çok fazla istek geliyor. Sayaçlara girdiğimde uygulama safari olarak gözüküyor ve binlerce sayfa isteği gelmiş. Bu bir siber saldırı mı ? site adress https://ikuz.com.tr/

window.location.href = "tel:02-xxxx-xxxx" Can the development team modify the screen text? Or can the country code be erased? What are the reasons for continuing to be "on the phone" if the country code is automatically attached to the phone like this?

WKWebView has set the option to disable selection ("document. documentElement. style. webkitUserSelect='none ';") and long press ("document. documentElement. style. webkitTouchCallout='none';"). If there is text on one of the images in WebView, simply tap the image twice and then long press the text. The program will crash with the following error message: 0 CoreFoundation 0x185e058c8 __exceptionPreprocess + 164 1 libobjc.A.dylib 0x182d797c4 objc_exception_throw + 88 2 CoreFoundation 0x185e908d4 -[NSException initWithCoder:] + 0 3 QuartzCore 0x18678a874 CA::Layer::set_position(CA::Vec2&lt;double&gt; const&amp;, bool) + 160 4 QuartzCore 0x1869a7270 -[CALayer setPosition:] + 52 5 UIKitCore 0x18c4ac564 -[UIView _backing_setPosition:] + 176 6 UIKitCore 0x18cefdf0c -[UIView setCenter:] + 220 7 UIKitCore 0x18cd9f794 -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] + 936 8 UIKitCore 0x18cd9f3c0 __54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke + 104 9 UIKitCore 0x18ced1060 -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] + 384 10 UIKitCore 0x18cd9f2e4 -[_UIEditMenuContentPresentation _displayMenu:reason:] + 304 11 UIKitCore 0x18cd9f0d8 -[_UIEditMenuContentPresentation displayMenu:configuration:] + 64 12 UIKitCore 0x18ced0344 __58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke + 260 13 UIKitCore 0x18ced1f8c __80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke + 80 14 UIKitCore 0x18cc8403c __109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke + 180 15 UIKitCore 0x18cc84584 __107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke + 148 16 WebKit 0x1a05ae5d4 WTF::CompletionHandler&lt;void (WebKit::DocumentEditingContext&amp;&amp;)&gt;::operator()(WebKit::DocumentEditingContext&amp;&amp;) + 64 17 WebKit 0x1a05bb468 WTF::Detail::CallableWrapper&lt;WTF::CompletionHandler&lt;void (IPC::Connection*, IPC::Decoder*)&gt; IPC::Connection::makeAsyncReplyCompletionHandler&lt;Messages::WebPage::RequestDocumentEditingContext, WTF::CompletionHandler&lt;void (WebKit::DocumentEditingContext&amp;&amp;)&gt;&gt;(WTF::CompletionHandler&lt;void (WebKit::DocumentEditingContext&amp;&amp;)&gt;&amp;&amp;, WTF::ThreadLikeAssertion)::'lambda'(IPC::Connection*, IPC::Decoder*), void, IPC::Connection*, IPC::Decoder*&gt;::call(IPC::Connection*, IPC::Decoder*) + 196 18 WebKit 0x19fcf5db8 WTF::Detail::CallableWrapper&lt;WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRef&lt;IPC::Encoder&gt;&amp;&amp;, WTF::OptionSet&lt;IPC::SendOption&gt;, std::__1::optional&lt;IPC::ConnectionAsyncReplyHandler&gt;, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*&gt;::call(IPC::Connection*, IPC::Decoder*) + 64 19 WebKit 0x19fce54f0 IPC::Connection::dispatchMessage(WTF::UniqueRef&lt;IPC::Decoder&gt;) + 340 20 WebKit 0x19fcf5aa0 IPC::Connection::dispatchIncomingMessages() + 536 Will the official version have this issue?