Closed Bug 26282 Opened 25 years ago Closed 25 years ago

filename alt text should end at first ? ; or # {compat}

Categories

(Core :: Layout, defect, P4)

x86
Other
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: David_Charlap, Assigned: troy)

References

()

Details

Visit the URL I mentioned above.  Notice how the "comics.com services" box is
incredibly wide.  This forces the entire page to be that wide.  The comic
itself, which is centered on the page, ends up being placed centered over the
too-wide page.

I'm using the daily Windows build, which I downloaded from mozilla.org on
2-Feb-2000.

-- David
Looks okay with today's build
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
It only happens when I filter out the advertisements.  Add a line to 
\WINNT\System32\drivers\etc\hosts containing

127.0.0.1	ad.doubleclick.net

to make the ad banners not appear.  (I am running a local web server, but 
that shouldn't matter, since the URLs don't exist - not-found errors are 
returned for all doubleclick.com references.)  Then the layout for the 
"services" box gets messed up.  This box is a table containing links and images 
from the no-longer-available site.  It appears to have been inserted via 
JavaScript.

For comparison, Communicator 4.7 displays the box properly, and simply shows the 
broken-image icon for the unavailable content.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Adding that line to my "hosts" isn't causing the image load to fail (instead 
it's just spinning), but looking at the source it's clear what the issue is.

The IMG URI looks like this:                                                 
http://ad.doubleclick.net/ad/www.umcomics.alleyoop.com/;s_opt=servicesboxh;s_typ
=text;s_pos=botmid;s_avl=servicesboxh_text_nonhomepage;s_ava=servicesboxh_text_n
onhomepage_entertain;ov=OX;sz=320x18;tile=3;ord=887481286884242800

When, in your case, it fails to load we display the alternate content instead. 
Since there's no ALT attribute or TITLE attribute we try and use the filename. 

And we do a lousy job of it and so probably everything after the last '/' is 
used. That's why the table ends up so large.

All of that is per the HTML4 spec, although it's not what Nav or IE do.

Ian, what do you think we should do in this case?

We could:
1. see there's no ALT attribute specified. That means it's not valid HTML (per 
the HTML4 spec), because ALT is required. Then we could look at whether it's 
quirks mode and if it is just leave up the broken icon
2. try to come up with a sensible substitution, including using "" because we 
can't find anything that looks like a filename in that mess.
Ok. First of all, our behaviour is actually correct, if a little short sighted.
Second, the page is broken, since it does not specify the alt text.

Having said that, we do indeed need to do something here. We could just limit
ourselves to everything from the last "/" to the first ";", "?" or "#". That 
would solve this problem (rather neatly, in fact: it would leave nothing at all
in this case!), and preempt any likely problems with more conventional CGI-
script-generated images (although we may be already doing this).

I wouldn't invoke quirks mode things here, because the entire concept of using
the filename for the alternative text means that the document is invalid anyway.

petersen: I'm stealing QA, since this is an alt text bug...
david: any views on this?
Blocks: html4.01
Severity: normal → minor
Depends on: 1994
Priority: P3 → P4
QA Contact: petersen → py8ieh=bugzilla
Summary: Centered image is way off the edge of the screen → filename alt text should end at first ? ; or # {compat}
Just using from the last slash / to ? ; or # and then stripping off the 
extension if there is one (that's the part I'm doing today that's actually 
correct) sounds fine to me if David has no objections

When I first wrote code I was unaware of just how nasty the syntax was URI 
segments
I changed the frame construction code to do what Ian and I discussed. Now if 
the segment contains ;?# we only use what's between the final '/' and the 
special character and ignore the rest
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
dcharlap@fore.com: Could you verify that this is fixed for you in the latest
nightly builds? Thanks.
Yep.  It's fixed in the build I downloaded this morning.  Build ID: 2000021316

Thanks much, everybody.


Status: RESOLVED → VERIFIED
Depends on: 75185
No longer depends on: 1994
You need to log in before you can comment on or make changes to this bug.