We have some code here which collapses touch-action regions into the dispatch-to-content region if we get more than one touch-action rectangle. Since this code runs after the the rectangles are updated here it means that a single element with touch-action: pan-x pan-y will trigger the collapsing codepath and end up in the dispatch-to-content region. This is undesirable because it's perfectly possible to represent this case in the layer tree.

There's also the case like this:

<div style="touch-action: pan-x pan-y">
 <div style="something that makes this div generate a hit-test info item"></div>
</div>

where there is really only one element with touch-action, but that touch-action property gets inherited down into descendant elements. And then the FrameLayerBuilder codepath gets multiple hit-test info items, and treats them as "multiple rectangles" and does the collapsing thing.

I wrote patches to improve this as an attempt to fix bug 1648491. Unfortunately it didn't fix that bug due to other complications. The patches do work as intended though and might be worth landing. There might be a bit of a perf hit because of the extra field added to the HitTestInfo structure. I'll put them up as WIP for now.

Unrelated cleanup that I wanted to do while I was digging around in this code.

This patch adds some plumbing so that the nsDisplayListBuilder can track a
"touch-action root" frame, which is defined as the nearest ancestor frame which
modified the touch-action bits in the hit-test info. This field is currently
initialized on constructing the nsDisplayListBuilder, but not yet updated (that
will happen in the next patch). The plumbing also propagates the current value
of the field into any hit-test info items that are created, so that they can
be used by the FrameLayerBuilder when collapsing touch-action regions (also in
a future patch).

Depends on D89200

As we descend the frame tree to build the display list, we identify frames that
are touch-action roots (basically, scrollable scrollframes and elements with
touch-action properties), and update the display list builder accordingly.

Depends on D89201

This refines the existing condition in FrameLayerBuilder from "do we have
multiple display items with touch-action rects" to "do we have multiple display
items with different touch-action roots". In particular it allows us to handle
the case where there is an element with touch-action properties, and then
descendant elements inherit the same touch-action properties but generate their
own hit-test display items. Previously those subsequent display items would
trigger the "already have rects" condition even though they can be safely
merged. The new code will detect that they share the same touch-action root
and allow the regions to be merged.

Depends on D89202

Depends on D89203

I think my plan here is to abandon these changes. It adds some extra complexity to the layers codepath which we're going to be eventually removing anyway, and the fix from bug 1648491 is more robust.

The first patch here is just const-ification which might be worth landing but for now I'll just wontfix this bug and if I find some time later I can repost the const-ification to another bug.