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.