Bug 200204 - Content in <iframe> should override "touch-action" set in embedding document
Summary: Content in <iframe> should override "touch-action" set in embedding document
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on: 200853
Blocks:
  Show dependency treegraph
 
Reported: 2019-07-28 12:38 PDT by Simon Fraser (smfr)
Modified: 2020-04-08 14:44 PDT (History)
4 users (show)

See Also:


Attachments
Test (650 bytes, text/html)
2019-08-16 01:24 PDT, Antoine Quint
no flags Details
patch (4.67 KB, patch)
2019-08-16 05:04 PDT, Antti Koivisto
no flags Details | Formatted Diff | Diff
alternative fix (4.97 KB, patch)
2019-08-17 00:30 PDT, Antti Koivisto
no flags Details | Formatted Diff | Diff
patch (4.59 KB, patch)
2019-08-17 00:33 PDT, Antti Koivisto
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Fraser (smfr) 2019-07-28 12:38:06 PDT
What should be the behavior of touch-action on an <iframe>? Should it override the touch-actions of the iframe contents or not?
Comment 1 Antoine Quint 2019-08-16 01:24:27 PDT
I would have expected them to, but the spec doesn't seem to say anything in that regard. Empirically, the attached test shows in the Chrome dev tools using Pixel 2 as the emulated device that scrollable content in an <iframe> does scroll when the top-level document has "touch-action: none" set.
Comment 2 Antoine Quint 2019-08-16 01:24:46 PDT
Created attachment 376484 [details]
Test
Comment 3 Antti Koivisto 2019-08-16 04:57:13 PDT
<rdar://problem/54355249>
Comment 4 Antti Koivisto 2019-08-16 05:04:43 PDT
Created attachment 376493 [details]
patch
Comment 5 Antti Koivisto 2019-08-16 06:07:11 PDT
(In reply to Antoine Quint from comment #1)
> I would have expected them to, but the spec doesn't seem to say anything in
> that regard. Empirically, the attached test shows in the Chrome dev tools
> using Pixel 2 as the emulated device that scrollable content in an <iframe>
> does scroll when the top-level document has "touch-action: none" set.

I don't think spec is ambiguous about this:

"A touch behavior is supported if it conforms to the touch-action property of each element between the hit tested element and its nearest ancestor with the default touch behavior (including both the hit tested element and the element with the default touch behavior)."

With iframe content the "nearest ancestor with the default touch behavior" is the iframe. If there is no 'touch-action' set in any of the elements between the touch element and the iframe then default touch-action (auto) is applied, no matter what it is set in iframes ancestors.
Comment 6 Antti Koivisto 2019-08-16 06:18:17 PDT
Well, I suppose it is bit ambiguous what "nearest ancestor with the default touch behavior" exactly means for frame content as <iframe> is not a DOM ancestor of its content document. Whatever the interpretation is it doesn't affect this bug though.
Comment 7 WebKit Commit Bot 2019-08-16 08:48:09 PDT
Comment on attachment 376493 [details]
patch

Clearing flags on attachment: 376493

Committed r248772: <https://trac.webkit.org/changeset/248772>
Comment 8 WebKit Commit Bot 2019-08-16 08:48:10 PDT
All reviewed patches have been landed.  Closing bug.
Comment 9 WebKit Commit Bot 2019-08-16 22:15:42 PDT
Re-opened since this is blocked by bug 200853
Comment 10 Antti Koivisto 2019-08-17 00:30:21 PDT
Created attachment 376598 [details]
alternative fix

Instead of generating the event region for frame top layer (the previous patch) simply treat the missing region as indicating touch-action:none when resolving touch-actions in UI process.
Comment 11 Antti Koivisto 2019-08-17 00:33:42 PDT
Created attachment 376599 [details]
patch
Comment 12 WebKit Commit Bot 2019-08-17 01:50:19 PDT
Comment on attachment 376599 [details]
patch

Clearing flags on attachment: 376599

Committed r248819: <https://trac.webkit.org/changeset/248819>
Comment 13 WebKit Commit Bot 2019-08-17 01:50:21 PDT
All reviewed patches have been landed.  Closing bug.