39797 - www.aol.fr forces "unknown file type" dialog on Mac

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P3)

Comment 1

[Clay Collier]

Seeing the same behaviour on the current nightlt build (win-32-talkback.zip 
build for 5/20/2000)., Build ID 2000052015.  Steps to reproduce:
1)Fire up Mozilla
2)Visit http://www.aol.fr
3)Observe that the page is compleatly blank.
Peculiarly, in Milestone 15(Build ID 2000041805), not only does the page not 
load, but Mozilla reports that it is attempting to download an unrocognized 
file of type application/octet stream, and proceeds to download a 3 KB file 
named afp.dll.  Opening the .dll file with a text editor reveals it to contain 
the sourcecode for the page.  The fact that the page source is a mass of 
Javascript suggests a scripting problem, but the download in M15 suggests a 
problem in the parser or something like that.  Anyone know where this should go?

clay  

Comment 2

[timeless]

This page does all sorts of things wrong. Marking won't fix, adding to cc. My 
issues follow:
1. Lynx gets laughed at "This web page uses frames, but your browser doesn't"
2. It flunks accessibility requirements http://www.cast.org/bobby/ output is 
http://udl.cast.org/bobby?browser=AccEval&URL=http%3A%2F%2Fwww.aol.fr&output=Su
bmit
3. This page's frames do not contain <meta http-equiv="replace" content="0; 
url=http://urlforJSunawarebrowsers">
4. This server should accept my request of [us]ENglish content. [Yes I know, 
that isn't fair, but just because I go to a site in .france doesn't mean I want 
to speak french, that's a browser preference.]
Last: Using http://www.delorie.com/web/wpbcv.html or composer I get some really 
unacceptable output.
-details: check all boxes and enter the url
"The specified module could not be found. "
This text also appears in mozilla composer in certain instances.
http://www.aol.fr/undefinedafp.dll?MesInfos2
The problem is that this site requires javascript to work.

If you want us to reopen this bug, please convince www.aol.fr to use standard 
features, support lynx and then reopen the bug noting that the content changed.
-
Otherwise feel free to establish a tiny test case.

Comment 3

[ekrock's old account (dead)]

REOPENing, marking 4xp, and assigning to warren as this seems like a possible 
netlib problem. (It may be a DUP of another open bug for all I know.)

Timeless, many thanks for your detailed assessment of the page's 
accessibility & standards compliance (or lack thereof). AOL France (and probably 
most of the web!) can obviously learn much from you! And we should make 
a note to evangelize them on those issues. However, for resolving this report 
in particular, there are two things worth keeping in mind:

1) Most of the problems detected by those page analysis tools, the lack of Lynx 
support, etc., are bad page design indeed, but I'm not yet sure they're directly 
related to the fact that the page completely fails to display (which is the main 
focus of this report).
2) The page displays correctly in  Nav4x and *almost* correctly in IE5 (except 
for I'm seeing some odd garbage characters that look like Chinese scattered 
across the page, which is strange given that the AOL client itself embeds IE and 
you'd expect their content to if anything be optimized for it). So whatever the 
page's/site's/server's faults may be, since it displayed correctly (or at least 
displayed!) in Nav4 and IE, Mozilla will likely be considered "buggy" by users 
if it totally chokes on the page, and we should investigate further to see why 
it is that the page is totally blank. (It may be the case that there is some 
kind of poor client/server interaction like that you noted that Nav4 tolerated 
and Mozilla currently breaks on.)

Bottom line: we don't want Mozilla to Break The Web, so totally failing to 
display a major site page is a source of concern. Linda, could you & int'l 
Netcenter please work on simplifying the page down to a simple-as-possible test 
case so eng & QA can zero in on the problem?

Comment 4

[ekrock's old account (dead)]

Reassigning to warren because of the possible netlib issue (english language vs. 
french language) noted by external analyst.

Comment 5

[timeless]

My last parting blow to this bug before I leave it to the pros.
4xp, JavaScript disabled in nc4.73 results in two empty pages [tiny top w/ no 
scrollbars] and large bottom w/ disabled scrollbars.

this may be a javascript bug because otherwise mozilla behaves correctly under 
4xp.

Comment 6

[Warren Harris]

Gagan is necko now.

Comment 7

[Gagan]

I get some assertions from docshell/docloader. ->rpotts

Comment 8

[rpotts (gone)]

This is a sweet bug :-)

So, it appears that the page is ending up in the "unknown content type" byte 
sniffer because *no* content-type header was supplied by the server :-(

Unfortunately, because it is a non-english page it is failing the test for 
text/plain so its content-type is returned as x-application/octet-stream.

I have no idea why the save-as dialog is *not* showing up, but it seems like the 
real problem is that the byte sniffer code is not dealing with foriegn text 
pages correctly...

Comment 9

[rpotts (gone)]

Attachment: Proposed fix to nsUnknownDecoder.cpp

Comment 10

[rpotts (gone)]

Marking nsbeta2 because this bug affects *all* international sites where the 
server does not supply a content-type...

Comment 11

[rpotts (gone)]

hey frank,

I need your help on this one...  What is the "correct" way to determine of a 
buffer (~2k) of data is actually text/plain.

All that I have is the data, no content-type and no charset info :-(

What can I do?

Comment 12

[Allan Masri]

I just spoke to ftang about this problem. He suggests that what we're really 
doing is handling errors created on the server side. Although we could 
theoretically solve these problems, the right approach should be to inform the 
server owner that they are making a mistake. Otherwise, this becomes a 
bottomless pit of refining algorithms that are all unnecessary if the server is 
doing the right thing. 

Comment 13

[Michael La Guardia]

How do current browsers handle this?  If the problem doesn't exist in 4.x, pdt
will plus it.

Comment 14

[Linda Baliman]

www.aol.fr displays perfectly in Communicator 4.72, Windows OS, at least.

Also looking good in IE 5.0, Windows OS.

Comment 15

[timeless]

ie5.5 windows 2000
DrWatson ran :-)
-- For people who don't use windows, this means iexplore.exe crashed. It killed 
my whole shell [and made my day].  As long as we don't do this, I'm happy.

Comment 16

[rpotts (gone)]

I agree with Frank, that in a perfect world we shouldn't need to worry about 
this, but unfortunately we *are* living in a bottomless pit of horrors - or at 
least I do with these kind of bugs.

The bottom line is that in the real world. servers *do* send content without a 
content type, and Nav4 and IE do an OK job of dealing with this.

I need to know the minimum that I can do to in order to detect whether a buffer 
is text or not...  

since I can't rely on text being 7-bit ASCII, can I look for embedded nulls?

Comment 17

[Michael La Guardia]

marking nsbeta2+.  adding 4xp keyword

Comment 18

[Asa Dotzler [:asa]]

Sorry for the spam.  New QA Contact for Browser General.  Thanks for your help
Joseph (good luck with the new job) and welcome aboard Doron Rosenberg

Comment 19

[rpotts (gone)]

I've checked the fix in...

-- rick

Comment 20

[Zach Lipton [:zach]]

I am still having this problem with 2000062508 on Mac OS 9. Has this bug really
been fixed?

Comment 21

[rpotts (gone)]

removing 'have fix' from status 

Comment 22

[rpotts (gone)]

It looks like this bug has 'morphed'.  Now http://www.aol.fr/ does not load 
correctly, but it *does* load...

I'm closing this bug out and opening a new bug to reflect the fact that 
http://www.aol.fr/ is not loading correctly.

See bug #45894
-- rick

Comment 23

[John Morrison]

verified fixed -- page is not blank, but remaining issues are 
1) images don't load -- bug 45894
2) scrollbars are only ~4px wide -- bug  42974

Comment 24

[John Morrison]

Reopening (despite the morphing, and yesterday's verification). 

With 2000072008 (mac 9.0), when I load www.aol.fr, I am presented with the 
'unknown file type' dialog. [Actually, on one occasion it did load today 
(with missing images [bug 45894/bug 45019]), but on every other occasion I 
got the unknown file type dialog.

This is now a MAC-ONLY bug; it does not occur on win32 and linux. 
Note: there are two other open bugs related to this AOL page:
  1) bug 45019 -- "images not displayed with page written by javascript"
       (which bug 45894 was duped against)
  2) bug 42974 -- ""Ultra narrow" horizontal & vertical scrollbars."

Comment 25

[John Morrison]

Updating summary from "www.aol.fr will not display using US PR1, US PR2"

Comment 26

[rpotts (gone)]

hey jud,

I don't have a Mac, so I have no way to debug this one...  Do you want to take a 
quick look at it?  Or kick it over to Conrad?

thanks,
-- rick

Comment 27

[Judson Valeski]

mscott, please review the following patch.

Index: src/nsMIMEInfoImpl.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/mime/src/nsMIMEInfoImpl.cpp,v
retrieving revision 1.21
diff -c -r1.21 nsMIMEInfoImpl.cpp
*** nsMIMEInfoImpl.cpp  2000/07/11 23:11:59     1.21
--- nsMIMEInfoImpl.cpp  2000/07/21 19:53:45
***************
*** 104,109 ****
--- 104,112 ----
  nsMIMEInfoImpl::GetMIMEType(char * *aMIMEType) {
      if (!aMIMEType) return NS_ERROR_NULL_POINTER;

+     if (mMIMEType.Length() < 1)
+         return NS_ERROR_NOT_INITIALIZED;
+
      *aMIMEType = mMIMEType.ToNewCString();
      if (!*aMIMEType) return NS_ERROR_OUT_OF_MEMORY;
      return NS_OK;

this is MAC only because the mac digs down into the internet config libraries 
for the mac. On the mac we wind up creating an nsMIMEInfo object w/ an empty 
string as the MIME type, and we're later trying to use that empty string as a 
valid MIME type :-/. I'm attatching a patch that will cause GetMIMEType() to 
fail if it's MIME type len isn't > 0.

This patch fixes the unknown content type dialog problem, but the page doesn't 
fully load (all platforms suffer from this problem).

Comment 28

[Scott MacGregor]

Okay this looks correct to me. r=mscott for this first part of the fix.

Comment 29

[Judson Valeski]

fix is in (for the dialog throwing)

Comment 30

[Doron Rosenberg (IBM)]

Linda Baliman - can you verify?

Comment 31

[Linda Baliman]

Doron, I'm not in QA, so I cannot Verify.  Please ask someone in QA to Verify.

Comment 32

[John Morrison]

verified fixed. mac os 9.0 2000072408. www.aol.fr loads ok (modulo a possible
lingering problem covered by bug 42974).