1884144 - Fails to load more products when scrolling down the search results page on taobao.com

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P1)

Description

[Calin Tanase (OOO until 22nd of Nov)]

Attachment: search results FF vs Chrome.mp4

Environment:
Operating system: OnePlus 6 A6000 (Android 11)
Firefox version: Nightly 125.0a1-20240306095835

Precondition: must be logged in

Steps to reproduce:

1. Go to https://main.m.taobao.com
2. Tap on the search bar.
3. Tap again on the search bar when redirected.
4. Search for a product (e.g. shoe).
5. Scroll down the page.

Expected Behaviour:
More products get displayed when scrolling down.

Actual Behaviour:
No more products get displayed when scroll down.

Notes:

1. Screen rec attached
2. Reproducible on Firefox Release as well
3. Reproducible regardless of the ETP status
4. Not reproducible on Chrome
5. Does not reproduce with every product or everytime (however when searching for "shoe" I was able to reproduce every time)
6. Issue found during WebCompat team [Top100] websites testing

Comment 1

[Ksenia Berezina [:ksenia]]

This could be related to bug1847924

Comment 2

[Daniel Holbert [:dholbert]]

Calin: if we have an existing account to use for testing on Taobao, would you be willing to email me the login credentials? (dholbert at mozilla dot com)

(Alternately I could create my own one, but if there's an existing one I can use without bloating Taobao with yet-another test account, that'd be all-the-better.)

Thanks!

Comment 3

[Calin Tanase (OOO until 22nd of Nov)]

I could share the credentials but unfortunately the login requires OTP which is sent to one of our work phone numbers.

Comment 4

[Daniel Holbert [:dholbert]]

Thanks. Let's coordinate to do that next week sometime, if that works. I want to see if I can diagnose this, which means I need to sign in to some account; I briefly looked to see what it would take to set up my own account, but I don't have a cell phone number that I'd be comfortable sharing with Taobao (which seems to be a required part of their account setup process). (I don't have a work cell phone, and I'm not comfortable giving them my personal cell number.)

Comment 5

[Daniel Holbert [:dholbert]]

Calin helped me get signed in, and I'm testing this right now.

I can reproduce the issue in Firefox Nightly 129 on my Pixel 6a phone (Android 15 beta). The infinite-scroll just never gets triggered; I can scroll to the bottom of the content and then nothing autopopulates or fills in.

I cannot reproduce the issue in Chrome on the same device, and I can't reproduce the bug in Firefox on Desktop in RDM.

One key observation: If I turn off the dynamic scrollbar (i.e. force the Firefox toolbar to stay visible), then the bug goes away. So this has something to do with the dynamic toolbar and how it impacts the viewport size (which in turn impacts how Taobao is determining whether you've scrolled to the end of the document.)

Comment 6

[Daniel Holbert [:dholbert]]

Looking at the page DOM, they have a zero-height element at the very bottom of the page like this:

<div class="rax-view-v2 ItemList--loadingPic--1poe9FD"><!----></div>

That element has no contents and has a height of 0.

When things are working as-expected, the page somehow notices when you reach the bottom and puts an img into that element with the throbber image (and then populates additional tiles).

When things aren't working as-expected, that never happens; that element remains blank.

The "things working as expected" img-insertion seems to chain up to an IntersectionObserver callback for some of the other elements in the page, though the JS Debugger seems to have lost some of the information about specifically which element is the target of that IntersectionObserver callback.

It seems like the relevant JS for the IntersectionObserver callback here is:
https://g.alicdn.com/??mtb/lib-promise/3.1.3/polyfillB.js,ali-lib/appear-polyfill/0.1.2/index.js,mtb/lib-windvane/3.0.7/windvane.js,mtb/lib-login/2.2.0/login.js

...specifically this bit (which is the IntersectionObserver callback):

    function p(t) {
        t.forEach(function(t) {
            var n = t.target
              , i = t.boundingClientRect
              , e = t.intersectionRatio
              , t = i.y || i.top
              , i = parseInt(n.getAttribute("data-before-current-y")) || t;
            .01 < e && !m(n.getAttribute("data-appeared")) && !v(n, "appear") ? (n.setAttribute("data-appeared", "true"),
            n.setAttribute("data-has-appeared", "true"),
            n.dispatchEvent(w("appear", {
                direction: i < t ? "up" : "down"
            }))) : 0 === e && m(n.getAttribute("data-appeared")) && !v(n, "disappear") && (n.setAttribute("data-appeared", "false"),
            n.setAttribute("data-has-disappeared", "true"),
            n.dispatchEvent(w("disappear", {
                direction: i < t ? "up" : "down"
            }))),
            n.setAttribute("data-before-current-y", t)
        })

It looks like this function checks whether the intersectionRatio is nonzero (greater than .01) and if so, for elements that lack the data-appeared attribute (i.e. are being shown for the first time), we call n.dispatchEvent( to fire some sort of appear event. That seems to be what triggers the img loading throbber to show up (through a complex long callstack).

So presumably there's some weird edge case where an element at the extreme bottom of the page is just out of reach (and can't be scrolled to, or at least can't attain a intersectionRatio greater than .01), due to the dynamic toolbar causing some sort of funkiness with viewport sizing.

Comment 7

[Daniel Holbert [:dholbert]]

I came up with a reduced testcase that behaves the same as Taobao does here, and I think it's the root cause of this bug (though it's hard to be sure, since the JS is pretty minified/obfuscated). I've filed that as bug 1905441.

Comment 8

[Daniel Holbert [:dholbert]]

Er, I guess my new bug is a known issue, filed as platform bug 1788504 & WebCompat KB bug 1886147. Looks like hiro's got some recent work there (e.g. bug 1788504 comment 27) so hopefully this will be fixed soon!

Comment 9

[Daniel Holbert [:dholbert]]

Calin, would you mind retesting in a Firefox Nightly build with about:config setting layout.scroll.disable-pixel-alignment=true?

Based on observations in the bug that I spun off for the reduced testcase (bug 1905441), that should probably fix the issue (and it would help to have confirmation of that for the actual site here).

Thanks!

Comment 10

[Calin Tanase (OOO until 22nd of Nov)]

Attachment: Release vs Nightly.mp4

I wanted to test again without the mentioned pref and it seems it no longer reproduces on Nightly with a clean profile, can't say the same for the Release version.

So in conclusion it works with layout.scroll.disable-pixel-alignment set to false on Nightly. I've tested multiple times to make sure its not a 1 time thing.

Operating System: OnePlus 6 A6000 (Android 11)
Browser / Version: Nightly 130.0a1-20240729094831 (Build #2016035383) / Release 128.0.3-20240725162350

Comment 11

[Daniel Holbert [:dholbert]]

Aha, that's great news! Thanks.

Probably this was fixed by bug 1788504, then! (The bug that I spun off with a reduced testcase -- bug 1905441 -- requires a bit more work beyond bug 1788504 to fix, but maybe the actual site here doesn't have quite as strict requirements.)

--> resolving as WFM, presumably having been fixed by bug 1788504.