1878247 - Pull-to-refresh is not always triggered on reddit.com

Status: NEW

(Fenix :: General, defect)

Description

[miralobontiu]

Attachment: pull to refresh - reddit_Trim.mp4

Steps to reproduce

1. Make sure you have the Pull to refresh toggle enabled in Settings - Customize.
2. Go to reddit.com, and pull the page down from the top of the page, to trigger the pull to refresh feature.
3. Repeat step 2 several times.

Expected behavior

The pull-to-refresh animation is triggered, along with a page refresh.

Actual behavior

The first time, the pull to refresh works as expected. If you pull down the page again, nothing happens. Only after several attempts, the feature is working again - please see the attached video.

Device information

• Firefox version: only on Nightly 124.0a1
• Android devices: Google Pixel 6 (Android 14), Samsung Galaxy A14 (Android 13), Lenovo tablet M10 (Android 10)

Any additional information?

• Not reproducible on RC 122.0.1, nor on Beta 123.0b5

Comment 1

[Mark]

Possible duplicate of bug 1873873?

Comment 2

[Titouan Thibaud [:titouan]]

I can reproduce it quite easily, and what I see is that every time the bug happens the page slightly scrolls up. Basically Gecko considers that we're not at the top of the page (it's probably a matter of 1px) and then doesn't trigger PTR.

The API we use doesn't give us the distance from the top, we only know if we are already at the top of the page or not.

So I'm not sure what to do from here. @botond Do have any idea?

Comment 3

[Botond Ballo [:botond]]

If the page ends up with a scroll position that's some sub-pixel amount away from the top (without any user action to scroll away from the top), that could be an issue in the family of bug 1774315 and its related bugs. That's something we hope to tackle with the help of the graphics team this year.

In the meantime, a workaround we could consider might be to add a small tolerance to how Gecko sets the canOverscrollTop etc. values, so it still returns true in this situation.

If, by contrast, we end up scrolled some larger amount away from the top (e.g. several pixels), we should look more closely into how that happens.

Comment 4

[Titouan Thibaud [:titouan]]

Thanks for your answer!
I think the workaround you propose might work.

Do you know what would be a good way to confirm that the problem is related to a small enough amount of pixels?

Comment 5

[Botond Ballo [:botond]]

(In reply to Titouan Thibaud [:tthibaud] from comment #4)

Do you know what would be a good way to confirm that the problem is related to a small enough amount of pixels?

I think some Gecko logs with the apz.controller:5 log module enabled taken while reproducing the issue should allow us to confirm this.

Comment 6

[Botond Ballo [:botond]]

Adding to APZ diagnosis backlog for the remaining diagnostics steps outlined in comments 3-5.

Comment 7

[Hiroyuki Ikezoe (:hiro)]

Tituouan, would you mind trying to see whether this bug persists with setting a preference value named layout.scroll.disable-pixel-alignment to true?

On my pixel 3, this bug can happen without setting the pref value, I would say the bug can not happen with setting it.

Comment 8

[Titouan Thibaud [:titouan]]

Hey Hiro,
I can still reproduce it with layout.scroll.disable-pixel-alignment set to true, on a Pixel 7, Android 14.

Comment 9

[Hiroyuki Ikezoe (:hiro)]

Thanks, that's unfortunate. :/

Comment 10

[Hiroyuki Ikezoe (:hiro)]

I now guess that this is somewhat related to bug 1897345, and unlike bug 1895742 this bug isn't fixed by bug 1897567. That's because in this bug case INPUT_RESULT_IGNORED happens on ACTION_DOWN.

The scenario is;

1. Fall into this if (mQueuedInputs.IsEmpty() && aEvent.mTouches.Length() == 1 && ... branch
2. The block is marked as a fast fling
3. SetStatusForFastFling gets called
4. Thus the status becomes nsEventStatus_eConsumeNoDefault
5. And mHandledResult is never set for the block

Comment 11

[Hiroyuki Ikezoe (:hiro)]

The analysis in comment 10 is wrong. I did it on my Linux box with RDM, which means the branch at 1 never happens on Android since there's no FLING state on Android, it's Linux specific.

So I did diagnose again on Android with some debug logs in NestedGeckoView.kt (also with layout.scroll.disable-pixel-alignment=true).

From what I can tell is even after we properly call parent?.requestDisallowInterceptTouchEvent(false) in NestedGeckoView.kt, sometimes pull-to-refresh doesn't happen.

That means it's unlikely an issue in Gecko. (I guess it somehow causes unexpected states in SwipeRefreshLayout. Moving to Fenix:Genaral.