45441 - [Mac] html files saved without .html extension are viewed as plain text

Status: NEW

(Firefox :: File Handling, defect, P3)

Description

[Joseph Elwell]

If I open home.netscape.com then do Save Page As...
and save the file as "testing". When I open that file in Mozilla I see the HTML
code (as plain text). If I open the file in N4.x then I see the HTML web page
just fine with pictures... etc. I tried this on mac 2000071310.

windows 2000071208 seems to view html, regardless of it's extensions, just fine.

i'm putting this in XP Apps, because law already has a few Saving html type bugs. :)

Comment 1

[verah (gone)]

Nav triage team: [nsbeta3+]

Comment 2

[Bill Law]

I'm handing this off to Paul Chen 'cause he knows the Mac stuff (and has 
recently implemented stuff that can help out here).

I think what we need to do is cause the mime-type of the resulting file to be 
set to text/html.  The easiest way to do this is to add a "string mimeType" 
parameter to nsIStreamTransfer::SelectFileAndTransferLocationSpec.  The 
implementation of this method would then have #ifdef MAC/#endif code that set 
the mime-type.

All the callers of this method would have to be changed to pass in either the 
real mimetype, or, an empty string.

There may be some complications in some cases.  E.g., when doing "Save Link 
As..." from the context menu, we don't know the mime-type; we should probably 
guess it in that case from the file/url "extension."  Another example is "Save 
Image As..."; I'm not sure we remember the real image mime-type (but maybe we 
can just infer one from the extension again).

Paul, let me know if you need help hacking the stream transfer or unknown 
content type handler code.

Comment 3

[Phil Peterson]

PDT thinks this is a P3 since there's an obvious workaround. We think it might
be a P2 to fix the saving side so that .html is prefilled for the user, which
doesn't happen today.

Comment 4

[Paul Chen]

This looks like a dupe of bug 44627 (or bug 44627 is a dupe of this one)

Comment 5

[johng]

nav triage team:
edgecase, so nsbeta3- at this point in this schedule

Comment 6

[Paul Chen]

nav triage team:

Annoying, but not a beta1 stopper, marking nsbeta1-

Comment 7

[Jesse Ruderman]

*** Bug 63970 has been marked as a duplicate of this bug. ***

Comment 8

[timeless]

*** Bug 64703 has been marked as a duplicate of this bug. ***

Comment 9

[Simon Fraser [no longer active]]

So how do we set a MIME type on the file from its file type?

Comment 10

[Paul Chen]

Marking nsbeta1- bugs as future to get off the radar

Comment 11

[Simon Fraser [no longer active]]

This is a pretty serious bug for Mac users, who are used to saving files without 
file extensions. It will also break composer users who do the same.

Comment 12

[Greg K.]

Documents should only be displayed as HTML if there is some identifying
metainformation associated with the file that indicates that it is HTML.
Examples of such metainformation would be the ".html" filename extension, a type
of "HTML" under Classic, or whatever the new mechanism is under OS X.

If it's just a plain text file, Mozilla should display it as such.

If you can somehow associate the text/html MIME type with the file, then that's
great, and the way to go.

Comment 13

[sairuh (rarely reading bugmail)]

spam: over to File Handling. i have not changed the assigned developer [or the
other fields for that matter], so if anyone realizes that a bug should have a
more appropriate owner, go ahead and change it. :)

Comment 14

[Jaime Rodriguez, Jr.]

Removing adequated PDT grafitti.

Comment 15

[Asa Dotzler [:asa]]

->default owner

Comment 16

[Bill Law]

Reassigning to Adam.  I think the fix has to be implemented in
nsWebProwserPersist; it should set the Mac type/creator appropriately for known
mime types (html at a minimum).

Comment 17

[Simon Fraser [no longer active]]

There isn't traditionally a Mac file type for HTML, so, without the file 
extension, the only thing we can do is to sniff the contents of the file. 4.x 
does this, I believe.

Comment 18

[Bill Law]

restoring target milestone

I'm not sure why extensionless files open as html on windows but not Mac.  I
thought the mac  filetype/creator fields influenced that.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Isn't the problem here just that IC is coming back with a type for us when we
ask it for one?

Comment 20

[Cristan Meijer]

When you single click on a file which has got an extension unknown to mozilla
(like, RAR, MSI and so on) it is also displayed as plain text. When you press
right mouse button, and Save As, you are default saving the file with .txt as
extension. This could be very annoing.

P.S. I use mozilla 1.4RC2 on windows 2000 and XP

Comment 21

[Christian :Biesinger (don't email me, ping me on IRC)]

Cristan Meijer: That is not true. I assume you are refering to http urls, in
which case it depends entirely on the mime type the server sends to mozilla.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Is this a problem with current builds?

Comment 23

[Andrew Thompson]

Not really, from what I've seen with Jaguar and Moz 1.4. While the file has no
icon, and can't be double clicked or dragged onto mozilla in the dock, if one
drags it directly into Mozilla's window, it does display as HTML now.

Comment 24

[Boris Zbarsky [:bzbarsky]]

OK.  Well, I don't think I should be resolving bugs I can't test worksforme, so
some mac person should take the initiative there, if needed.

Comment 25

[Asa Dotzler [:asa]]

worksforme with 2004020305 Mac SeaMonkey build on 10.3

Comment 26

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This is certainly still a problem with current Camino and Firefox builds; a file with type TEXT and no extension is loaded, but it is rendered as raw plain text rather than HTML.  Reopening.

Can we do extra sniffing on these extensionless, type TEXT *local* files and then say they are text/html (rather than saying *all* files of type TEXT are html files, which is how I read comment 2)?

Safari handles this as Mac users expect (as did 4.x), and it's a common complaint against Firefox and Camino made by many Mac users thinking of switching from Safari.  Apparently people still *create* these types of files in 2007 (not just load old ones)!

Comment 27

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I should add, I know this didn't work properly in 2004--I had looked at this very report before Asa closed it--which is why I'm reopening this bug rather than filing a new one.

Comment 28

[Boris Zbarsky [:bzbarsky]]

So here's the thing.  Right now, what we do for such files in nsFileChannel is call GetTypeFromFile on the helper app service.   GetTypeFromFile calls nsInternetConfigService::GetMIMEInfoFromTypeCreator, which goes into Mac-specific code that I don't really know.  Someone who understands how that stuff (e.g. Internet Config) is supposed to work should trace through it and see what's up.