44627 - [mac]local files without .html extension are not loaded correctly

Status: VERIFIED FIXED

(Core :: Networking, defect, P4)

Description

[johng]

reproduce:
- go to www.quote.com
- click "log in"
- see the pop-up log-in window and compare these results to the results from a
4.x browser.

Although the text is the same, the appearance is very different.  Furthermore,
if you do log in (you can get a free 30 day trial), you get a results page.  In
4.x, you get a full page (I believe initiated by a javascript call), but with
this browser thepage is blank.

using nscp branded build 06/28/00

Comment 1

[johng]

Just redid it - the log-in page and log-out page displays fine (just so slow
first time that I thought it was broken).

However, the follow-up page (what you get after you log-in) is still blank.  The
page/command it is attemping to display is the following:

javascript:featureWin('http://www.quote.com/quotecom/auth/login.asp','login',450,350);

jg

Comment 2

[karnaze (gone)]

Pierre, can you please triage.

Comment 3

[Pierre Saslawsky]

The problem is fairly serious: remote URLs without a ".html" extension are not 
displayed at all. The HTTP query is sent to the server; the server sends back the 
page with "Content-Type: text/html" but Mozilla doesn't display anything if the 
URL doesn't have a ".html" extension. It means that all the CGI and ASP pages are 
simply ignored.

There is similar problem with local files. Save the same html file on your local 
machine and make 2 copies - 1 with a .html extension, 1 with a .asp extension - 
then load them both in Mozilla. They are not displayed identically.

I'm going to attach 3 files:
- Session Transcript: a text file that shows the HTTP log between Mozilla and the 
server. Nothing looks wrong there.
- Sample page: save 2 copies of this file on your local machine, one as 
"login.html" and one as "login.asp".
- Testcase: save it on your local machine and open in Mozilla.

Changed summary line from "follow-up page to log-in or log out is blank" to "URLs 
without .html extension are not displayed". Set P1/Blocker because we can't use 
the Query page on Bugzilla. Reassigned to Parser/harishd because it doesn't seem 
to be a NetLib problem.

Comment 4

[Pierre Saslawsky]

Attachment: Session Transcript

Comment 5

[Pierre Saslawsky]

Attachment: Sample page (save as "login.html" and "login.asp")

Comment 6

[Pierre Saslawsky]

Attachment: testcase (save locally and open in Mozilla)

Comment 7

[harishd]

Johng, the follow up page 
(Javascript:featureWin('http://www.quote.com/quotecom/auth/login.asp','login',45
0,350); ) being blank page could be related to bug 36081.

Comment 8

[rbs]

Dup with bug 44819?

Comment 9

[harishd]

Pierre, your test case seems to work for me. Could you please update me on this? 
Thanx.

Comment 10

[Pierre Saslawsky]

With 07/12 builds, it works on Win98 but not on the Mac.

Harish, could you test on Unix? If the problem only happens on the Mac, I may be 
able to help. As I said, it makes the app unusable because too many forms just 
don't load.

Comment 11

[harishd]

I don't see the problem on Unix either.  Pierre, I might need your help to see
this no MAC.

BTW, parser doesn't do any platform specific task.  I think the problem could be
somewhere up in the webshell level. CC ing Jud.

Comment 12

[Judson Valeski]

definately not webshell related. this is most likely nsMIMEService related. 
Note: my mac works fine w/ bugzilla query page, build from this morning.

Comment 13

[Scott MacGregor]

the mime service is just a list of hard coded file extension to content type
mappings. Nothing non-XP here.

Oh wait, actually there is a small part that's mac specific. Davidm wrote a
snippet of code to interact with internet config to determine the content type
for file extensions. Maybe his code is getting in your way?

Even if that were the case, if the content type coming back from the server is
indeed "text/html" then the http channel should be telling the world that's the
content type and not even bothering to look at the file extension.

Comment 14

[Judson Valeski]

possibly related. 39797

Comment 15

[Pierre Saslawsky]

Reducing priority because the different web pages work for me now.

We still have the problem with local files as shown in my testcase.
Reassigning to myself to investigate on the Mac or try to find a XP testcase.

Comment 16

[Pierre Saslawsky]

Changed summary from "URLs without .html extension are not displayed at all" to 
"[mac]local files without .html extension are not loaded correctly".

Reassigned to Networking. See my comments from [2000-07-10 02:38] about local 
files: it's the only remaining problem.

Comment 17

[Gagan]

gordon can you investigate this? thx.

Comment 18

[Gagan]

getting on the right radar.

Comment 19

[gordon]

Looks like nsUnknownDecoder never gets a chance at files with a type of TEXT and 
no extension. nsMIMEService::GetTypeFromFile sets the MIME type to text/plain 
when the file is opened, so nsUnknownDecoder never gets a chance to parse the 
data to determine if another type is more appropriate.  Here's my proposed fix, 
that I'll check in as soon as someone reviews it.


Index: mozilla/netwerk/mime/src/nsMIMEService.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/mime/src/nsMIMEService.cpp,v
retrieving revision 1.35
diff -r1.35 nsMIMEService.cpp
42a43
> #include "nsMimeTypes.h"
221c222,226
<      return info->GetMIMEType(aContentType);
---
>      rv = info->GetMIMEType(aContentType);
>      if (NS_SUCCEEDED(rv)) {
>       if (nsCRT::strcasecmp(*aContentType, TEXT_PLAIN))  // Let nsUnknownDecoder try to do better.
>        return rv;
>      }

Comment 20

[gordon]

Above change checked in.

Comment 21

[Judson Valeski]

On my mac (os9) without this change, I'm able to open an html file lacking an
extension just fine (it's rendered as html).

Comment 22

[Pierre Saslawsky]

Judson, that wasn't the problem. To reproduce:
- save locally the attached testcase
- save locally 2 copies of the attached sample page, one as "login.html", the 
other as "login.asp"
- load the testcase
- click on the 2 links at the bottom
==> Bug: "login.asp" is displayed as a text file

I confirm that the patch from Gordon fixes the problem but I'm not marking 
Verified to let QA run similar tests if they have some.

Comment 23

[gordon]

Jud, in some cases, depending on the files type and creator codes, a file with no 
extension that rendered in 4.x as html would render as text in mozilla.  What 
were the type and creator codes of your test files?

Also...what Pierre said.

Comment 24

[Tom Everingham]

verified:
mac os9 10/27