Bug 1911066 Comment 2 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

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.

We could theoretically ship 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.
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.)

We could theoretically ship 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.
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.

Back to Bug 1911066 Comment 2