Open Bug 1946375 Opened 17 days ago Updated 4 days ago

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

Categories

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

Product:
Web Compatibility
Component:
Site Reports
Platform:
Desktop
Windows 10
Type:
defect

Tracking

(Webcompat Score:7, Webcompat Priority:P2, firefox-esr115 wontfix, firefox-esr128 affected, firefox135 wontfix, firefox136 fix-optional, firefox137 affected)

Status:
ASSIGNED
Project Flags:
Webcompat Score 7
Webcompat Priority P2
Tracking Flags:
Tracking Status
firefox-esr115 --- wontfix
firefox-esr128 --- affected
firefox135 --- wontfix
firefox136 --- fix-optional
firefox137 --- affected

People

(Reporter: ctanase, Assigned: hiro)

References

(Regression,
URL
)

Details

(Keywords: regression, webcompat:site-report, Whiteboard: [webcompat-source:web-bugs][webcompat:sightline])

User Story

platform:windows,mac,linux,android
impact:content-missing
configuration:general
affects:all
branch:release
diagnosis-team:layout
user-impact-score:600

Attachments

(2 files)

flipkart FF vs Chrome.mp4
1.80 MB, video/mp4
Details
Bug 1946375 - Update scroll snap target ids when re-using an AsyncSmoothMSDScroll or an AsyncScroll instance. r?botond
48 bytes, text/x-phabricator-request
Details | Review

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

status-firefox135: --- → affected
status-firefox137: --- → affected

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

status-firefox136: --- → affected
Whiteboard: [webcompat-source:web-bugs] → [webcompat-source:web-bugs][webcompat:sightline]

: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.

Flags: needinfo?(hikezoe.birchill)

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

Flags: needinfo?(hikezoe.birchill)
Flags: needinfo?(hikezoe.birchill)
Severity: -- → S2
User Story: (updated)
Webcompat Priority: --- → P2
Webcompat Score: --- → 7
Keywords: webcompat:needs-diagnosis
Priority: -- → P1

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.

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.

Assignee: nobody → hikezoe.birchill
Status: NEW → ASSIGNED
Flags: needinfo?(hikezoe.birchill)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: