Post not yet marked as solved
- (void)viewDidLoad { [super viewDidLoad]; UIBarButtonItem *rightButton = [[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemAdd target:self action:@selector(rightButtonTapped:)]; self.navigationItem.rightBarButtonItem = rightButton; WKWebViewConfiguration *configuration = [[WKWebViewConfiguration alloc] init]; _webView = [[WKWebView alloc] initWithFrame:self.view.bounds configuration:configuration]; _webView.navigationDelegate = self; [self.view addSubview:_webView]; NSURL *url = [NSURL URLWithString:@https://www.apple.com]; NSURLRequest *request = [NSURLRequest requestWithURL:url]; [_webView loadRequest:request]; } - (void)rightButtonTapped:(UIBarButtonItem *)sender { NSLog(@self.webView.scrollView.contentSize.height:%f, self.webView.scrollView.contentSize.height); WKSnapshotConfiguration* configuration = [WKSnapshotConfiguration new]; configuration.rect = CGRectMake(0, 0, self.webView.scrollView.contentSize.width, self.webView.scrollView.contentSize.height); // configuration.afterScr
Post not yet marked as solved
Our app collected some JavaScriptCore crash information on iOS17 and above systems, but the cause of the error cannot be located. The crash stack is as follows: #27 Heap Helper Thread SIGSEGV 0 JavaScriptCore JSC::MarkedBlock::aboutToMarkSlow(unsigned int) 1 JavaScriptCore JSC::JSFinalObject::visitChildren(JSC::JSCell*, JSC::SlotVisitor&) 2 JavaScriptCore JSC::JSFinalObject::visitChildren(JSC::JSCell*, JSC::SlotVisitor&) 3 JavaScriptCore JSC::SlotVisitor::drain(***::MonotonicTime) 4 JavaScriptCore JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, ***::MonotonicTime) 5 JavaScriptCore ***::SharedTaskFunctor<void (), JSC::Heap::runBeginPhase(JSC::GCConductor)::$_15>::run() 6 JavaScriptCore ***::ParallelHelperClient::runTask(***::RefPtr<***::SharedTask<void ()>, ***::RawPtrTraits<***::SharedTask<void ()> >, ***::DefaultRefDerefTraits<***::SharedTask <void ()> > > const&) 7 J
Post not yet marked as solved
[WKWebView dealloc] WebKit::WebURLSchemeTask::stop() - crash
Post not yet marked as solved
while the async one seems to be called from arbitrary threads (and thus crashing). Hmmmm, I’m not sure what to make of that. If I had more time I’d dig into it to confirm my understanding, but the months leading up to WWDC are kinda busy O-: I submitted feedback FB13774556. Thanks. Regardless of your workaround, getting this annotated correctly in the headers is the best long-term solution. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Post not yet marked as solved
I don’t have any answers to your direct question, but I have some recommendations for how to avoid problems like this: Rather than working directly with a self-signed certificate, instead create a CA and have it issue certificates. You can then install the CA’s root certificate, and trust evaluation follows a well-trodden path. Rather than issuing certificates for localhost, issue them for your Mac’s local DNS name. For example, if your Mac is called Guy Smiley it’s local DNS name will be guy-smiley.local. Again, that keeps you on a well-trodden path. I discuss the specific steps involved in: Technote 2326 Creating Certificates for TLS Testing QA1948 HTTPS and Test Servers Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Post not yet marked as solved
I created a PWA that requires access to users' geolocation to perform a certain action in the system. The correct operation would be the user opens the application, and then the operating system prompts them to allow sharing their exact location with the PWA. However, this is not happening with a few users who have iPhone 11 or XR. I tested it on iPhones 14, 13, 11 Pro, and even iPhone 6, and it works as expected. I directly spoke with a user who was experiencing the problem and conducted some tests. I checked if location access was allowed in the settings. I verified if Safari was accepting with the option to always ask selected. In the settings of my system's website, I checked if location access was allowed with the option to always ask chosen. We changed all prompting options to allow. We opened the following site https://whatpwacando.today/ and found that geolocation was also not possible. Everything indicates that the issue lies with these users' phones; however, other geolocation methods work fine, as
Post not yet marked as solved
The strange certificate came from a settings error I made in the configuration file of the framework I use (Quasar). I got the https configuration for the development server wrong and Quasar issued an ad-hoc certificate instead of using the certificate I provided. So my question boils down to why Safari won't let me accept the certificate on one of the Macs. But maybe an even better solution: I added the mkcert root CA and the certificate I signed with this CA to my keychain, now Safari accepts it.
Post not yet marked as solved
Hey Quinn, thanks for responding. I was about to write that your suggestion will crash, but it turns out that only true for the async version. The version with the replyHandler that you posted does get called from the main thread, while the async one seems to be called from arbitrary threads (and thus crashing). I submitted feedback FB13774556.
Post not yet marked as solved
I'm also running into this issue, and it appears random. I've caught it happening via my remote logging. A user has valid login session data stored in IndexedDB one day. The next day, they open the PWA and the IndexedDB is gone and reset from scratch. It doesn't appear to be related to anything time based, since the log messages where they had valid session data and when they didn't are 24 hours apart. This is a PWA killer.
Post not yet marked as solved
Hi, I'm trying to implement a type conforming to WKScriptMessageHandlerWithReply while having Swift's strict concurrency checking enabled. It's not been fun. The protocol contains the following method (there's also one with a callback, but we're in 2024): func userContentController( controller: WKUserContentController, didReceive message: WKScriptMessage ) async -> (Any?, String?) WKScriptMessage's properties like body must be accessed on the main thread. But since WKScriptMessageHandlerWithReply is not @MainActor, neither can this method be so marked (same for the conforming type). At the same time WKScriptMessage is not Sendable, so I can't handle it in Task { @MainActor in this method, because that leads to Capture of 'message' with non-sendable type 'WKScriptMessage' in a `@Sendable` closure That leaves me with @preconcurrency import - is that the way to go? Should I file a feedback for this or is it somehow working as intended?
Post not yet marked as solved
Hi Apple Team, We have a PWA which supports downloading and playback for audio and video content. Downloaded content is stored in IndexedDB in the form of blobs and blob URLs are generated on runtime through which content is played. We have observed that the blob URLs have stopped working on iOS 17.4.1. They work on iOS 17.4 and iOS 17.3 as well. This feature is very critical for us as it is the heart of the offline mode of the app. Thanks!
Post not yet marked as solved
Hello, I am on the latest iOS 17.5 beta, still having issues with my extension.
Post not yet marked as solved
The issue with remote inspection of content in Safari on visionOS has been fixed as of visionOS 1.2 (currently available in beta, Simulator available with Xcode 15.4) both on-device and in Simulator. A fix for devices was made earlier in a patch release to visionOS 1.1 You may still encounter another issue with content not being remote-inspectable: https://bugs.webkit.org/show_bug.cgi?id=271134#c4 The workaround described there works for visionOS Simulator too: open the page again in another tab in Safari on the Simulator. That bug has also been addressed and a fix is coming in a future OS update. Track https://bugs.webkit.org/show_bug.cgi?id=271134 to know when a public build is available.
Post not yet marked as solved
Hello, I have noticed an issue when using my web application via TestFlight on iOS devices. When I try to print through the application, a message This action will take you outside the app, press OK to continue appears. This message prevents the user from printing documents from the application. Steps to reproduce the issue: Open my web application via TestFlight on an iOS device. Press the print button in the application. Expected behavior: It is expected that the user can print documents from the web application via TestFlight without any obstacles. Actual behavior: When pressing the print button, a message This action will take you outside the app, press OK to continue appears, preventing printing.
