1175564 - APZC: vertical scrolling has no momentum or is blocked (horizontal scroll works properly)

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect)

Description

[Paul Rouget [:paul]]

On OSX, with B2G desktop, with APZC enabled, scrolling in an iframe behaves in one of these ways:
1) scroll properly, with momentum (doesn't happen often)
2) scroll, but there's no momentum (happens often)
3) doesn't scroll (happens often, but not as much as 2)

Scrolling horizontally works properly (smooth with momentum).

When 3) happens, I get this warning in the terminal (many of them):

> 0xXXXXXXX replacing unconfirmed target 0xYYYYYYYY with real target 0x0

This happens with pages as simple as a big image:

> <iframe mozbrowser=true remote=true src=http://i.imgur.com/HHBRUKO.png>

Any idea how I can debug that?

Comment 1

[Paul Rouget [:paul]]

Attachment: screencast

Behavior 2) is really what happens most of the time. See attachment.

Comment 2

[Paul Rouget [:paul]]

David, any idea what is going on?

Comment 3

[Benoit Girard (:BenWa)]

I'm going to move this to Panning and Zooming but it might be cocoa/e10s style issue. FWIW I notice the same thing using the trackpad with e10s so it might be the same issue as e10s but I don't know for sure.

Comment 4

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

Loading this page in OS X desktop with APZ enabled works fine:

 data:text/html,<iframe mozbrowser=true remote=true src=http://i.imgur.com/HHBRUKO.png>

Unless this affects OS X desktop or B2G on a device it's not going to be very high priority, sorry.

Comment 5

[Paul Rouget [:paul]]

Any pointer? Anything that I could try to log/enable/disable that would help me understand what's going on?

The fact it works for horizontal scrolling but not for vertical scrolling might help understand what could go wrong.

Comment 6

[Paul Rouget [:paul]]

It only happens if the page can scroll horizontally.

If the page is not larger (width) than the viewport, scrolling works as expected.

Comment 7

[Paul Rouget [:paul]]

Scrolling in a larger-than-viewport iframe triggers crash after a while:

[Child 25943] ###!!! ABORT: ActorDestroy by IPC channel failure at LayerTransactionChild: file /Users/paul/mozilla/src/gfx/layers/ipc/LayerTransactionChild.cpp, line 121
#01: mozilla::ipc::ProcessLink::OnChannelError()[/Users/paul/mozilla/src/obj.debug.noindex/dist/B2GDebug.app/Contents/MacOS/XUL +0x49fc28]
#01: mozilla::layers::PCompositorChild::DestroySubtree(mozilla::ipc::IProtocolManager<mozilla::ipc::IProtocol>::ActorDestroyReason)[/Users/paul/mozilla/src/obj.debug.noindex/dist/B2GDebug.app/Contents/MacOS/XUL +0x79d318]
#02: IPC::Channel::ChannelImpl::OnFileCanReadWithoutBlocking(int)[/Users/paul/mozilla/src/obj.debug.noindex/dist/B2GDebug.app/Contents/MacOS/XUL +0x47e019]
#02: mozilla::layers::PCompositorChild::OnChannelError()[/Users/paul/mozilla/src/obj.debug.noindex/dist/B2GDebug.app/Contents/MacOS/XUL +0x79d613]
#03: event_base_loop[/Users/paul/mozilla/src/obj.debug.noindex/dist/B2GDebug.app/Contents/MacOS/XUL +0x4600df]
#03: mozilla::ipc::MessageChannel::NotifyMaybeChannelError()[/Users/paul/mozilla/src/obj.debug.noindex/dist/B2GDebug.app/Contents/MacOS/XUL +0x49def7]
#04: base::MessagePumpLibevent::Run(base::MessagePump::Delegate*)[/Users/paul/mozilla/src/obj.debug.noindex/dist/B2GDebug.app/Contents/MacOS/XUL +0x46c685]
#04: MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&)[/Users/paul/mozilla/src/obj.debug.noindex/dist/B2GDebug.app/Contents/MacOS/XUL +0x46b1bd]
#05: MessageLoop::Run()[/Users/paul/mozilla/src/obj.debug.noindex/dist/B2GDebug.app/Contents/MacOS/XUL +0x46a85c]
#05: MessageLoop::DoWork()[/Users/paul/mozilla/src/obj.debug.noindex/dist/B2GDebug.app/Contents/MacOS/XUL +0x46b4fb]
#06: base::Thread::ThreadMain()[/Users/paul/mozilla/src/obj.debug.noindex/dist/B2GDebug.app/Contents/MacOS/XUL +0x47565d]
#06: mozilla::ipc::DoWorkRunnable::Run()[/Users/paul/mozilla/src/obj.debug.noindex/dist/B2GDebug.app/Contents/MacOS/XUL +0x4a07c5]
#07: ThreadFunc(void*)[/Users/paul/mozilla/src/obj.debug.noindex/dist/B2GDebug.app/Contents/MacOS/XUL +0x47576a]
#07: nsThread::ProcessNextEvent(bool, bool*)[/Users/paul/mozilla/src/obj.debug.noindex/dist/B2GDebug.app/Contents/MacOS/XUL +0xe1c55]
#08: _pthread_body[/usr/lib/system/libsystem_pthread.dylib +0x3268]
#08: NS_ProcessPendingEvents(nsIThread*, unsigned int)[/Users/paul/mozilla/src/obj.debug.noindex/dist/B2GDebug.app/Contents/MacOS/XUL +0x11aa1f]
#09: _pthread_body[/usr/lib/system/libsystem_pthread.dylib +0x31e5]
[Child 25943] ###!!! ABORT: Aborting on channel error.: file /Users/paul/mozilla/src/ipc/glue/MessageChannel.cpp, line 1662
Hit MOZ_CRASH() at /Users/paul/mozilla/src/memory/mozalloc/mozalloc_abort.cpp:33

Comment 8

[Paul Rouget [:paul]]

Crash is most likely related to bug 1161166.

Comment 9

[Paul Rouget [:paul]]

We must do something in the wheel code to cancel out tiny horizontal movements when doing "big" vertical movement to have a perfectly straight scrolling. The lack of momentum happens when the horizontal movement is very tiny, when the cancelling happen. When there's enough horizontal movement, momentum works (and scrolling is not exactly straight).

Comment 10

[Paul Rouget [:paul]]

I'm wrong. I don't see any horizontal scrolling happening. Momentum happens on horizontal and diagonal scrolling. If vertical movement is much larger than horizontal movement, then momentum doesn't happen.

Comment 11

[Paul Rouget [:paul]]

Note: the apzctreemanager gets the momentum events.

Comment 12

[Paul Rouget [:paul]]

Scrolling stop because we end up here:

http://hg.mozilla.org/mozilla-central/file/2694ff2ace6a/gfx/layers/apz/src/AsyncPanZoomController.cpp#l1515

Comment 13

[Paul Rouget [:paul]]

Note: mY.CanScroll(aDelta.y) returns false. It I force it to return true, momentum works as expected.

Comment 14

[Paul Rouget [:paul]]

mY->mAxisLocked is true.

Comment 15

[Paul Rouget [:paul]]

Commenting this line:

http://hg.mozilla.org/mozilla-central/file/2694ff2ace6a/gfx/layers/apz/src/AsyncPanZoomController.cpp#l1934

Fixes the momentum issue.
What is cross_slide?

Comment 16

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

Cross-slide is a gesture in windows [1] that we added APZ support for, when the metro browser was still a thing. We can remove cross-slide support although I'm not convinced doing that will fix this problem. If you are hitting the line 1934 as in your previous comment that means the scroll delta is almost completely horizontal. Can you log the steam of scroll deltas coming into the wheel events (which get translated to touch events) and check that they reflect your finger movements on the trackpad?

And thanks for digging through the code!

[1] https://msdn.microsoft.com/en-us/library/windows/apps/hh465299.aspx

Comment 17

[Paul Rouget [:paul]]

Attachment: v1

So the issue is that when momentum scrolling starts, and new pan is started. It starts with a displacement of x:0,y:0. When the angle of the pan is calculated, we end up with and angle of 0 (which make no sense), which is considered as close to horizontal panning, locking the y axis.

In HandlePanning, `IsCloseToHorizontal(aAngle, gfxPrefs::APZAxisLockAngle())` is true because angle is 0.

I hope that makes sense :)

Comment 18

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

Ah, nice find! That does seem like a bug. I think the more correct solution would be to land the patch in bug 1156606 but apparently that caused tests to fail and needs some work. In the meantime I think your patch should be fine, since OnPanBegin is only ever called from the instant-scroll wheel handler now. On OSX we might get pan-gesture events, but only if layers.async-pan-zoom.separate-event-thread is set to true, which is not the default case. And even then I don't think this patch would break anything there.

Comment 19

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

Comment on attachment 8624699 [details] [diff] [review]
v1

Review of attachment 8624699 [details] [diff] [review]:
-----------------------------------------------------------------

s/block/lock/ in the commit message. rest looks good.

Comment 20

[Paul Rouget [:paul]]

Attachment: v1 (r=kats)

Comment 21

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

Also for the record the reason this doesn't happen on OS X desktop is because GetAxisLockMode() == FREE on desktop but B2G desktop picks up b2g prefs which include axis locking.

Comment 22

[Paul Rouget [:paul]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=aff6763cc446

Comment 23

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/738e3dcf5eed

Comment 24

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/738e3dcf5eed