Closed Bug 329896 Opened 19 years ago Closed 13 years ago

No broken image icon with broken image without width or height set

Categories

(Core :: Graphics: ImageLib, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: martijn.martijn, Unassigned)

References

Details

(Keywords: regression, testcase)

Attachments

(3 files)

See upcoming testcase, I would expect to see a broken image icon there, but I don't see it with current trunk build.
This regressed between 2005-09-18 and 2005-09-19, so likely a regression from bug 11011.
Attached file testcase
This was a purposeful change made in bug 11011, per Hixie's alt text spec.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
You mean this text, right?
http://www.hixie.ch/specs/alttext
"
There should never be a sized placeholder frame for an image where the
UA does not know the size.

Note that broken images never take up their size as given in HTML, and
if they are unimportant according to the author (i.e., alt='') then
they will in fact not be shown at all (except in legacy/quirks mode).
For these images, a "Page Info" feature is the only way of accessing
the information.
"

But doesn't that contradict with:
"
   For ALL other cases (images not downloaded in 'Don't Load Images'
   mode, broken images, missing images, unrecognised images, and
   images that have no dimensions):

      In CSS terms, make the IMG or INPUT be a non-replaced element.

      If there is any alternative text, or if the document is in
      legacy (or 'quirks') mode and the alt attribute is missing, then
      insert an inline box containing an image icon inside the IMG or
      INPUT element.
"?
Attached file testcase2
With this testcase, I get a broken image icon to see in current trunk builds.
I don't really see why there should be a difference between the two testcases.
Yesh, those two sections are a little contradictory, or at least the second contradicts the informative text in the first.  Mention it to Ian?

At the moment we just don't implement the second section -- that requires that we show an icon for ALL broken images, including ones with useful alt text, and I'm not sure we want to do that particularly.

I do agree that the rendering difference between testcase and testcase2 is odd; I'll investigate that.
Reopening -- stuart says this is an imagelib bug.  There shouldn't be an imgIContainer if SIZE_AVAILABLE is not set, which is what's happening here.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
If it's decided that it's ok to have a non-null imgIContainer here, please reassign back to layout; in that case we'll need to sprinkle flag checks all over our GetImage() callers.

stuart, could you please decide what the imagelib api is supposed to be doing and document in imgIRequest?  That will tell me where we stand with the rest of this stuff.
Assignee: nobody → pavlov
Status: REOPENED → NEW
Component: Layout → ImageLib
OS: Windows XP → All
QA Contact: layout
Hardware: PC → All
It seems like the decision is to don't show the broken image icon.
Personally I would have liked the broken image icon to show up. This is also what IE6 is doing. (and for web authors it is easier noticeable when they have some image on a web page screwed up)
Component: ImageLib → Layout
OS: All → Windows XP
Hardware: All → PC
bz asked me to attach this
Component: Layout → ImageLib
OS: Windows XP → All
Hardware: PC → All
None of this is relevant here since the test case in question is in quirks mode and the spec cited above is only relevant to standards mode. In any case, I don't really see the contradiction in the spec, could you point it out more explicitly?
Note that there are already bugs filed on the whole alt text icon thing in standards mode. See bug 41924 comment 179 and bug 180622.
Ah, I see.  The placholder is not inserted for alt=''.  Ok, no contradiction.  ;)
  
Assignee: pavlov → nobody
QA Contact: imagelib
I see broken image icons for both testcases with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0a2) Gecko/20111129 Firefox/10.0a2

Given that this resolves the original bug description, and that the confusion around specs was for standards mode, not quirks, I'm resolving this as WFM.

Please reopen if this is still an issue.
Status: NEW → RESOLVED
Closed: 19 years ago13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: