Bugzilla

(In reply to Julien Cristau [:jcristau] from comment #24)
> I'm seeing an issue where scrolling works in some tabs (e.g. gmail) but not others (e.g. chat.mozilla.org or slack.com), and works in chrome popup windows but not in e.g. the tab strip.
> 
> Made a profile as guided by padenot: https://share.firefox.dev/3SPJAuv

Thanks for the profile. Based on the logs, something different is happening in your case than in Paul's (but still APZ related).

I'll post some analysis here anyways; we can split out this issue into a separate bug later as needed.

Here is a subset of the log that tells an interesting story about what happens to wheel events when we don't scroll in response to them:

```
D/apz.manager Hit-testing point (1164,833) with WR
D/apz.manager Examining result with guid { l=0x100000010, p=0, v=13 } hit info 0x5... 
D/apz.manager selecting as chosen result.
D/apz.manager Successfully matched APZC 7fa54ac28000 (hit result 0x5)
D/apz.inputqueue started new scroll wheel block 7fa54979ff20 id 1002 for target 7fa54ac28000
D/apz.inputqueue scheduling main thread timeout for target 7fa54ac28000
D/apz.inputqueue got a target apzc; block=1002 guid={ l=0x100000010, p=2, v=13 }
D/apz.inputqueue got a content response; block=1002 preventDefault=0
D/apz.inputqueue processing input from block 7fa54979ff20; preventDefault 0 shouldDropEvents 0 target 0
```

The initial hit test succeeds and finds an APZC with identifier v=13 and address 7fa54ac28000. We enqueue it into the input queue, creating a wheel block whose initial target APZC is the one we found via the hit-test (7fa54ac28000), and then send a message to the content process to confirm that this is what should be scrolled.

We get the requisite responses from the content process ("got a target apzc", "got a content response"). The target APZC confirmed by the content process is the same one (v=13).

When we deqeueue the event to process it, though... we now have `target 0`, i.e. the target APZC is null, so the event is dropped. Oops.

So what happened here?

The value being printed as null is `InputBlockState::mTargetApzc`. This is set initially when the input block is created, and we can see from the message "started new scroll wheel block 7fa54979ff20 id 1002 for target 7fa54ac28000" that its initial target is not null.

The only place where `mTargetApzc` is modified is in `InputBlockState::UpdateTargetApzc`. This has a few call sites but the only one applicable in this situation is `InputBlockState::SetConfirmedTargetApzc`, called when we get the "got a target apzc" message from the content process.

However, based on the message "got a target apzc; block=1002 guid={ l=0x100000010, p=2, v=13 }", the new target APZC [is also non-null](https://searchfox.org/mozilla-central/rev/f6b9653de71818550ea39fdb0cf11703c43c0cd1/gfx/layers/apz/src/InputQueue.cpp#920).

How is this possible? It turns out that `WheelBlockState` overrides `SetConfirmedTargetApzc`, and the overriden implementation can [replace the new target](https://searchfox.org/mozilla-central/rev/f6b9653de71818550ea39fdb0cf11703c43c0cd1/gfx/layers/apz/src/InputBlockState.cpp#326-329) with the result of calling `BuildOverscrollHandoffChain()->FindFirstScrollable()` on the new target.

Based on what we're seeing, what must be happening is that `FindFirstScrollable()` call returns null, and so that's what we update the target APZC to.

(In reply to Julien Cristau [:jcristau] from comment #24)
> I'm seeing an issue where scrolling works in some tabs (e.g. gmail) but not others (e.g. chat.mozilla.org or slack.com), and works in chrome popup windows but not in e.g. the tab strip.
> 
> Made a profile as guided by padenot: https://share.firefox.dev/3SPJAuv

Thanks for the profile. Based on the logs, something different is happening in your case than in Paul's (but still APZ related).

I'll post some analysis here anyways; we can split out this issue into a separate bug later as needed.

Here is a subset of the log that tells an interesting story about what happens to wheel events when we don't scroll in response to them:

```
D/apz.manager Hit-testing point (1164,833) with WR
D/apz.manager Examining result with guid { l=0x100000010, p=0, v=13 } hit info 0x5... 
D/apz.manager selecting as chosen result.
D/apz.manager Successfully matched APZC 7fa54ac28000 (hit result 0x5)
D/apz.inputqueue started new scroll wheel block 7fa54979ff20 id 1002 for target 7fa54ac28000
D/apz.inputqueue scheduling main thread timeout for target 7fa54ac28000
D/apz.inputqueue got a target apzc; block=1002 guid={ l=0x100000010, p=2, v=13 }
D/apz.inputqueue got a content response; block=1002 preventDefault=0
D/apz.inputqueue processing input from block 7fa54979ff20; preventDefault 0 shouldDropEvents 0 target 0
```

The initial hit test succeeds and finds an APZC with identifier v=13 and address 7fa54ac28000. We enqueue the wheel event into the input queue, creating a wheel block whose initial target APZC is the one we found via the hit-test (7fa54ac28000), and then send a message to the content process to confirm that this is what should be scrolled.

We get the requisite responses from the content process ("got a target apzc", "got a content response"). The target APZC confirmed by the content process is the same one (v=13).

When we deqeueue the event to process it, though... we now have `target 0`, i.e. the target APZC is null, so the event is dropped. Oops.

So what happened here?

The value being printed as null is `InputBlockState::mTargetApzc`. This is set initially when the input block is created, and we can see from the message "started new scroll wheel block 7fa54979ff20 id 1002 for target 7fa54ac28000" that its initial target is not null.

The only place where `mTargetApzc` is modified is in `InputBlockState::UpdateTargetApzc`. This has a few call sites but the only one applicable in this situation is `InputBlockState::SetConfirmedTargetApzc`, called when we get the "got a target apzc" message from the content process.

However, based on the message "got a target apzc; block=1002 guid={ l=0x100000010, p=2, v=13 }", the new target APZC [is also non-null](https://searchfox.org/mozilla-central/rev/f6b9653de71818550ea39fdb0cf11703c43c0cd1/gfx/layers/apz/src/InputQueue.cpp#920).

How is this possible? It turns out that `WheelBlockState` overrides `SetConfirmedTargetApzc`, and the overriden implementation can [replace the new target](https://searchfox.org/mozilla-central/rev/f6b9653de71818550ea39fdb0cf11703c43c0cd1/gfx/layers/apz/src/InputBlockState.cpp#326-329) with the result of calling `BuildOverscrollHandoffChain()->FindFirstScrollable()` on the new target.

Based on what we're seeing, what must be happening is that `FindFirstScrollable()` call returns null, and so that's what we update the target APZC to.