1311505 - invisible element prevents scrollwheel from working with multiprocess enabled

Status: NEW

(Core :: Panning and Zooming, defect, P3)

Description

[zaid]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20161019004013

Steps to reproduce:

1. Make sure multiprocess is enabled
2. Sign into sandglaz.com (sample account username: [e-mail], password: demopassword)
3. Try to scroll the project list using the scroll gesture.


Actual results:

If the mouse is on the leftmost edge, it does scroll. If it is in the center of the project list, it doesn't scroll. However the scroll gesture makes the scrollbars appear, and they can be dragged to scroll the page. 

This only occurs if multiprocess is enabled.


Expected results:

The element should have scrolled.

Comment 1

[Alice0775 White]

I can reproduce on Windows10 Nightly52.0a1.

Comment 2

[Alice0775 White]

Attachment: html (For the record)

Comment 3

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=16b370b80a93eaf19a255945002c9a0c617c76db&tochange=7d77ceeacfa6f625623f49cca04270e9e9a4b282


Regressed by: Bug 1203140

Comment 4

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

Thanks, I'll take a look (probably on Friday since I'll be off tomorrow).

Comment 5

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

So it looks like the page has touch listeners somewhere on the root document or document element. Prior to bug 1203140, we would mark the entire layer tree with the force-dispatch-to-content flag so that the hit-testing would go through the main thread. After bug 1203140, we don't set that flag any more (because we ignore the touch listeners on devices that don't have touch support). The compositor hit-test finds a different layer than the main-thread hit-test would have, and this results in the thing not scrolling properly.

This is a case of bug 1203140 exposing a pre-existing problem in the compositor hit-testing code, so we should fix the compositor hit-testing bug. I'll keep digging.

Comment 6

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

This might be an issue with generating the correct clip rects in the layer tree.

First, there's a <div id="sidebar"> which contains the left sidebar (the thing we're trying to scroll). That div is position:fixed with z-index:0.

Later in the document, as a sibling of the sidebar, there's a <div id="grid_show"> which is also position:fixed but has z-index:100. The grid would ordinarily sit on top of the sidebar, but it has a translateX(300) transform applied, so it's shifted over to the right.

Now, the contents of the grid expand beyond the visible bounds of the grid. That is, somewhere inside the grid, there is an element <div class="vertical-scroll column single-day past">, which, if it weren't clipped by the grid, would sit on top of the sidebar (minus some pixels at the top of the sidebar). The event regions for this element are generated and pushed over to the compositor as part of the grid's layer, and the grid's layer sits at a higher z-index than the sidebar, so it gets hit first. It seems to me that there should be some sort of clip on the grid's layer that prevents this from happening. Or the event regions should be getting clipped on the layout side somewhere. Markus, any thoughts?

I'm attaching the display list and layer tree dump for the page. The layer at 0x7f0544d96c00 is the one that is stealing the input, because the event regions at 0x7f0545606020 are leaking out. The display items at 0x7f0545712be8 and 0x7f0545712a28 are for the position:fixed and transform:translateX(300) on the grid.

Comment 7

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

Attachment: Display list/client layer tree dump

Comment 8

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

Dropping stale needinfo. As this is clip-related we might as well wait until bug 1298218 is landed and then see if it still happens.

Comment 9

[Markus Stange [:mstange]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #6)
> Or the event regions should be
> getting clipped on the layout side somewhere.

This sounds like the right thing to do, but I'm a bit surprised if we didn't do that already somewhere, or at least tried to.

Comment 10

[Markus Stange [:mstange]]

Attachment: not a testcase

I've tried to create a testcase based on your description of the problem but it doesn't seem to reproduce the bug.

Comment 11

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

The URL field of the bug has a saved copy of the original page. I can try to reduce it down to a minimal test case if that would help.

Comment 12

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

This is not fixed by bug 1298218 (tested on OS X build from https://hg.mozilla.org/mozilla-central/rev/dd7cce059626e9787537bf9ba7863a6ad8ac06a1)

Comment 13

[Nathan Froyd [:froydnj]]

Kats, it looks like we've spent a couple of releases opting not to fix this.  Should we just mark this fix-optional for 54 and officially classify this bug as a backlog bug?

Comment 14

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

Yup.