1946375 - www.flipkart.com - Slideshow gallery does not work correctly, only the first 2 slides are displayed

Status: VERIFIED FIXED

(Core :: Layout: Scrolling and Overflow, defect, P1)

Description

[Calin Tanase]

Environment:
Operating system: Windows 10
Firefox version: Firefox 134.0/135/137

Steps to reproduce:

1. Go to https://www.flipkart.com/
2. Try watching the slides on the slideshow gallery (below the header), click on the next arrow ">" to navigate the gallery.

Expected Behavior:
All the slides can be accessed.

Actual Behavior:
When trying to see the 3rd slide, it will return to the first one.

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/147762

Comment 1

[Calin Tanase]

Attachment: flipkart FF vs Chrome.mp4

Comment 2

[BugBot [:suhaib / :marco]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 3

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=307dd529e2a3dc6f6191a40d35c1c9e9fd94f727&tochange=1f99e4a5113539ba2b85689d04f66fd0261db0a8

Comment 4

[BugBot [:suhaib / :marco]]

:hiro, since you are the author of the regressor, bug 1530253, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 5

[Hiroyuki Ikezoe (:hiro)]

I haven't looked though, it may be a case of this spec resolution (bug 1942692).

Comment 6

[Hiroyuki Ikezoe (:hiro)]

I am still in the middle of diagnosis, but one of the culprits is the indicator which is positioned below the slideshow. It's animated by changing styles (width?), and it causes reflows of the scroll container, and the reflow of the scroll container re-evaluate snap position.

I guess on Chrome the style change on the indicator doesn't reflow the scroll container.

Comment 7

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1946375 - Update scroll snap target ids when re-using an AsyncSmoothMSDScroll or an AsyncScroll instance. r?botond

In the case of overflow:hidden scroll container, async scroll
operations are handled on the main-thread. And the scroll snap target ids
are also maintained on the main-thread either by mAsyncSmoothMSDScroll
or mAsyncScroll. But when re-using an existing mAsyncSmoothMSDScroll
instance (or mAsyncScroll), the first scroll snap target ids had persisted
in the instance, that resulted unexpected re-snapping.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/09d2be57064f
Update scroll snap target ids when re-using an AsyncSmoothMSDScroll or an AsyncScroll instance. r=dlrobertson

Comment 9

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/51418 for changes under testing/web-platform/tests

Comment 10

[amarc]

https://hg.mozilla.org/mozilla-central/rev/09d2be57064f

Comment 11

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 12

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:hiro, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox137 to wontfix.

For more information, please visit BugBot documentation.

Comment 13

[Raul Bucata]

This still reproduces using the RC Build

Tested with:

Browser / Version: Firefox 137.0-candidate build 1
Operating System: Windows 10 PRO x64

Comment 14

[Daniel Holbert [:dholbert]]

(In reply to Raul Bucata from comment #13)

This still reproduces using the RC Build
Browser / Version: Firefox 137.0-candidate build 1

It looks like this didn't get uplifted to 137, so I think that's expected.

Could you test 138 and confirm whether that's fixed there?

Comment 15

[Daniel Holbert [:dholbert]]

(It looks like we've still got an open question on whether it's worth uplifting this -- hiro, did you have a leaning there? Without knowing much of the details, my assumption is that we should just let this ride the trains as part of v138 at this point (and not uplift), since 137 gets released in less than a week, and since we've been living with this bug for years so there's presumably no pressing need to get a fix out to release users in 1 week vs. ~5 weeks.)

Comment 16

[Daniel Holbert [:dholbert]]

(I'm also reclassifying to Layout:Scrolling-and-Overflow since we had a platform change land directly on this bug, and I think that's the webcompat team's recommended process for cases where we do that -- with webcompat:platform-bug and webcompat:site-report keywords to keep it properly tracked as being a site-report-caused-by-a-platform-bug. And reverting the keyword/reopening from comment 13 since per comment 14 I think that was just a misunderstanding about which version had the fix.)

Comment 17

[Hiroyuki Ikezoe (:hiro)]

Thanks Daniel. I has somehow missed the need-info here. I'd let this change ride on the train.

Comment 18

[Raul Bucata]

The latest Nightly 138 seems to work as expected.

Comment 19

[Raul Bucata]

Verified as FIXED using the RC Build

Tested with:

Browser / Version: Firefox 138.0-candidate build 1
Operating System: Windows 10 PRO x64