10767 - [PP] A local image with a broken reference is not displaying the ALT name.

Status: VERIFIED DUPLICATE of bug 24778

(Core :: Graphics: ImageLib, defect, P3)

Description

[Chris Petersen]

Version: Apprunner
Build: 1999072815
Platform:Mac 8.6
Other Platforms: Works on Win 98 and Linux.
Expected results: The alt name should be displayed when the image can't be found.
What I got: When the file is local, the ALT name is not displayed. There is a 1
pixel object displayed where the text should appear.

Steps to reproduce:
1) Open and save the attached test case to local drive.
2) Open the file in Apprunner.
3) There will a 1 pixel object displayed in the window. The ALT name specified is
not appearing.

Comment 1

[Chris Petersen]

Attachment: A image element with a bad url and a ALT attribute

Comment 2

[pnunn]

Do other gifs display?
The description you gave could also match
what would happen if the gifcom module was
not linked properly with the gif decoder.

If other gif images display, then there is
a bug in error handling.

-pn

Comment 3

[Eli Goldberg]

Confirmed. Grr...I knew I had written this up somewhere, but couldn't find it

when we spoke on the phone.



I believe that 9796 covers this problem. CC:ing Ian out of habit. ;)

Comment 4

[Chris Petersen]

Yes, this does look like bug # 9796.

Comment 5

[Hixie (not reading bugmail)]

[thanks elig]

Bug 9796 refers to the case where the document itself is an invalid image, not
when an HTML document refers to a missing image. That would be bug 1995.

If this is a [PP] bug as the summary claims, then I suggest that bug 1995 be
added in the "Bugs depending on bug 10767" list above. Bug 1995 does not
mention Mac-only problems AFAICT, this bug would presumably cover this issue.

AFAIK, this is not a duplicate of anything.

Comment 6

[Hixie (not reading bugmail)]

For bug 1995, read bug 1994. *shoots self*

Comment 7

[Hixie (not reading bugmail)]

[Adding dependency as per my previous comments...]

Comment 8

[pnunn]

I just checked a recent mac build and
I see the alt text.
This was most likely fixed by other checkins.

-pn

Comment 9

[Hixie (not reading bugmail)]

Eli: Since this is a Mac-only bug, I am not assigning myself as QA contact.

Comment 10

[Eli Goldberg]

While this is not reproducible when loaded via the http:// server, I do see this
issue still on Mac OS using the 1999090609 build when loaded from a local file
(per the bug report.)

Thus, re-opening.

Comment 11

[pnunn]

I just tested this on a new tree. It works on a local file
using apprunner and viewer.
Eli, would you try this again. I'm using mac os 8.5.
-pn

Comment 12

[Eli Goldberg]

Using yesterday's build on Mac OS 8.6, this issue remains reproducible. I'd be
happy to check on a more recent build, but we're doing 4.7 until Monday morning.

Comment 13

[pnunn]

I just checked this on Kritzer's mac with 8.6
and it worked fine.
Eli, show me the breakage on Monday.
Thanks.
-pn

Comment 14

[pnunn]

Last time I checked, this worked. No one has added a
comment saying they have had a different experience with
recent builds. I'm closing.
-pn

Comment 15

[Eli Goldberg]

Hey, Pam ---

Using the 1999102109 build, this problem still occurs on Mac OS-only, using the
Mac OS 8.6 system in Eli-land. Currently, it displays nothing, instead of the
broken image text. Other local text files display correctly.

Re-opening for pnunn.

Comment 16

[pnunn]

This bug requires a mac layout person.
When I view the above url with a breakpoint
set at nsImageFrame:DisplayAltFeedback() on the
mac, it never hits the breakpoint. It does hit
the breakpoint on windows....

Troy, would you assign this to the appropriate person?
Thanks.
-p

Comment 17

[pnunn]

This was an m11. I'm changing to m13.
-p

Comment 18

[troy]

Maybe Patrick Beard?

Comment 19

[troy]

Or Done Cone?

Comment 20

[Patrick C. Beard]

I just tried my build from 12/29/99, and it does hit the breakpoint I set on
nsImageFrame::DisplayAltFeedback() a couple of times, but then it stops getting
hit. For some reason, once the alternate text gets displayed,
nsImageFrame::Paint() never gets called again. Why would this be?

Comment 21

[troy]

That would be because if the image can't be rendered, then we render the
alternate content instead. That means we create a text frame and replace the
image frame with the text frame, i.e., the image frame is destroyed

Comment 22

[troy]

This sounds like a Mac only problem so I'm re-assigning it back to Patrick

Comment 23

[Patrick C. Beard]

You'll have to give me more information to go on to help me fix this. Where
does the text frame get substituted?

Comment 24

[troy]

The image frame gets notified by the image library that we can't load the
image. It notifies the pres shell (through the CantRenderReplacedElement()
function), which notifies the frame construction code. The frame construction
CantRenderReplacedElement() code throws away the image frame and creates a text
frame to display the alternate content instead.

Comment 25

[Patrick C. Beard]

Reassigning to dcone, so I can concentrate on remaining critical view manager
bugs. Feel free to defer.

Comment 26

[dcone (gone)]

Sounds like this is a duplicate problem.. all platforms are having some problems 
with displaying alternate text due to the lack of an error being sent to the 
image observers when the image URL not being loaded.  Rod has this bug, we are 
all working on (pnunn, rods and dcone) to get this working.

*** This bug has been marked as a duplicate of 24778 ***

Comment 27

[Eli Goldberg]

Ian, might you wish to verify this? (if you can do so without needing the Mac 
that you don't have?)

If you'd rather not, just QA Assign it back to me.

Thanks!

Comment 28

[Hixie (not reading bugmail)]

Sounds like it probably is a dup. I'll add a comment on the other bug saying
that this one must be checked before marking the other one a dup.