From f6671f856165b67ff6929dbf6bc646a300d7112d Mon Sep 17 00:00:00 2001 From: Alexander Ljungberg Date: Fri, 19 Aug 2016 14:35:19 +0100 Subject: [PATCH] Fixed: iOS virtual keyboard broke hit tests. Without this fix, tapping on the screen while the virtual keyboard of iOS was open, and it had forced scrolling (due to the input being low on the screen), would cause incorrect mouse event locations. So you might tap on a text field below your current field to edit it and something entirely different would get selected. --- AppKit/Platform/DOM/CPPlatformWindow+DOM.j | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/AppKit/Platform/DOM/CPPlatformWindow+DOM.j b/AppKit/Platform/DOM/CPPlatformWindow+DOM.j index 15d55a070..ba8d113d1 100644 --- a/AppKit/Platform/DOM/CPPlatformWindow+DOM.j +++ b/AppKit/Platform/DOM/CPPlatformWindow+DOM.j @@ -1171,7 +1171,11 @@ _CPPlatformWindowWillCloseNotification = @"_CPPlatformWindowWillCloseNotificatio var touch = aDOMEvent.touches.length ? aDOMEvent.touches[0] : aDOMEvent.changedTouches[0]; newEvent.clientX = touch.clientX; - newEvent.clientY = touch.clientY; + + /* + Normally the document can't scroll in Cappuccino: our body element has top:0 and bottom:0 with absolute positioning. So it should always be exactly the height of the viewport. The below handles a special case. iOS scrolls the document when the virtual keyboard is present and it needs to move a text input upwards visually to avoid covering the input with the keyboard. For most purposes we can ignore this, except here. In theory I think we could always apply this (scrollTop should always be 0 on every other device and situation) but let's be defensive and only apply it for touch events to minimise the risk of surprises. + */ + newEvent.clientY = _DOMWindow.document.body.scrollTop + touch.clientY; newEvent.timestamp = [CPEvent currentTimestamp]; newEvent.target = aDOMEvent.target;