1628739 - Hit region for scrolling div is wrong on specific page `will-change: transform;` and a filter on parent

Status: RESOLVED FIXED

(Core :: Web Painting, defect, P3)

Description

[Dennis Schubert [:denschub]]

We have received a report about an issue where sometimes, scrolling fails on macOS if the element to be scrolled has will-change: transform; set, and its parent has a filter (in that case a drop shadow) attached to it.

The reporter provided this testcase: https://codepen.io/pranksinatra/pen/yLYBLyB and even though I can't reproduce reliably, other team members can.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Attachment: test case

While I can reproduce intermittently on the codepen.io page, I can't repro on a standalone page (attached), except for when the mouse is over the area just inside the bottom of the red box. So I think most of this bug is just "codepen sucks". I'll look a bit closer at the issue I can reproduce on the standalone page.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #1)

I'll look a bit closer at the issue I can reproduce on the standalone page.

It looks like the hitregion for the scroller in layer tree is not at the right position. It's top-left is (2,2) which doesn't take into account the vertical offset produced by the "Try to scroll in Firefox" text, and so when APZ does a hit-test on the bottom part of the scroller it ends up hitting the root scroller instead.

With WR enabled the standalone page behaves as intended, so making this a P3.

Also note that the codepen has a bug in the CSS, transform: transform: ... and I don't know if that's intentional or not.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

For future reference:

MOZ_LOG="apz.inputqueue:4,apz.manager:4" ./mach mozregression --persist ~/Downloads/mozregression/ --launch 2020-04-07 -a "~/Downloads/1628739.html" -P stdout

APZCTreeManager (0x1285c2000)
  HitTestingTreeNode (0x1292b6020) APZC (0x1290f7000) g=({ l=0x100000006, p=3, v=2 }) r=({}) t=([ I ]) c=(< (x=0, y=0, w=2560, h=1622); >)
    HitTestingTreeNode (0x12c533100) APZC (0x0) g=(l=0x100000006) r=({ hitregion=< (x=0, y=0, w=2560, h=1622); >}) t=([ I ]) c=(none)
    HitTestingTreeNode (0x12c3b57a0) APZC (0x0) g=(l=0x100000006) r=({}) t=([ I ]) c=(< (x=0, y=0, w=2560, h=1622); >)
    HitTestingTreeNode (0x12c3b55c0) APZC (0x0) g=(l=0x100000006) r=({ hitregion=< (x=132, y=0, w=2348, h=66); (x=0, y=66, w=138, h=20); (x=0, y=86, w=138, h=4); (x=152, y=86, w=36, h=4); (x=0, y=90, w=138, h=32); (x=152, y=90, w=36, h=32); (x=2424, y=90, w=32, h=32); (x=2506, y=90, w=32, h=32); (x=0, y=122, w=138, h=4); (x=152, y=122, w=36, h=4); (x=0, y=126, w=138, h=18); (x=0, y=144, w=2560, h=2); > dispatchtocontentregion=< (x=212, y=0, w=2268, h=66); (x=0, y=66, w=74, h=78); >}) t=([ I ]) c=(none)
    HitTestingTreeNode (0x1292b6200) APZC (0x0) g=(l=0x100000006) r=({}) t=([ 1 0; 0 1; 0 148; ]) c=(< (x=0, y=148, w=2560, h=1474); >)
      HitTestingTreeNode (0x1292b63e0) APZC (0x0) g=(l=0x100000007) r=({}) t=([ I ]) c=(none)
        HitTestingTreeNode (0x1292b6980) APZC (0x0) g=(l=0x100000007) r=({}) t=([ I ]) c=(< >)
        HitTestingTreeNode (0x1292b67a0) APZC (0x0) g=(l=0x100000007) r=({ hitregion=< (x=0, y=0, w=2560, h=1474); >}) t=([ I ]) c=(none)
        HitTestingTreeNode (0x1292b65c0) APZC (0x12c77e000) g=({ l=0x100000007, p=2, v=2 }) r=({ hitregion=< (x=0, y=0, w=2560, h=1474); >}) t=([ I ]) c=(< (x=0, y=0, w=2560, h=1474); >)
        HitTestingTreeNode (0x12c3b5020) APZC (0x12c77e000) g=({ l=0x100000007, p=2, v=2 }) r=({}) t=([ I ]) c=(< (x=0, y=0, w=2560, h=1474); >)
          HitTestingTreeNode (0x12c3b5200) APZC (0x1114f7000) g=({ l=0x100000007, p=2, v=3 }) r=({ hitregion=< (x=2, y=2, w=600, h=600); > dispatchtocontentregion=< (x=2, y=2, w=600, h=600); >}) t=([ I ]) c=(< (x=2, y=2, w=600, h=600); >)

It's the regions on that last HTTN that are not positioned correctly relative to what one sees visually.

Comment 4

[Botond Ballo [:botond]]

Based on comment 2, is this likely a Web Painting issue?

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Probably, yes.

Comment 6

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)