STR:

1. In Firefox Nightly for Android, visit some playable content, e.g. this page:
   https://www.npr.org/2022/03/11/1086150840/our-most-valuable-lessons-from-2-pandemic-years
2. Tap the play button near the top of the article ("21-minute Listen")
3. When the widget at the bottom of the screen indicates that it's playing, scroll down the article enough to hide Firefox's dynamic toolbar.
4. Wait a few seconds.

ACTUAL RESULTS:
The controls disappear on NPR's player widget at the bottom of the screen. They're still clickable in that I can tap the left edge to (audibly) pause/play the episode; but they aren't visible until you scroll back up to make the dynamic toolbar appear again.

EXPECTED RESULTS:
Controls should remain visible.

I suspect there might be some painting bug here (as opposed to a layout/positioning bug), where we're failing to paint since we think the content is offscreen/clippbable.

This also seems to be a regression. I can reproduce this issue in the latest gve build

 mozregression --app gve --launch 2022-03-13

...whereas in older gve builds, I see a much-less-severe version of this issue where only the ticking timestamp seems to disappear, e.g. in these builds:

mozregression --app gve --launch 2021-03-15
mozregression --app gve --launch 2021-09-09

(To be clear, the disappearing-ticking-timestamp is still a bug and not-by-design AFAICT. Possibly the same bug which has just become more severe.)

I'll track down a tighter regression range for the behavior-change later on today.

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=972d906c1278206af1924049c83563cec369d4d8&tochange=c1b506c204a4cad3eba0383fa29cdb5e8054c35a

This pointed me to this commit:
https://hg.mozilla.org/integration/autoland/rev/c2ba5de58a9f79d620d90f98d1ff52de1e76d50a
Miko Mynttinen — Bug 1751742 - Enable stacking context display item reuse in Nightly r=mstange

...which set about:config pfref layout.display-list.retain.sc to true for Nightly.

And indeed, that's responsible for the behavior-change. If I manually toggle that to 'false', then this goes away - I end up with the less-severe issue where only the ticking timestamp disappears. The other contents in this footer-widget (the pause-button, episode title, and "Open^" button) all remain visible.

It looks like we're returning the pref to false everywhere in bug 1759514, though. That would fix this, based on my own testing by flipping the pref. --> Setting dependency.

Toggling ni=miko in case he wants to investigate this further, or put it on some sort of radar associated with that work (if we're eventually intending to reenable/ship this configuration or something like it).

Set release status flags based on info from the regressing bug 1751742

(setting status flags to 'disabled' in v98 and 99, since this depends on a pref that was flipped on for Nightly-only)

(In reply to Daniel Holbert [:dholbert] from comment #4)

It looks like we're returning the pref to false everywhere in bug 1759514, though. That would fix this, based on my own testing by flipping the pref. --> Setting dependency.

Toggling ni=miko in case he wants to investigate this further, or put it on some sort of radar associated with that work (if we're eventually intending to reenable/ship this configuration or something like it).

Thank you. I will definitely take a look at this when it's appropriate.

This has gotten a little bit better (i.e. more fiddly) -- the controls usually don't disappear altogether now. Here's a screencast showing several scenarios.

A few simple observations about what disappears and how to make it disappear:

• If you scroll to hide the toolbar while the story is playing (per STR), the timestamp disappears after a second or two (and stays hidden).
• If you pause the story while the toolbar is in view, and then scroll to hide the toolbar, and then hit play: the play button will usually disappear entirely, instead of turning into a pause button.

The attached screencast shows both of these things happening.

As in bug 1782119 comment 7: if I disable the about:config pref layout.display-list.retain, then this bug goes away and stuff doesn't disappear anymore. (I don't even need to reload the web page. Just scroll some more, do further actions as shown in my screencasts; nothing disappears, hooray!)

per Matrix discussion with hiro, I think that means we can call this a dupe of bug 1772859. Though of course we can/should reopen if this issue persists after that bug's fix lands.