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.

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

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. ;)

Yes, this does look like bug # 9796.

[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.

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

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

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

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

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.

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

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.

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

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

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.

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

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

Maybe Patrick Beard?

Or Done Cone?

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?

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

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

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

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.

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

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 ***

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!

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.