If you use the ipad pro's magic keyboard cover, and you do a five-finger app switch on the screen, the trackpad will stop sending PointerEvents into the browser once you return. You have to throw away the app and start over to get PointerEvents to work again. This happens in WebViews inside apps as well as safari. Note that MouseEvents still get sent. https://codepen.io/msfeldstein/pen/jOmpowb
*** Bug 236391 has been marked as a duplicate of this bug. ***
*** Bug 236392 has been marked as a duplicate of this bug. ***
<rdar://problem/88763390>
Still repros on iOS 16.0 beta 1 (20A5283p) on an iPad Air. Only on device, not in the simulator. Any gesture that goes to the app switcher seems to provoke the bug, not just the five-finger pinch. For instance, swiping up from the bottom of the screen.
AFAICT the WKContentView's gesture recognizers are operating normally -- events are coming through. Tried making the WKContentView stop watching applicationWillResignActive and applicationDidBecomeActive notifications, but that didn't seem to affect anything. Only difference between good and bad states that I can find: Set a breakpoint on `WebPageProxy::didReceiveEvent` with a condition "($x1 & 0xFFFFFFFF) == 0". That catches the response from the content process after sending the event. In the good state, the second argument 'handled' aka $x2 is true. In the bad state, it's false. So, something different is happening in the content process, but it's hard to tell what.
In iPadOS 16 beta 6, this bug is also provoked when you use the new-style edit menu. (Use a hardware trackpad and two-finger click or control-click. Or, use a hardware keyboard and hold control while tapping.) 1. On iPad with trackpad attached, in Safari, visit https://codepen.io/msfeldstein/pen/jOmpowb 2. Put pointer over the text in the bottom of the screen 3. Control-click or two-finger click on trackpad to show edit menu 4. Dismiss the menu by clicking outside of it 5. Click a few more times in the text Expected: the text should update with more POINTERDOWN timestamps Actual: it doesn't.
No news about this bug? This is really blocking the use of VSCode with Safari on iPad
This works best via Chrome on the iPad (although it is WebKit like Safari). The scroll works without setting the site zoom to 85% and the selection with the cursor also (the right click does not open the editing popup of the OS)
This is most likely a Safari issue and not a WebKit issue per se. I'll forward this information to the Safari team.
It isn't just Safari. I've seen this bug affect my native app that uses a WKWebView. Both the original bug (five-finger app switcher gesture, or swipe up from home affordance), and the case in Comment 6 with the edit menu.
This is still broken with iPadOS 17.4. The old codepen link is no longer working, but this one is a replacement: https://codepen.io/krevis-figma/pen/yLKejBa 1. Load that page in Mobile Safari 2. Using mouse/trackpad, click in the text at the bottom. Confirm that you see a POINTERDOWN for each click. 3. Swipe upwards from the bottom of the screen to show the dock. -- OR -- Hold the control key down (on an attached hardware keyboard) and tap the text to show a context menu, then tap outside to dismiss it. 4. Use the mouse/trackpad again and click in the text. Expected: We continue to see POINTERDOWNs for each click. Actual: we don't.
I've just hit this same bug, but it also happens with a Bluetooth mouse! Basically, anytime after bringing up the dock by swiping up from the bottom, PointerEvents stop getting dispatched for mouse input, though MouseEvents still work. This is absolutely critical. How can this be broken for so long? I'm getting 1-star reviews because my WKWebView-based app randomly breaks because of this egregious bug.
And how is this still in "NEW" status? This affects a large number of users and breaks basic system functionality. Seriously? Stop adding new emoji and start fixing basic bugs!
Sorry, just realized that this is probably in Apple's playing field, not WebKit's... so forget the "Emojis" comment!
After a day of investigation in the WebKit source and random playing around, I found out that the bug does NOT happen if the HTML element which has the PointerEvent listener(s) does NOT overlap with the bottom system gesture area, eg: - a div element with height calc(100vh - 50px): triggers the bug - a div element with height calc(100vh - 190px): does NOT trigger the bug So the problem must be that the system gesture recognizer somehow interferes with and disables WebKit's handling / creation of PointerEvents. Note that css :hover is also affected.
It seems that if the gesture you're doing to pull up the dock overlaps with the element that has the event listeners (i.e., your finger touches the element while doing the gesture), the bug is triggered.
WORKAROUND: I've developed a workaround for this problem as a small JavaScript snippet. https://seven.systems/WebkitMouseFix.js (sorry, compiled JS... but it's readable enough) How to use: - load via [script src="WebkitMouseFix.js"] - if you determine that you are in danger of hitting this bug (i.e. you are on iOS and your users are potentially using a mouse), call WebkitMouseFix.init() once How it works: - once .init() has been called, it will detect whenever iOS stops sending pointer events for the mouse - it will generate "artificial" pointerdown/move/up events from mousedown/move/up events - it also has a custom emulated .setPointerCapture / .releasePointerCapture implementation for the artificial events Only very little testing has been done, but seems to work well enough for simple cases. Public Domain, feel free to share and improve!
Thanks for that workaround ae@seven.systems, but it doesn't seem to work properly for more complex apps like ours, im still seeing missing pointer events. I think its still very important that this is fixed properly by the system.
(In reply to Michael Feldstein from comment #18) > Thanks for that workaround ae@seven.systems, but it doesn't seem to work > properly for more complex apps like ours, im still seeing missing pointer > events. I think its still very important that this is fixed properly by the > system. Yes, we're also still getting user reports about the mouse "sometimes" ceasing to work. It's really pretty insane that something like this is going on for years. But then again, I've stopped wondering about the state of software quality years ago 😄 FEATURES, FEATURES, FEATURES!!! For the bean counters I guess...