2055777 - www.eldiariodehoy.com - Images fail to display (they're zero-sized) and display as black placeholders

Status: NEW

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

Description

[Bernadett Farkas]

Environment:
Operating system: Windows 10
Firefox version: Firefox 152.0 / Firefox Nightly 154.0a1 (2026-07-16)

Steps to reproduce:

1. Access: https://www.eldiariodehoy.com/fotogalerias/asi-celebraron-los-argentinos-su-pase-a-la-final-del-mundial/85701/2026/
2. Scroll down and observe the page

Expected Behavior:
The images are loaded accordingly

Actual Behavior:
Images fail to load and display as black placeholders

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/228599

Comment 1

[Bernadett Farkas]

Attachment: Missing images Nightly vs Chrome

Comment 2

[BugBot [:suhaib / :marco]]

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

Comment 3

[AutoWebCompat]

Attachment: Reproduction steps generated by autowebcompat bot

This is a genuine Firefox web-compat issue. On the eldiariodehoy.com photo gallery page, the main gallery images (celebracion-argentina-inglaterra-*.jpg) render as large black boxes with only the caption text visible; the image content is not shown. Inspecting the image elements in Firefox shows the images are loaded (complete=true, naturalWidth=246) but their computed display height is 0, so they collapse and the black figure container shows through instead of the photo. In Chrome the identical images render at their proper display height (~957px) and show the photos correctly. Because the breakage reproduces in Firefox but not Chrome, it is a valid web-compat issue (visual/layout).

Comment 4

[AutoWebCompat]

Attachment: Screenshot generated by autowebcompat bot

Comment 5

[Alice0775 White]

Workaround: height: auto instead of 100% will show the images.

https://www.eldiariodehoy.com/wp-content/uploads/elementor/css/the-reporter-gutenberg-wp-frontend.css?ver=1.0.0

.wp-block-gallery.has-nested-images.is-cropped figure.wp-block-image:not(#individual-image) img {
  width: 100%;
  flex: 1 1 0%;
  height: 100%;
  object-fit: cover;
}

Comment 6

[Alice0775 White]

Regression window:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=e8e0ae9ae6d98094213f1535e9f063a79cc64bfd&tochange=e9065a5ef9a610b466704d32ee756b75839ad16b

Suspect: Bug 1585485

Comment 7

[BugBot [:suhaib / :marco]]

:TYLin, since you are the author of the regressor, bug 1585485, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 8

[BugBot [:suhaib / :marco]]

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

Comment 9

[AutoWebCompat]

Root cause analysis generated by autowebcompat bot:

Firefox and Chrome disagree on how to resolve a percentage flex-basis on a flex item whose column flex container has no specified height (i.e. an indefinite/content-based main size that only becomes definite via cross-axis stretching).

The gallery markup is figure.wp-block-gallery.has-nested-images.columns-1.is-cropped (an outer display:flex; flex-wrap:wrap; align-items:normal container) whose children are figure.wp-block-image elements. Each inner figure is display:flex; flex-direction:column with no specified height, and contains exactly two in-flow flex items:

1. the <img>, styled by the-reporter-gutenberg-wp-frontend.css:
   .wp-block-gallery.has-nested-images.is-cropped figure.wp-block-image:not(#individual-image) img { width:100%; flex:1 0 0%; height:100%; object-fit:cover; }
   → flex-basis: 0% (a percentage), flex-grow: 1, flex-shrink: 0, height: 100% (also a percentage).
2. the <figcaption class="wp-element-caption">, styled by the combination of
   .wp-block-gallery.has-nested-images figcaption { flex-grow:1; flex-basis:100%; } (WordPress gallery CSS) and an inline <style> rule figcaption.wp-element-caption { display:block !important; clear:both !important; position:relative !important; }. That position:relative !important defeats the gallery CSS that would otherwise make the caption position:absolute, so the caption stays in flow as a real flex item with flex: 1 1 100% — again a percentage flex-basis — plus max-height:100%.

Both items therefore ask for a percentage of the container's main size, which is not definite from the container's own properties.

• Chrome treats a percentage flex-basis that resolves against an indefinite main size as content (per CSS Flexbox §9.2 / the flex-basis definition). The caption's base size becomes its own content height (~47px on the site), the image is content-sized from its intrinsic aspect ratio, and the figure ends up image + caption tall with the photo visible (img ≈ 957px at a 1280px viewport).
• Firefox instead resolves the caption's flex-basis: 100% against the container's resolved height. The caption's flex base size becomes the entire container height, so it consumes all of the main axis. The <img>, whose flex base size is 0% → 0px and whose flex-shrink is 0, is left with a used height of 0px — getComputedStyle(img).height === "0px", getBoundingClientRect().height === 0 — even though img.complete === true and img.naturalWidth === 246. The image disappears and the black figure background shows through with only the white caption text drawn on top: the reported "solid black rectangle".

Note the reporter's observation that changing the img's height:100% → height:auto fixes it is a symptom of the same thing (it removes the percentage main-size path); the primary driver is the caption's flex-basis: 100% eating the whole container.

Evidence:

1. Confirmed the divergence on the live site (DevTools evaluate_script, 1280px viewport, no pref changes).
For img[src*="celebracion-argentina-inglaterra"] with complete===true, naturalWidth===246, naturalHeight===184:

• Firefox: img rect height 0, computed height "0px", rect width 1279.88; parent figure.wp-block-image height 1006.87px.
• Chrome: same img rect height 957 (computed 957.297px = 1279.88 × 184/246), parent figure 1004.23px.
  Both browsers agree the figure is display:flex; flex-direction:column; justify-content:center with no specified height, and the img computes to flex: 1 0 0%; height:<used>; object-fit:cover; max-width:100%.

2. Found the caption is the item consuming the space. Computed style of the live figcaption.wp-element-caption in Firefox: position:relative, display:block, flex: 1 1 100% (flex-basis: 100%), max-height:100%, and height: 1009.83px — identical to the figure's own height. Its getBoundingClientRect() height was also 1009.83, i.e. the caption box covers the whole container. In Chrome the same caption is only ~47px tall (figure 1004.23 = img 957.30 + caption 46.93).

3. Single-property probes on the live page in Firefox (each applied and reverted individually). Baseline img height 0; figure 1006.87.

• img { flex-basis: auto } → 1006.87 (fixed); img { flex-basis: 0px } → 0; img { flex-basis: 50% } → 503.43 (= 50% of 1006.87, so the percentage is being resolved against the container height, and no free space is distributed).
• img { height: auto } → 959.92 (fixed).
• figure { align-self: flex-start } → 959.92 (fixed — no stretch, so the height stays indefinite).
• gallery { align-items: flex-start } → 959.92; gallery { align-items: stretch } → 0.
• gallery { display: block } → 969.6 (fixed).
• figure { height: 1000px } → still 0 (a definite height also lets the caption's 100% eat everything).
• Irrelevant: justify-content, max-width, position on the figure, object-fit, margin:0 auto, min-height, removing srcset/sizes, removing the width/height attributes — all still 0.
• A plain <div style="flex:1 0 0%;height:100%"> probe inserted as a sibling of the img also measured 0, proving no free space was distributed in that column container.
• A figure clone with a fully cached, already-loaded image (complete:true, 246x184) still measured img 0 → not a load-timing/invalidation bug.

4. CSS bisection to isolate the trigger. Disabling each of the 47 stylesheets one at a time on the live page: only two mattered — sheet 8 (the-reporter-gutenberg-wp-frontend.css, which supplies the is-cropped ... img { flex:1 0 0%; height:100% } rule; disabling → img 184.33) and an inline sheet (index 36). Deleting rules from sheet 36 one at a time isolated rule #112: figcaption.wp-element-caption { display:block !important; clear:both !important; position:relative !important; } — deleting it made the img 959.92 and re-inserting it returned it to 0 (a control deletion of an unrelated rule in the same sheet had no effect). Editing that rule's declarations via CSSOM narrowed it further:

• position: relative !important alone → img 0 (bug present)
• display: block !important alone → 959.92; clear: both !important alone → 959.92; empty rule → 959.92
  i.e. the bug needs the caption to be in flow (position:relative defeating the gallery CSS's position:absolute), so that its flex-basis: 100% participates in flex sizing.

5. Reduced testcase (/app/diagnosis/testcase=1yg2jqq6.html, ~40 lines of CSS, self-contained data: URI image with intrinsic size 246×184 and width=1024 height=768 attributes, no site scripts). Structure: outer display:flex; flex-wrap:wrap div → inner figure { display:flex; flex-direction:column; width:100%; background:#000 } (no height) → img { width:100%; flex:1 0 0%; height:100%; object-fit:cover } + figcaption { position:relative; flex:1 1 100%; max-height:100% }.

• Firefox Nightly: img rendered HEIGHT = 0.00, computed height 0px, figcaption height = 786.17, figure height = 786.17 → "FAIL". Screenshot shows a solid black rectangle with only the white caption text — same visual as the site.
• Chrome stable: img rendered HEIGHT = 747.95 (= 1000 × 184/246), computed 747.953px, figcaption height = 38.19, figure height = 786.14 → "PASS". Screenshot shows the blue/yellow test image.
  The caption height equalling the whole figure height in Firefox vs one text line in Chrome is the same signature measured on the live site (1009.83 vs ~47).

Comment 10

[AutoWebCompat]

Attachment: Reduced testcase generated by autowebcompat bot

Comment 11

[Jeff Muizelaar [:jrmuizel]]

Daniel, is this known?

Comment 12

[Daniel Holbert [:dholbert]]

I reduced the testcase a bit further and spun off bug 2064812 for what I think the root issue is here.