Closed Bug 1616537 Opened 2 months ago Closed 1 month ago

img broken shown even with alt=""


(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

73 Branch



Tracking Status
firefox-esr68 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- fixed


(Reporter: benjamin.leseur, Assigned: emilio)




(Keywords: parity-chrome, regression)


(3 files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

A web page with a non-important image like :

<img src="non-existing.jpg" alt="">

The broken image icon is shown even with the alt attribute set to "".

Actual results:

Firefox shows the broken image icon.

Expected results:

The broken image icon should be hidden.

Reading the doc : I found this in alt paragraph :

Setting this attribute to an empty string (alt="") indicates that this image is not a key part of the content (it’s decoration or a tracking pixel), and that non-visual browsers may omit it from rendering.
Visual browsers will also hide the broken image icon if the alt is empty and the image failed to display.

Chromium hide the broken image icon with alt=""

Has STR: --- → yes
Component: Untriaged → Layout: Images, Video, and HTML Frames
Keywords: parity-chrome
Product: Firefox → Core

I don't see any broken image icon with data:text/html,<!doctype html><img src="non-existing.jpg" width=50 height=50 alt=""> or the same without the standards mode or the width / height attributes or what not.

Can you attach a test-case that reproduces the issue?

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

Can you attach a test-case that reproduces the issue?

I don't see a broken image with your example either, but I do with this one:
data:text/html,<!doctype html><img src="https://nosuchdomain.exists/logo.jpg" alt="">

I still show the broken image icon in all these situations :

Relevant spec is here and I agree that per spec based on that we should be treating alt="" differently from no alt attribute.

That is a bit odd, is that intentional Anne? WebKit behaves like us, for what is worth.

I'd be a bit wary of changing our behavior here given how bizarre the Blink behavior is:

Though they do get this particular case right, in fairness.

Flags: needinfo?(annevk)

Yeah, that's intentional. alt="" signifies the image has no meaning. Lack of alt signifies that the meaning is unknown. Copying bz as he used to work on this a bunch (and might still?).

Flags: needinfo?(annevk)

I guess WebKit fixed this like two days ago...

Assignee: nobody → emilio
Ever confirmed: true

Yes, alt="" should suppress broken image stuff, generally... I thought we used to do that, but maybe some of the missing-alt changes changed the behavior?

From memory, it had this behavior in a not so old past

Flags: needinfo?(emilio)

mozregression-gui can't narrow the range further because this regression is so old. Bug 1196668 looks like the likely culprit.

Has Regression Range: --- → yes
Keywords: regression
Regressed by: 1196668
Priority: -- → P3
Flags: needinfo?(emilio)

The spec seems to want us to treat it like an inline, but that's not what other
browsers do (I added tests for this in bug 1196668, and they still pass in all

This is an oddly specific condition to put in
nsImageFrame::ShouldShowBrokenImageIcon(), but oh well, we're past all sanity
here I think...

Pushed by
Don't give images with empty alt an intrinsic ratio. r=bzbarsky
Created web-platform-tests PR for changes under testing/web-platform/tests
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla75
Upstream PR merged by moz-wptsync-bot
You need to log in before you can comment on or make changes to this bug.