msn.com - The images carousel pagination is misplaced when navigating through pictures
Categories
(Web Compatibility :: Site Reports, defect, P2)
Tracking
(firefox128 affected, firefox130 affected)
People
(Reporter: rbucata, Unassigned)
References
(Depends on 1 open bug, )
Details
(Keywords: webcompat:platform-bug, webcompat:site-report)
User Story
platform:android impact:significant-visual configuration:general affects:all branch:release diagnosis-team:layout
Attachments
(1 file, 1 obsolete file)
|
713.76 KB,
image/png
|
Details |
Screenshot_9.png
Environment:
Operating system: Android 12/ Android 13
Firefox version: Firefox Nightly 130.0a1 (2016035631-🦎130.0a1-20240730164742🦎)
Preconditions:
Clean profile
Steps to reproduce:
- Navigate to: https://www.msn.com/en-xl/health/other/the-things-we-re-glad-stayed-in-the-early-2000s/ss-AA1msnZ9?ocid=hpmsn&cvid=1828090ac34840b0a37682b55f0b653f&ei=93
- Swipe right to navigate the images carousel
- Observe the upper right corner of the carousel
Expected Behavior:
The carousel pagination is present
Actual Behavior:
The carousel pagination is misplaced
Notes:
- Reproducible regardless of the status of ETP
- Reproducible on the latest build of Firefox Nightly and Release
- Works as expected using Chrome
- Attachment provided
- Issue found during WebCompat team [Top100] websites testing
|
Reporter | |
Updated•2 months ago
|
|
|
Reporter | |
Updated•2 months ago
|
|
|
Reporter | |
Comment 1•2 months ago
|
||
|
||
Updated•2 months ago
|
|
||
Comment 2•4 days ago
•
|
||
This reproduces in responsive design mode, which makes it a bit easier to investigate (though one "gotcha" -- if you're swiping through the carousel with mouse-click-and-drag in RDM, you have to be sure to release your mouse button before you move your mouse off the edge of the virtual phone, or else the content gets confused about whether/where your swipe ended).
So for me at least, this 3/30 (etc.) slide-counter doesn't even show up at all until I swipe the carousel far enough to reach the first ad (slide 5 or so) -- at which point this widget appears at the spot shown in the screenshot, and says Skip Ad. (This might be due to an invalidation bug of some sort? not sure.)
At that point, if I inspect it using devtools, I can see that it's an absolutely positioned element -- <div class="control-container"> -- and it's inside of a custom element <mobile-gallery-slideshow> which has :host { position: relative; } applied to it. That relative-positioned ancestor should be serving as an abspos containing block for the abspos slide-counter; but it's failing to do so for some reason.
If I manually add display:block to <mobile-gallery-slideshow>, then the slide-counter snaps to the expected position (and nothing else changes). So I think some of this is from some sort of bug with inline elements serving as abspos containing blocks. (Also: after I've added display:block to fix the layout: if I then revert that change, then the slide-counter doesn't just jump to the bad spot -- it entirely disappears again, until I swipe through a few slides to an ad, just like at the initial pageload.)
If we hypothetically needed a workaround here, we could consider shipping that^ as an intervention -- e.g. mobile-gallery-slideshow { display: block } for msn.com -- but that might conceivably break layouts in some other cases, too.
|
|
||
Comment 3•3 days ago
|
||
I filed bug 1918504 with a reduced testcase for the incorrect positioning here. (I also filed bug 1918489 for another painting issue that I ran into while reducing the testcase, which might explain why the slide count doesn't initially show up here for me.)
Calling this diagnosed with bug 1918504 being the primary underlying bug here. Bottom line, this site is sort-of-accidentally using a display:inline element as an abspos containing block, and we've got some known issues with layout for content that does that (which I've gathered as dependencies of metabug 1918488).
Description
•