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



19 years ago
14 years ago


(Reporter: lbaliman, Assigned: jud)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta2+] 7/21, URL)


(1 attachment)

Comment hidden (empty)

Comment 1

19 years ago
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?


Comment 2

19 years ago
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 
3. This page's frames do not contain <meta http-equiv="replace" content="0; 
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.
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.
Last Resolved: 19 years ago
OS: Windows 98 → All
Hardware: PC → All
Resolution: --- → WONTFIX
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?
Resolution: WONTFIX → ---
Reassigning to warren because of the possible netlib issue (english language vs. 
french language) noted by external analyst.
Assignee: asadotzler → warren

Comment 5

19 years ago
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 

Comment 6

19 years ago
Gagan is necko now.
Assignee: warren → gagan

Comment 7

19 years ago
I get some assertions from docshell/docloader. ->rpotts
Assignee: gagan → rpotts


19 years ago

Comment 8

19 years ago
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

19 years ago
Created attachment 9138 [details] [diff] [review]
Proposed fix to nsUnknownDecoder.cpp


19 years ago
Whiteboard: have fix

Comment 10

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

Comment 11

19 years ago
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

19 years ago
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. 
How do current browsers handle this?  If the problem doesn't exist in 4.x, pdt
will plus it.
Whiteboard: have fix → [Need Info] have fix

Comment 14

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

Also looking good in IE 5.0, Windows OS.

Comment 15

19 years ago
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

19 years ago
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?
marking nsbeta2+.  adding 4xp keyword
Keywords: 4xp
Whiteboard: [Need Info] have fix → [nsbeta2+] have fix
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
QA Contact: jelwell → doronr

Comment 19

19 years ago
I've checked the fix in...

-- rick
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED


19 years ago
Depends on: 42974
I am still having this problem with 2000062508 on Mac OS 9. Has this bug really
been fixed?
Resolution: FIXED → ---

Comment 21

19 years ago
removing 'have fix' from status 
Whiteboard: [nsbeta2+] have fix → [nsbeta2+]

Comment 22

19 years ago
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
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 23

19 years ago
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
QA Contact: doronr → jrgm

Comment 24

19 years ago
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."
OS: All → Mac System 9.0
Hardware: All → Macintosh
Resolution: FIXED → ---

Comment 25

19 years ago
Updating summary from "www.aol.fr will not display using US PR1, US PR2"
Depends on: 45019
Summary: www.aol.fr will not display using US PR1, US PR2 → www.aol.fr forces "unknown file type" dialog on Mac

Comment 26

19 years ago
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?

-- rick
Assignee: rpotts → valeski

Comment 27

19 years ago
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).
Keywords: patch
Whiteboard: [nsbeta2+] → [nsbeta2+] 7/21

Comment 28

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


19 years ago
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 29

19 years ago
fix is in (for the dialog throwing)
Linda Baliman - can you verify?

Comment 31

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

Comment 32

19 years ago
verified fixed. mac os 9.0 2000072408. www.aol.fr loads ok (modulo a possible
lingering problem covered by bug 42974).
Product: Browser → Seamonkey
OS: All
Hardware: Macintosh → All
You need to log in before you can comment on or make changes to this bug.