Bug 194813

Summary: [iOS] Correctly handle overlapping regions for elements with a touch-action property
Product: WebKit Reporter: Antoine Quint <graouts>
Component: DOMAssignee: Antoine Quint <graouts>
Status: RESOLVED FIXED    
Severity: Normal CC: ews-watchlist, koivisto, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=197281
Bug Depends on: 196608, 196701    
Bug Blocks:    
Attachments:
Description Flags
wip
none
wip
none
Patch
koivisto: review+, ews-watchlist: commit-queue-
Archive of layout-test-results from ews213 for win-future none

Antoine Quint
Reported 2019-02-19 01:55:40 PST
The code we currently use to gather regions for elements with touch-action set on them is very basic and does not account for any element that might overlap it. For instance, having "touch-action: none" on an element and having another element overlap in a different hierarchy means the other element is also treated to have "touch-action: none".
Attachments
wip (11.89 KB, patch)
2019-04-08 05:59 PDT, Antti Koivisto
no flags
wip (12.45 KB, patch)
2019-04-08 07:00 PDT, Antti Koivisto
no flags
Patch (30.60 KB, patch)
2019-05-08 12:42 PDT, Antoine Quint
koivisto: review+
ews-watchlist: commit-queue-
Archive of layout-test-results from ews213 for win-future (13.65 MB, application/zip)
2019-05-08 15:48 PDT, EWS Watchlist
no flags
Radar WebKit Bug Importer
Comment 1 2019-02-19 02:20:01 PST
Antti Koivisto
Comment 2 2019-04-08 05:59:25 PDT
Antti Koivisto
Comment 3 2019-04-08 07:00:37 PDT
Antti Koivisto
Comment 4 2019-04-08 12:10:09 PDT
Moved the part that computes the touch actions from remote layer tree to bug 196701 for review.
Antoine Quint
Comment 5 2019-05-07 03:22:19 PDT
Found an issue where elements with "display: inline-block" don't have a touch-action region, see https://bugs.webkit.org/show_bug.cgi?id=197281.
Antoine Quint
Comment 6 2019-05-08 12:42:00 PDT
EWS Watchlist
Comment 7 2019-05-08 15:48:32 PDT
Comment on attachment 369410 [details] Patch Attachment 369410 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/12136954 New failing tests: security/contentSecurityPolicy/video-with-file-url-allowed-by-media-src-star.html legacy-animation-engine/compositing/reflections/load-video-in-reflection.html
EWS Watchlist
Comment 8 2019-05-08 15:48:34 PDT
Created attachment 369438 [details] Archive of layout-test-results from ews213 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews213 Port: win-future Platform: CYGWIN_NT-10.0-17763-3.0.5-338.x86_64-x86_64-64bit
Antti Koivisto
Comment 9 2019-05-09 00:40:55 PDT
Comment on attachment 369410 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=369410&action=review r=me > Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:1342 > + if (!touchActions.contains(WebCore::TouchAction::PinchZoom)) > + _webView.scrollView.pinchGestureRecognizer.enabled = NO; Where does this thing get reset?
Antoine Quint
Comment 10 2019-05-09 01:30:30 PDT
(In reply to Antti Koivisto from comment #9) > Comment on attachment 369410 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=369410&action=review > > r=me > > > Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:1342 > > + if (!touchActions.contains(WebCore::TouchAction::PinchZoom)) > > + _webView.scrollView.pinchGestureRecognizer.enabled = NO; > > Where does this thing get reset? I'm not actually sure, but testing indicates that the value is reset as expected. Maybe UIKit performs that reset internally, I couldn't find any code in WebKit that would do this.
Antoine Quint
Comment 11 2019-05-09 01:34:41 PDT
Note You need to log in before you can comment on or make changes to this bug.