1245083 - Swiping back or forward makes scrolling on the trackpad not work until the mouse is moved

Status: NEW

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

Description

[ovidiu boca[:Ovidiu]]

Like Wayne suggested on bug 764048 on comment 4, I filed a new bug.

Steps to reproduce:


On the nightly UX builds, if you use the two finger back/forward gesture, once the page is loaded, scrolling on the trackpad doesn't work until you move the mouse.  Once it moves, the scrolling works again.  It's as if the scroll gesture is not being received by the new window.
It seems to only happen if you try to scroll too soon before the page is fully loaded again.  But once you try to scroll, even once the page is loaded, the scrolling doesn't work until you move the mouse.

I can reproduce this on Nightly 46.0a1(2016-1-13) but I can't reproduce it on Firefox 43.0.4, so this is a regression. 

Using mozregression lead me to:

Last good revision: 3ab040e254a09046d6e548ad20ce0c997ce8f05b
First bad revision: b24bf166441b9dae774dd92c8187f2453091c4ce

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3ab040e254a09046d6e548ad20ce0c997ce8f05b&tochange=b24bf166441b9dae774dd92c8187f2453091c4ce

Comment 1

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

I'm not able to reproduce this. Do you have specific URLs that you were seeing this on?

Comment 2

[ovidiu boca[:Ovidiu]]

Hi,
I used just a simple google search, for example after letter "S", I received the results and then I went to the first link https://ro.wikipedia.org/wiki/S. After you push the link you need to go on your trackpad with 2 fingers back and forward.

Comment 3

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

Thanks, I'm still not able to reproduce this. Would you be able to get a fix window for bug 764048? Since that affected Firefox 25 but not Firefox 43, it was fixed at some point between those two. I would like to know the change that fixed it, and maybe that will give us more information about how to fix it now that it has come back in Firefox 46.

Note also that you were unable to reproduce the issue in Firefox 43.0.4, but the regression window pointed to bug 1193062, which landed in Firefox 43. This sounds contradictory but makes sense if this regression is specific to APZ. In the 43 release builds (including 43.0.04) APZ is disabled and so you wouldn't see the problem. In 43 nightly, however, APZ is enabled, and so the problem would manifest. This means that the problem will affect Firefox 46 and up in release, because APZ will be enabled in Firefox 46 and up. So I'm marking this bug as affecting 46+ and blocking apz-desktop.

Comment 4

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

Ovidiu said on IRC that he wasn't able to repro this on FF 25, so getting a fix window may not be possible/easy. We can try to just debug this on central.

Comment 5

[Markus Stange [:mstange]]

(In reply to ovidiu boca[:Ovidiu] from comment #0)
> On the nightly UX builds,

What do you mean with "UX builds"? Do we still have a UX branch?

Comment 6

[ovidiu boca[:Ovidiu]]

Hi, 
I was referring to Firefox Nightly builds.

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

As the apz team is tracking this I don't think relman needs to track it too. Thanks kats

Comment 8

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

Wontfix'ing for 46 since we probably wouldn't uplift to beta even if we had a fix on Nightly right now. Also e10s (and therefore APZ) won't be going to release on 46.

Comment 9

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

Are you still able to reproduce this? I tried reproducing this again and am still unable to. If you are able to repro, perhaps the best thing to do here is for me to make a build with extra logging that you can run and that would help diagnose the problem.

Comment 10

[ovidiu boca[:Ovidiu]]

Hi,

I tested on FF Nightly 50.0a1(2016-06-14) with MacBook OS X 10.11 and I can reproduce it. When a page is loading you start to use the two finger back/forward gesture, once the page is loaded scrolling on the trackpad doesn't work until you move the mouse.

Comment 11

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

Sorry for the delay. I added some logging and pushed a try build to https://treeherder.mozilla.org/#/jobs?repo=try&revision=6883dd418103. It would be great if you could run that build from the command line and collect the stderr logging output to a file, while reproducing the problem. Let me know if you need instructions on how to do that.

Comment 12

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

Note: the build can be found at http://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-6883dd418103d4169f89e32036c297d646fb9ce8/try-macosx64/ (for some reason TreeHerder shows the build as not yet finished, but it is actually finished).

Comment 13

[ovidiu boca[:Ovidiu]]

Attachment: Browser Console output.rtf

Hi, 
Don't wary for the delay.

Here is what I did: I open the build with the command line, reproduce the problem and copy from browser console the output. Please see the attached file. If this is not what you asked please add the details that you think would help me.

Comment 14

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

Thanks, but the browser console output is not what I needed. I need the command-line output from the browser. You can get this by doing the following:

- Download the .dmg file from the folder in comment 12
- Open the .dmg file with DiskImageMounter (this should be the default in OS X), so that it gets mounted. Usually this will be mounted to /Volumes/Nightly, unless you already have other disk images mounted. If that's the case you can move the Nightly application to some temporary folder, and use the path to the temporary folder instead.
- Open the Terminal app
- Run the following command (replace the /Volumes/Nightly/ with the path as necessary):
  /Volumes/Nightly/Nightly.app/Contents/MacOS/firefox 2>&1 | tee output.txt
- This should start the Nightly build, and start dumping a bunch of logging to the terminal. The logging will also get saved into the output.txt file in the current directory (probably your home directory).
- Reproduce the bug and close firefox
- Attach the output.txt file to this bug

Note that if you have multiple Firefox profiles you can launch the Nightly build with a specific profile by adding "-P <profilename>" into the command, just before the "2>&1" piece.

Let me know if you run into any issues. Thanks!

Comment 15

[ovidiu boca[:Ovidiu]]

Attachment: output.txt

Thanks for your guidance, it was really helpful. Please see the output.txt attached file.

Comment 16

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

Thanks, this is the output I wanted. I'll need to spend some time looking through it and figuring out what's going on.

Comment 17

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

I took a look at the log, and it does provide some useful information. It looks like the PanGesture events after the page transition get put into the same wheel transaction that was going on before the page transition. Also relevant is that the APZC target for this wheel transaction is 0x0, so the events are effectively ignored. Moving the mouse or waiting a while will end the transaction and start a new one which makes the scrolling work properly.

I would like a bit more info as to why the APZ is coming out 0x0, just to satisfy my curiousity. I don't think that will actually matter much in terms of the fix. I have created a patch with more logging but tryserver has been closed all day so I haven't been able to get a build with that patch. I'll post it here once I have it.

Comment 18

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

Ovidiu, can you do the same thing, using the build at https://treeherder.mozilla.org/#/jobs?repo=try&revision=36e3f5932d5d&selectedJob=23188966 - this one adds a bit more logging so hopefully I can narrow down the problem a bit more. Thanks!

Comment 19

[ovidiu boca[:Ovidiu]]

Attachment: output.txt 2016-07-05.txt

Here is the output. I used the build that you send it. Please tell me if it's ok, or I need to do something else.

Comment 20

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

Ovidiu, I was looking through this log and the sequence of events that I see being generated doesn't look like there is any horizontal swiping going on. Can you describe what sequence of actions you took when generating this log? (If you don't remember, you can create a new log using the same build, and please record what actions you did - how many scrolls and swipes and in what direction). Thanks!

Comment 21

[ovidiu boca[:Ovidiu]]

Attachment: output2016-07-07.txt

Hi,

I added thee new output.txt document. 
I installed and open the FF from the build that you provided. I did a search in google after "s" and open the firs result. In the time when the page was loading I was moving up and down (vertical move) 2 fingers on track pad. I did 7 moves up and down and then stopped and take the fingers from the trackpad for 1 sec and then when I started the same move everything works as expected. I did a second attempt, here I did 5 moves up and down.   


how many scrolls and swipes and in what direction

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Ovidiu, can you still reproduce this?

Comment 23

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

The next action here is for me to look at the log provided in comment 21.

Comment 24

[ovidiu boca[:Ovidiu]]

FYI I can reproduce it on Nightly 51.0a1 (2016-09-12).

Comment 25

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

I looked through the log. The first interesting thing I noticed was that if you look at the APZCCH output, there's no target APZC output stuff for block 3. It goes straight from processing block 2 to "Not resending target APZC confirmation for input block 3", and then eventually the input queue hits the main-thread timeout for block 3 before processing those events with target 0x1220c4800. It's quite likely that we're bouncing out of the presShell/rootFrame checks at [1], but sLastTargetAPZCNotificationInputBlock has already been updated - so the APZCCH never ends up sending a target APZC for that input block. Moving the line that sets sLastTargetAPZCNotificationInputBlock to inside the if conditions might help with that, if the presShell shows up a bit late.

I'll look through the log some more to see if I can spot anything else.

[1] http://searchfox.org/mozilla-central/rev/bcc9ea6947878ca6378e5b7d6f08c1c090ed9eb7/gfx/layers/apz/util/APZCCallbackHelper.cpp#763

Comment 26

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

Another interesting bit is how block 7 ends up with a null target. The APZCCH does appear to compute *some* target and sends over a guid, but then the InputQueue doesn't have a target APZC when it receives the message. This seems to indicate that the target guid is sent over to the compositor before the compositor has built an APZC for that guid, which means the "SendLayersDependentApzcTargetConfirmation" codepath isn't doing it's job. This log predates the GPU process work so it's not a regression from that either.

So those are the two anomalies I see in the log. I can write a patch for the thing in comment 25, but will have to stare the code some more or add more logging to figure out why SendLayersDependentApzcTargetConfirmation isn't working properly.

Comment 27

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

I've pushed a try build [1] which includes a patch for the issue in comment 25, and additional logging to confirm the issue in comment 26. Ovidiu, when this build is done, can you please try it to see if it resolves the problem. Also it should generate a log like the previous try build, please attach it to this bug. Thanks!

[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=040f4b00be48

Comment 28

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

whoops, forgot to needinfo ^

Comment 29

[ovidiu boca[:Ovidiu]]

Attachment: output from the try build comment 27.txt

I retested with your build from comment 27 and I'm still able to reproduce it. I also attached the output.

Comment 30

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

Thanks. It does indeed look like the SendLayersDependentApzcTargetConfirmation codepath is not working as intended, I see the APZC 0x12560d000 with v=5, which is the target for block 4, is created at some point after the SetTargetAPZC notification is received.

I'll dig into why this is happening. It might also explain some intermittent failures in the APZ mochitests.

Comment 31

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

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #30)
> Thanks. It does indeed look like the
> SendLayersDependentApzcTargetConfirmation codepath is not working as
> intended

I tried to force this to happen in a local setup using sleep calls in the right places but wasn't able to. So I think this is more of an edge case where we get the DidRefresh() notification without the layers transaction having completed. This can happen for a number of reasons, so I tried to make a patch that is more robust against this.

Ovidiu, one more build at https://treeherder.mozilla.org/#/jobs?repo=try&revision=38ff3581e021 that I'd like you to try, same as before - please check if it fixes the problem and provide the output log. If you don't get to it today that's fine, there's no big rush here. Have a good vacation!

Comment 32

[ovidiu boca[:Ovidiu]]

Attachment: output for build comment 31.txt

I retested this with the build provided in comment 31 and I still can reproduce it. Please see the attached output log. Thanks for the wishes.

Comment 33

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

I took a look at the log, it looks like I'm on the right track but there's more to it. In particular, it looks like we do the refresh on the main-thread long before the layers update reaches the compositor, and when it does, it has a first-paint flag on it. That seems to indicate that the main thread switches to a different document a long time before the compositor starts displaying that document (maybe because of paint suppression or something similar), and during that time we can't scroll unlayerized content in the new document. However that explanation is not entirely satisfying to me either because then the user should be seeing the old document on the screen and not the new one. I'll need to add more logging I think.

Comment 34

[Randell Jesup [:jesup] (needinfo me)]

kats - can you update this?  This has been happening/broken for a long time.... unless it got fixed in the meantime.

Comment 35

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

It probably hasn't gotten fixed, at least not as far as I know. The cost/benefit of fixing this bug is not great so I haven't been spending a lot of time on it (also why I marked it P5). I'll come back to it when I have more cycles, but marking it fix-optional for now so it doesn't keep coming up on the radar.

Comment 36

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

Not actively working on this