1933708 - europa.eu - Article images are not displayed

Status: NEW

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

Description

[Calin Tanase]

Attachment: image.png

Environment:
Operating system: Windows 11/10
Firefox version: Firefox 132.0.2 (release)/133/135

Preconditions:

• Clean profile

Steps to reproduce:

1. Navigate to: https://fusionforenergy.europa.eu/news/
2. Scroll down the page.
3. Observe the articles.

Expected Behavior:
Article images are displayed.

Actual Behavior:
Article images are missing.

Notes:

• Resizing the browser window displays the images as expected
• Reproducible on the latest Firefox Release and Nightly
• Reproducible regardless of the ETP setting
• Works as expected using Chrome

---

Created from webcompat-user-report:ccdb0f89-90a3-41ed-b062-1ac1405c5dd8

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fdbed96f8519523e97783bda3e7132ec184f5312&tochange=b95c7ed878eed5db3034a19e4992ee13b0bf4445

Suspect: Bug 1703048

Workaround:
set dom.image-lazy-loading.root-margin.bottom=0 and dom.image-lazy-loading.root-margin.top=0

Comment 4

[Sean Feng [:sefeng]]

I guess I misclicked, so my previous comment becomes private, here it is.

I think there's a chance that this isn't a platform-bug. So far I see the images are loaded, but they are invisible. The site has some JS that supposes to change the opacity, and also change the position of the images.

It could be some race conditions so that those JS are not run for Firefox, or we didn't fire certain events (so a DOM bug?) ?

I wonder if Daniel or Emilio can see something here.

Comment 5

[Daniel Holbert [:dholbert]]

So the relevant difference for whether or not these images are initially visible is whether the site's JS sets their top CSS property gets set (to 0). The site sets a bunch of properties when the viewport resizes, as well as on the initial pageload (inside a resize-related backtrace). But in Firefox, the site doesn't set top for some reason.

Stepping backwards from where the img attributes get set, there are a few intermediate steps, but it boils down to whether or not we already know the img's naturalWidth and naturalHeight when we get here:

                    d || (d = t[0].naturalWidth),
                    p || (p = t[0].naturalHeight),
                    h = d / p

https://fusionforenergy.europa.eu/wp-content/themes/iter/js/min.js

t[0] is the img element there. In Firefox, the naturalWidth and naturalHeight APIs return 0 at this point in the pageload. In Chrome, they return 300x150. In Firefox, this ends up meaning that the logic proceeds with h = 0/0 = NaN which messes up the later arithmetic and results in top not being added to the list of properties that the site sets. In Chrome, they proceed with h = 300/150 = 2.

The naturalWidth and naturalHeight difference there does seem to be an actual implementation difference between Firefox vs. Chrome. The image here is actually just a placeholder SVG data URI (the site hasn't inserted the actual image URL yet at this point). For now it's just data:image/svg+xml,%3Csvg xmlns='http%3A%2F%2Fwww.w3.org/2000/svg' style='width:auto;height:auto'%2F%3E (which decodes to <svg xmlns='http://www.w3.org/2000/svg' style='width:auto;height:auto'/>). And I can confirm locally that Firefox reports a naturalWidth and naturalHeight of 0 for an img with that URI, whereas Chrome reports 300x150 (the default fallback replaced-element size).

So: that behavior-difference is the proximal difference here.

The workaround in comment 2 presumably is about a later part of the pageload where the img element is actually available and the page might trigger the same callstack again with an image that has a nonzero naturalWidth and naturalHeight, but that's kind of a "second chance" at triggering this same logic and getting top to be set, rather than the first chance where Chrome happens to make it through this logic.

Comment 6

[Daniel Holbert [:dholbert]]

I spun off bug 1935269 on the naturalWidth & naturalHeight difference that I mentioned in comment 5.

I confirmed that aligning with Chrome on that bug is sufficient to get the site's expected layout here. If I place a breakpoint on the JS that I quoted in comment 5, and set d to 300 and p to 150 in cases where they would otherwise be 0, then the images shows up as-expected.

Comment 7

[Daniel Holbert [:dholbert]]

Morphing this back into a site-report with bug 1935269 being the underlying platform bug here.