236681 - Camino sometimes fails to display images embedded in documents

Status: RESOLVED WORKSFORME

(Camino Graveyard :: Page Layout, defect)

Description

[Greg K.]

Camino/2004-02-29-08 sometimes fails to display images included in web documents
such as HTML pages. Camino will successfully display the image when accessed
directly.

In the example URL, Camino will not display the columnist's image in the sidebar
which begins with the text, "Acquiring Jan Hrdina is a coup for the New Jersey
Devils...."

Current Mozilla trunk builds such as 2004-02-25-05 display the image successfully.

Comment 1

[Greg K.]

Attachment: A minimized testcase containing only an IMG element that Camino will fail to display

Comment 2

[Greg K.]

Attachment: Side-by-side comparison showing the same document area as displayed by Camino and Mozilla

Comment 3

[Jasper]

The image is displayed fine for me in Camino.

Comment 4

[Greg K.]

Re-tested with a fresh profile and it works. Triaged old profile, discovered
that if files cookperm.txt and hostperm.1 are removed the testcase works. What
generates these files? Do these files cause Camino to block loading of some images?

Comment 5

[Hiro]

Although URL was displayed by camino and firefox and image was compared, there
is no difference.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.7b) Gecko/20040306
Camino/0.7+
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.7b) Gecko/20040305
Firefox/0.8.0+

Comment 6

[Jasper]

As far as I know you can indeed block content using cookperm.txt. Note that that
is also possible with userContent.css. Please let me know if I can close the bug.

Comment 7

[Greg K.]

Sure you *can* block it, but at no point have I ever configured Camino to do so.

Comment 8

[Mike Pinkerton (not reading bugmail)]

this either sounds like a mozilla bug or wfm since we don't have any steps to
reproduce.

Comment 9

[Greg K.]

Reopening. Right now,
<http://us.i1.yimg.com/us.yimg.com/i/spo/med/2004/05/ipt/1083908088.jpg> won’t
display in 2004050308 (v0.8b); it does in Mozilla-Mac/2004042110. Does anyone
else see this?

Comment 10

[Mike Pinkerton (not reading bugmail)]

curious. what's special about that image?

Comment 11

[Greg K.]

Hm, one possible thing is the server doesn’t return a Content-Type.

GET http://us.i1.yimg.com/us.yimg.com/i/spo/med/2004/05/ipt/1083908088.jpg HTTP/1.0
Accept: */*
Host: us.i1.yimg.com
User-Agent: Interarchy/6.2

HTTP/1.1 200 Probably OK
Via: HTTP/1.0 spcss29. (IBM-PROXY-WTE-US), HTTP/1.1 spcss31. (IBM-PROXY-WTE-US)
Cache-Control: private, no-cache
Warning: 299 spcss29. "Origin server sent an HTTP/0.9 response; translated to
HTTP/1.x by proxy." 

Comment 12

[Stuart Morgan]

What exactly does "won't display" mean? 404? Timeout? Blank page load (if so,
what does the title bar say)?

(I can't test this, since that images is on server blocked by my hosts file and
thus doesn't show up in *any* browser)

Comment 13

[Greg K.]

Blank display. The URL bar shows the URL, the titlebar shows 1083908088.jpg
(JPEG image, 225x169 pixels), and the tab shows a truncated portion of that
title, as expected. The browser content area remains blank.

Comment 14

[Greg K.]

Tried to configure my Apache to never send a Content-Type, but failed. It always
insisted on sending at least Content-Type: text/plain.

Comment 15

[Greg K.]

Attachment: JPEG testcase

Comment 16

[Greg K.]

Attachment: HTML testcase

Okay, today this problem manifested itself in a different way, using *local
files* created by JAlbum. It appears to have something to do with width and
height attributes on images in this case. Image scaling is not involved,
because the width and height values correspond to the actual image dimensions.
The testcase fails in 2004060208 (v0.8b+), and WFM using Moz-Mac/1.7RC2.

Note also that the URL in comment 9 now appears to display using 2004060208
(v0.8b+).

Comment 17

[Greg K.]

Attachment: HTML testcase, corrected

Oops, old HTML testcase wasn't quite what it claimed to be.

Comment 18

[Greg K.]

Comment on attachment 150137 [details]
JPEG testcase

Absolutely my bad on this testcase. The image was being blocked by
userContent.css rules. XP

Comment 19

[Josh Aas]

I don't see the problem here. I never did. Can we mark this bug WFM?

Comment 20

[Greg K.]

Sure.