Bugzilla

OK, a few new developments:
(1) This is indeed a case where the `resize` event is firing in Chrome but not in Firefox, for the iframe's inner document, when the iframe goes from `display:none` to `display:block`.  I can confirm this by inspecting the iframe's document in DOM inspector, and then using Web Console (now in the context of that document) to run `addEventListener("resize", ()=>{console.log(`iframe resized`)})`.  From that point on, Chrome prints the log message when I show the iframe (i.e. when I click to bring up the image overlay view), whereas Firefox does not.

(2) This is actually a regression, though it's an old-ish one.  Regression range is:
Last good: 2022-11-20
First bad: 2022-11-21
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d2c6287383301f29964047d5c718640eb4bbcccb&tochange=a29b80b107103df84e493008e420e30aea857da1
The aforementioned simple console.log() experiment and the comment 0 STR both give expected-results (logging succeeds, image shows up) in the "last good" build vs. actual-results (no logging, image does not show up until I resize browser viewport when throbber is up) in the "first bad" build.

(3) I confirmed that the relevant thing in the regression range was **enabling container queries** in Nightly builds.  In particular, I can elicit "good" results from the first-bad build, Nightly 2022-11-21, by simply toggling `layout.css.container-queries.enabled` to `false`.  (Note that that pref doesn't exist anymore.)

(4) I confirmed that the frame here does indeed use container-queries (e.g. it has `@container (width < 840px){` inline in a `<style>` element), so the relevance of container queries is credible.

OK, a few new developments:
(1) This is indeed a case where the `resize` event is firing in Chrome but not in Firefox, for the iframe's inner document, when the iframe goes from `display:none` to `display:block`.  I can confirm this by inspecting the iframe's document in DOM inspector, and then using Web Console (now in the context of that document) to run `addEventListener("resize", ()=>{console.log(`iframe resized`)})`.  From that point on, Chrome prints the log message when I show the iframe (i.e. when I click to bring up the image overlay view), whereas Firefox does not.

(2) This is actually a regression, though it's an old-ish one.  Regression range is:
Last good: 2022-11-20
First bad: 2022-11-21
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d2c6287383301f29964047d5c718640eb4bbcccb&tochange=a29b80b107103df84e493008e420e30aea857da1
The aforementioned simple console.log() experiment and the comment 0 STR both give expected-results (logging succeeds, image shows up) in the "last good" build vs. actual-results (no logging, image does not show up until I resize browser viewport when throbber is up) in the "first bad" build.

(3) I confirmed that the relevant thing in the regression range was **enabling container queries** in Nightly builds.  In particular, I can elicit "good" results from the first-bad build, Nightly 2022-11-21, by simply toggling `layout.css.container-queries.enabled` to `false`.  (Note that that pref doesn't exist anymore.)

(4) I confirmed that the iframe here does indeed use container-queries (e.g. it has `@container (width < 840px){` inline in a `<style>` element), so the relevance of container queries is credible.