Closed
Bug 18491
Opened 25 years ago
Closed 25 years ago
www.epinions.com doesn't render correctly
Categories
(Core :: DOM: HTML Parser, defect, P3)
Tracking
()
VERIFIED
INVALID
M14
People
(Reporter: law, Assigned: nisheeth_mozilla)
References
()
Details
Attachments
(1 file)
|
26.05 KB,
image/png
|
Details |
Screen shot
It seems the URL in an <IMG> tag isn't being parsed properly (or at least not the same way IE or Netscape 4.61 parse it). Instead of the image, some of the URL shows up in the center of the table. This bogus column then pushes the real second column off the right edge of the window so you can't see it properly. I'm setting the component to Parser since it seems like the Parser's job to figure out what's the URL and what's not.
The tag is being parsed perfectly well. The problem is that the img SRC=xxx is invalid. When the document fails to find the specified URL it tries to use the alt-text, and since none is specified, it appears to trying to display the URL path itself. Reassigning to Nisheeth to determine if that's what we really want to do. By the way: here's a min test case: <html><body><img src="http://foo123"></body></html>
So IE/Netscape must be ignoring the <img> tag entirely in this case. I'll bug my buddy over at epinions.com. I wonder if this is some trick they're trying to pull vs. just a bug on their page?
Something's up. The ad img url loads and displays OK in Navigator (a 1x1 gif image). If I enter that URL in Mozilla's URL bar, I see "Document http://ad.doubleclick.net/... loaded successfully" written to the console. But Mozilla shows me "Error 404 Not Found." Is the server responding differently based on user-agent? How come the message on the console doesn't match the 404 Not Found message that Mozilla displays?
1) The Default to display image URL seems completely wrong to me. If the image isn't found, it should display either a broken image or nothing at all. 2) The URL seems to be valid even when telnetting, and a valid mime type is returned (image/gif). Is it possible that mozilla cares about the file extension? Obviously it shouldn't... telnet ad.doubleclick.net 80 Trying 204.253.104.170... Connected to gd8.doubleclick.net. Escape character is '^]'. GET /activity;src=345407;type=pv3;cat=ind;ord=942412277? HTTP/1.0 HTTP/1.0 200 OK Content-Type: image/gif Pragma: no-cache Cache-Control: private, no-cache Content-Length: 43 Set-Cookie: id=c0af3713; path=/; domain=.doubleclick.net; expires=Wed, 09-Nov-2030 23:59:00 GMT GIF89aящ,L;Connection closed by foreign host.
|
||
Comment 6•25 years ago
|
||
See bug 1994 for more about the default way to handle broken images. I think that Moz's way is usually OK, except for those times when you are dealing with long ad urls that cause layout problems. If only people used ALT="" then this wouldn't happen...
|
Assignee | |
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
|
|
Assignee | |
Comment 7•25 years ago
|
||
Based on Troy's comments in bug 1994, it seems that the spec says that the url of the image should be displayed if the alt text is absent. Marking this bug as a duplicate of bug 1994. Further discussion can happen on that bug. *** This bug has been marked as a duplicate of 1994 ***
Status: RESOLVED → REOPENED
I'm afraid we may be closing this as a dup a little too hastily. First, it isn't clear to me why we don't actually display the image. If you view the image url in Nav 4.x, you see a "GIF Image 1x1 pixel." What Mozilla displays for "broken" images is irrelevant if the image isn't broken, it seems to me. Secondly, there's the matter of the "width=1" attribute on the <img> tag. We might want to respect this directive in the case we actually do want to display the ALT= text (or the image URL). We can close this as a dup iff there is no image at that url, and, we deem the width= attribute as irrelevant if there isn't. I've changed the URL field in the bug to point to the image in question.
|
|
Assignee | |
Comment 10•25 years ago
|
||
Accepting bug and setting target milestone to M14...
|
|
Assignee | |
Comment 11•25 years ago
|
||
Bill, your arguments make a lot of sense. Well, it seems like the two problems here are: a) Why are we displaying a 404 Not Found error when Navigator can load and display the URL properly? I've filed bug _ on Necko to track this. b) Layout needs to respect the width specified on the image when it displays the alt text or url. If we fix this, then the layout on www.epinions.com will start looking ok. Lets use this bug to track this issue. Troy, what are your thoughts on b)? Do you want me to take a stab at fixing this or do you want to do it?
|
|
Assignee | |
Comment 12•25 years ago
|
||
Bug 25355 tracks issue a) above. I forgot to fill it in in my previous post.
|
||
Comment 13•25 years ago
|
||
Nobody is going to take a stab at fixing it, because what we're doing is correct. In CSS width/height properties apply to inline replaced elements, but nit to inline non-replaced elements. When it's an image it's a replaced element, but once it fails to render it's an inline or block frame containing a piece of text. It's no longer a replaced element and so width/height do not apply
|
|
Assignee | |
Comment 14•25 years ago
|
||
Bill, in light of Troy's comments, is it ok for me to close off this bug? It seems like your problem will get fixed as soon as bug 25355 gets fixed.
|
Reporter | |
Comment 15•25 years ago
|
||
Yes, it sounds like 25355 will solve the problem.
|
|
Assignee | |
Comment 16•25 years ago
|
||
Marking this bug invalid...
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•