User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.2 Safari/605.1.15

Steps to reproduce:

1. Enable apz.allow_zooming in about:config.
2. Use the touchpad pinch gesture to zoom in on any webpage.
3. Try to scroll the page left or right using the touchpad two-finger gesture.

Actual results:

Firefox goes forward or back in history.

Expected results:

Page should scroll left or right until the edge of the page is reached. At that point, further use of the two-finger left/right gesture should trigger the forward/back action.

Looks like this is caused by this line

https://searchfox.org/mozilla-central/rev/0678172d5b5c681061b904c776b668489e3355b0/dom/ipc/BrowserChild.cpp#1838

That will trigger a call to nsChildView::ReportSwipeStarted with aStartSwipe == true.

WidgetWheelEvent::TriggersSwipe returns true because mViewPortIsOverscrolled and mOverflowDeltaX were set in EventStateManager::PostHandleEvent here

https://searchfox.org/mozilla-central/rev/0678172d5b5c681061b904c776b668489e3355b0/dom/events/EventStateManager.cpp#3558

It just looks at the scrollframe (and layout doesn't think it can scroll) and doesn't know about anything apz (who knows that it can scroll because it has been zoomed).

How should this work?

(In reply to Timothy Nikkel (:tnikkel) from comment #1)

WidgetWheelEvent::TriggersSwipe returns true because mViewPortIsOverscrolled and mOverflowDeltaX were set in EventStateManager::PostHandleEvent here

https://searchfox.org/mozilla-central/rev/0678172d5b5c681061b904c776b668489e3355b0/dom/events/EventStateManager.cpp#3558

It just looks at the scrollframe (and layout doesn't think it can scroll) and doesn't know about anything apz (who knows that it can scroll because it has been zoomed).

How should this work?

The main thread does have information about the position and size visual viewport (PresShell::GetVisualViewportOffset(), PresShell::GetVisualViewportSize()). Perhaps the logic that computes mViewPortIsOverscrolled (ultimately looks like WheelHandlingUtils::CanScrollOn()) could check those? We may need to look at what other call sites use that and introduce flags as appropriate.

I think it would be a good idea to make it so that the main thread logic is only engaged in the cases where the APZ side isn't sure whether to swipe or not. In the case where APZ knows it will scroll and not swipe, maybe we should be setting mCanTriggerSwipe to false on the Gecko event.
The only cases where the main thread needs to be consulted in order to know whether to swipe are:

• Wheel event listeners: If scrolling against the edge, but the wheel event is preventDefaulted, then no swipe should happen.
• Inactive scroll frames, maybe? If an inactive scroll frame is not at the end of the scroll range in the scrolled direction, the main thread needs to activate the scroll frame before APZ can know whether to swipe. I'm not sure how this case works.

https://hg.mozilla.org/mozilla-central/rev/bf8c6a53bbe5

There still seems to be some websites where the bugged behavior still happens. I've checked on multiple websites, and zooming in while using gmail.com or old.reddit.com mistakes scrolling left while zoomed in for going back to the previous webpage.

I apologize, it looks like old.reddit.com is the website that's working, but it's the current reddit website that has the old buggy behavior. More specifically, when you navigate to the comments of a post, and you zoom it and try to scroll to the left or right, you go back and forward in your webpage history respectively.

Thanks for testing and reporting. Looks like pages are encountering a different problem, so I filed bug 1601185 to fix.

I've reproduced this issue with Fx 72.0a1(2019-10-27) on macOS 10.15 by following the provided steps.
The issue is verified fixed with Fx 74.0a1(2020-01-30) and Fx 73.0b11 on macOS 10.14 and macOS 10.15.