WebKit JS

RSS for tag

Access and modify DOM elements within a webpage, including touch events and visual effects, using WebKit JS.

Posts under WebKit JS tag

30 Posts

Post

Replies

Boosts

Views

Activity

WKWebView: Fullscreen API User Gesture Bypass
Howdy, WKWebView feature request: allow Fullscreen API without User Gestures similar to ElectronJS' userGesture: true flag that allows devs to bypass user gesture restriction for Fullscreen API and similar executeJavaScript(code[, userGesture]) https://www.electronjs.org/docs/latest/api/web-contents#contentsexecutejavascriptcode-usergesture afaik this is allowed because of a fairly recent update to Chromium that also allows users to give Fullscreen API permissions per domain https://chromeos.dev/en/posts/using-the-fullscreen-api-without-gestures Would be greatly useful for a use case in my cross-platform app, so I can avoid rewriting all platforms to use Chromium Thanks
1
0
142
Apr ’25
SIGABRT on WebKit macOS 15.3.2
The application I'm currently working on uses WebKit. Based on the crash analytics, we have noticed that some of our users are experiencing an unusual behavior in the app's WebKit view with macOS 15.3.2. These errors are reported for this version of the OS. The error in the crash log is a SIGABRT error, but there is no relevant information available to address it. In some crash logs, we found this error: "NSInternalInconsistencyException: Returned WKWebView was not created with the given configuration" but there is not any particular way to address it. Is there a way to identify the cause of this error? Alternatively, has anyone encountered this issue and found a solution? OS Version: macOS 15.3.2 (24D81) Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Crashed Thread: 0 Application Specific Information: Returned WKWebView was not created with the given configuration. Thread 0 Crashed: 0 CoreFoundation 0x303111e74 __exceptionPreprocess 1 libobjc.A.dylib 0x3027b6cd4 objc_exception_throw 2 CoreFoundation 0x303111d6c +[NSException raise:format:] 3 WebKit 0x34e85cb20 WebKit::UIDelegate::UIClient::createNewPage 4 WebKit 0x34e8a4a80 WebKit::SOAuthorizationCoordinator::tryAuthorize 5 WebKit 0x34e9f04f8 WebKit::WebPageProxy::createNewPage 6 WebKit 0x34ef994c8 WebKit::WebPageProxy::didReceiveSyncMessage 7 WebKit 0x34f0830cc IPC::MessageReceiverMap::dispatchSyncMessage 8 WebKit 0x34ea753b0 WebKit::WebProcessProxy::didReceiveSyncMessage 9 WebKit 0x34f07cfb4 IPC::Connection::dispatchSyncMessage 10 WebKit 0x34f07d3b0 IPC::Connection::dispatchMessage 11 WebKit 0x34f078c50 IPC::Connection::SyncMessageState::ConnectionAndIncomingMessage::dispatch 12 WebKit 0x34f07f4f4 ***::Detail::CallableWrapper<T>::call 13 JavaScriptCore 0x33f3520c0 ***::RunLoop::performWork 14 JavaScriptCore 0x33f352fe8 ***::RunLoop::performWork 15 CoreFoundation 0x30309f8a0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 16 CoreFoundation 0x30309f834 __CFRunLoopDoSource0 17 CoreFoundation 0x30309f598 __CFRunLoopDoSources0 18 CoreFoundation 0x30309e134 __CFRunLoopRun 19 CoreFoundation 0x30309d730 CFRunLoopRunSpecific 20 HIToolbox 0x319aeb52c RunCurrentEventLoopInMode 21 HIToolbox 0x319af1344 ReceiveNextEventCommon 22 HIToolbox 0x319af1504 _BlockUntilNextEventMatchingListInModeWithFilter 23 AppKit 0x30a7cd844 _DPSNextEvent 24 AppKit 0x30b133c20 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] 25 AppKit 0x30a7c0870 -[NSApplication run] 26 AppKit 0x30a797064 NSApplicationMain 27 <unknown> 0x182780274 <redacted> Thread 0 name: t-main-ui Crashed: 0 CoreFoundation 0x303111e74 __exceptionPreprocess 1 libobjc.A.dylib 0x3027b6cd4 objc_exception_throw 2 CoreFoundation 0x303111d6c +[NSException raise:format:] 3 WebKit 0x34e85cb20 WebKit::UIDelegate::UIClient::createNewPage 4 WebKit 0x34e8a4a80 WebKit::SOAuthorizationCoordinator::tryAuthorize 5 WebKit 0x34e9f04f8 WebKit::WebPageProxy::createNewPage 6 WebKit 0x34ef994c8 WebKit::WebPageProxy::didReceiveSyncMessage 7 WebKit 0x34f0830cc IPC::MessageReceiverMap::dispatchSyncMessage 8 WebKit 0x34ea753b0 WebKit::WebProcessProxy::didReceiveSyncMessage 9 WebKit 0x34f07cfb4 IPC::Connection::dispatchSyncMessage 10 WebKit 0x34f07d3b0 IPC::Connection::dispatchMessage 11 WebKit 0x34f078c50 IPC::Connection::SyncMessageState::ConnectionAndIncomingMessage::dispatch 12 WebKit 0x34f07f4f4 ***::Detail::CallableWrapper<T>::call
3
0
210
Apr ’25
Declarative Web Push
Anybody succeeded sending a Web Push Message using the new Declarative approach introduced with Safari Version 18.4 (20621.1.14.11.3)? I will help as well if someone can point me to a solution debugging the entire system using Xcode and Minibrowser? Currently I can't get the MiniBrowser connected to the WebPush Daemon.
0
0
235
Mar ’25
Prevent iOS from Switching Between Back Camera Lenses in getUserMedia (Safari/WebView, iOS 18)
I’m developing a hybrid app (WebView / Turbo Native) that uses getUserMedia to access the back camera for a PPG/heart rate measurement feature (the user places their finger on the camera). Problem: Even when I specify constraints like: { video: { deviceId: '...', facingMode: { exact: 'environment' }, advanced: [{ zoom: 1.0 }] }, audio: false } On iPhone 15 (iOS 18), iOS unexpectedly switches between the wide, ultra-wide, and telephoto lenses during the measurement. This breaks the heart rate detection, and it forces the user to move their finger in the middle of the measurement. Question: Is there any way, via getUserMedia/WebRTC, to force iOS to use only the wide-angle lens and prevent automatic lens switching? I know that with AVFoundation (Swift) you can pick .builtInWideAngleCamera, but I’m hoping to avoid building a custom native layer and would prefer to stick with WebView/JavaScript if possible to save time and complexity. Any suggestions, workarounds, or updates from Apple would be greatly appreciated! Thanks a lot!
1
0
439
Mar ’25
iOS17 WebKit crash IPC::Connection::cancelReply<Messages::WebPage::PerformDragControllerAction
Who can help me, I am running into a WebKit crash on ios 17 and I cannot reproduce it in the debug environment. Crashes happen in these iOS version:17.6.1, 17.5.1, 17.7.5, 17.4, 17.7, 17.4.1, 17.7.3, 17.6 WebKit IPC::Connection::cancelReply<Messages::WebPage::PerformDragControllerAction, WebKit::WebPageProxy::performDragControllerAction(WebKit::DragControllerAction, WebCore::DragData&, std::__1::optional<WebCore::ProcessQualified<WTF::ObjectIdentifierGeneric<WebCore::FrameIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits> > > const&)::$_26>(WebKit::WebPageProxy::performDragControllerAction(WebKit::DragControllerAction, WebCore::DragData&, std::__1::optional<WebCore::ProcessQualified<WTF::ObjectIdentifierGeneric<WebCore::FrameIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits> > > const&)::$_26&&) (in WebKit) WebKit WTF::Detail::CallableWrapper<WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRef<IPC::Encoder>&&, WTF::OptionSet<IPC::SendOption>, std::__1::optional<IPC::ConnectionAsyncReplyHandler>, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Decoder*>::call(IPC::Decoder*) (in WebKit) WebKit IPC::Connection::cancelAsyncReplyHandlers() (in WebKit) WebKit IPC::Connection::invalidate() (in WebKit) WebKit WebKit::AuxiliaryProcessProxy::shutDownProcess() (in WebKit) WebKit WebKit::WebProcessProxy::shutDown() (in WebKit) WebKit WebKit::WebProcessProxy::processDidTerminateOrFailedToLaunch(WebKit::ProcessTerminationReason) (in WebKit) WebKit WebKit::WebProcessProxy::didClose(IPC::Connection&) (in WebKit) WebKit IPC::Connection::dispatchMessage(std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >) (in WebKit) WebKit IPC::Connection::SyncMessageState::ConnectionAndIncomingMessage::dispatch() (in WebKit) WebKit WTF::Detail::CallableWrapper<IPC::Connection::SyncMessageState::processIncomingMessage(IPC::Connection&, std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >&)::$_5, void, >::call() (in WebKit) JavaScriptCore WTF::RunLoop::performWork() (in JavaScriptCore) JavaScriptCore WTF::RunLoop::performWork(void*) (in JavaScriptCore) CoreFoundation ___CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (in CoreFoundation) CoreFoundation ___CFRunLoopDoSource0 (in CoreFoundation) CoreFoundation ___CFRunLoopDoSources0 (in CoreFoundation) CoreFoundation ___CFRunLoopRun (in CoreFoundation) CoreFoundation _CFRunLoopRunSpecific (in CoreFoundation) GraphicsServices _GSEventRunModal (in GraphicsServices) UIKitCore -[UIApplication _run] (in UIKitCore) UIKitCore _UIApplicationMain (in UIKitCore) homework main (in homework:main.m:39) dyld start (in dyld)
0
0
526
Mar ’25
crossorigin="anonymous" Prevents Rendering and Canvas Access for Custom Scheme and HTTP Images on iOS 18
On iOS 18, when setting the src attribute of an tag to a custom scheme (e.g., myapp://image.png) or an HTTP URL (http://example.com/image.png), if crossorigin="anonymous" is applied, the image fails to load. Additionally, images affected by this issue cannot be drawn to a , as the browser treats them as tainted and blocks access to their pixel data. This issue did not occur in previous iOS versions and seems to be a regression in iOS 18. Steps to Reproduce: Open an HTTPS-hosted H5 page in Safari on iOS 18. Add an tag with crossorigin="anonymous" and set src to either: A custom scheme: <img src="myapp://image.png" crossorigin="anonymous"> An HTTP URL (even from the same origin): <img src="http://example.com/image.png" crossorigin="anonymous"> Observe that the image does not load. Attempt to draw the image onto a and retrieve its data: const canvas = document.createElement("canvas"); const ctx = canvas.getContext("2d"); const img = new Image(); img.crossOrigin = "anonymous"; img.src = "http://example.com/image.png"; // or "myapp://image.png" img.onload = () => { ctx.drawImage(img, 0, 0); try { console.log(canvas.toDataURL()); // Expect base64 image data } catch (error) { console.error("Canvas is tainted:", error); } }; Notice that the image is blocked, and any attempt to access pixel data results in a CORS error. Expected Behavior: * The image should be displayed if it is accessible under normal CORS rules. * The API should allow access to the image data unless explicitly blocked by the server’s CORS policy. Actual Behavior: The image fails to load when crossorigin="anonymous" is applied. The API does not allow access to the image data, treating it as tainted. Removing crossorigin="anonymous" allows the image to display in some cases, but this is not a viable workaround when CORS enforcement is required. Regression: Works correctly on: iOS 17 and earlier Broken on: iOS 18 Environment: Device: iPhone/iPad iOS Version: 18.0+ Browser: Safari Suggested Fix: Apple should investigate this regression and allow custom schemes and HTTP images to be correctly handled under CORS policies when crossorigin="anonymous" is set. If the source allows cross-origin requests, Safari should not block the image or its use in .
3
0
1.4k
Feb ’25