64703 - Open unknown type local files as text rather than putting up unknown content dialog asking user to save

Status: VERIFIED WORKSFORME

(Core Graveyard :: File Handling, defect, P2)

Description

[Mike Pinkerton (not reading bugmail)]

- Save a webpage to disk with "File:Save As". Give it a name like "foopy"
- try to open it in mozilla (by file:open or dragging it in)

Expected:
- file should open

Actual:
- you get an "unknown content type" dialog asking if you want to save the file
to disk. If you rename the file to end in .html, it works fine. Lame!!!!

Comment 1

[Mike Pinkerton (not reading bugmail)]

we should just assume any file w/out an extension is text, or at least look at
the file type (which is TEXT in this case -- note that i had to change it, we
save files as ????, but that's another bug) before we put up the unknown content
type dialog.

Comment 2

[Simon Fraser [no longer active]]

We need to map file extension to mime type, then open the file using the MIME 
type. Another bug about this just went by...

Comment 3

[Simon Fraser [no longer active]]

sorry, map file _type_ to MIME type

Comment 4

[timeless]

filing dupes of dupes of bugs --lame-- via bug 63970.

*** This bug has been marked as a duplicate of 45441 ***

Comment 5

[Mike Pinkerton (not reading bugmail)]

after talking to pchen, and looking at 45441, this is a different bug.

lame.

Comment 6

[Mike Pinkerton (not reading bugmail)]

-->pchen

Comment 7

[Paul Chen]

Marking nsbeta1+, p2, mozilla0.9.1

Comment 8

[Paul Chen]

Umm, so like this only happens on '????' type files using 2001041908 mac build.
Now that ccarlen fixed the default saved type to be 'TEXT' and also hooked up
internet config support (I think), I believe this bug is a lot less severe.

Comment 9

[Paul Chen]

Doing as Pinkerton proposes and map '????' files to 'TEXT', just set the file 
type to 'TEXT' if it's '????' in nsExternalHelperAppService::GetTypeFromFile() 
after the call to macFile->GetFileTypeAndCreator( (OSType*)&type,(OSType*) &
creator ). I'd post a diff, but I think we'd pick up Bill Law's patches for 52454 
which I have in my tree. So the code was like this:

#ifdef XP_MAC
  nsCOMPtr<nsILocalFileMac> macFile;
  macFile = do_QueryInterface( aFile, &rv );
  if ( NS_SUCCEEDED( rv ) && fileExt.IsEmpty())
  {
	PRUint32 type, creator;
	macFile->GetFileTypeAndCreator( (OSType*)&type,(OSType*) &creator );
  	nsCOMPtr<nsIInternetConfigService> icService 
(do_GetService(NS_INTERNETCONFIGSERVICE_CONTRACTID));
    if (icService)
    {

now looks like this:

#ifdef XP_MAC
  nsCOMPtr<nsILocalFileMac> macFile;
  macFile = do_QueryInterface( aFile, &rv );
  if ( NS_SUCCEEDED( rv ) && fileExt.IsEmpty())
  {
	PRUint32 type, creator;
	macFile->GetFileTypeAndCreator( (OSType*)&type,(OSType*) &creator );
+	// if file type == '????', set type to 'TEXT' to prevent
+	// unknown content dialog from showing up
+	if (type == '????')
+		type = 'TEXT';
  	nsCOMPtr<nsIInternetConfigService> icService 
(do_GetService(NS_INTERNETCONFIGSERVICE_CONTRACTID));
    if (icService)
    {

Comment 10

[Paul Chen]

Ok, just talked to Pinkerton about this bug, changing summary to "Open unknown
type local files as text rather than putting up unknown content dialog asking
user to save"

Comment 11

[Paul Chen]

Attachment: mac specific fix in nsExternalHelperAppService::GetTypeFromFile()

Comment 12

[Simon Fraser [no longer active]]

Is this a dup of 75758? I'm worried that we're sprinkling these kinds of fixes 
all over the place, rather than having a planned strategy for dealing with 
extension-less files. Both Samir and dougt have been doing similar things 
recently.

Comment 13

[Paul Chen]

Just attached mac specific fix. First, if the file has an extension, call 
GetTypeFromExtension(), this will look up extension in the "mime info cache". We 
have to do this otherwise file types, like xul, which are registered this way 
won't work. If that doesn't succeed, then call Internet Config for a match on 
type and creator. If that first call doesn't succeed, then set type to 'TEXT' and 
call Internet Config again.

So now, any local file whose type can't be determined will be loaded as text.

And, yes, this bug is cross platform, actually. If we wanted a more XP fix, I 
would still put the call to GetTypeFromExtension() at the top, leave a middle 
section for platform specific stuff, and at the end, have the last resort case 
where we return "text/plain" in aContentType.

Actually, I just realized we could just set aContentType to "text/plain" and not 
incur the second call to the nsIInternetConfigService.

Comment 14

[Paul Chen]

Simon,

75758 looks more like determining content downloaded from the net. This bug is 
specifically to prevent the #*&$^#$*&#^$ unknown content dialog coming up and 
asking you to save a file you ALREADY have stored locally. In fact, the user 
explicitly dragged the file into a browser window.

Comment 15

[Simon Fraser [no longer active]]

Why is loading from the net different from loading from the hard drive?

Comment 16

[timeless]

because it doesn't make sense to ask the user to save a local file when it's 
clear they want to open it?

Comment 17

[Simon Fraser [no longer active]]

I meant in terms of implementation, not user experience.

Comment 18

[Paul Chen]

That's something to ask the folks behind necko and uriloader. Actually, it 
currently works that way. If it's an unknown content type off the net or on the 
local drive, we always ask the user for a helper app to use or to save to disk.

Comment 19

[Conrad Carlen (not reading bugmail)]

A good point was made on bug 75758 though - to look at the contents of the file
to try and determine what it is. For opening local files, we need different
handling than from the net. I'd say we NEVER want to bring up the unknown
content type handler. I think we should, in more or less this order:
1. Look at the file suffix
2. Look at the file type
3. Look at the contents of the file (as suggested in bug 75758)
4. If we still don't know, alert the user and ask if they want to open it as TEXT

Having necko/URI loader handle local file much differently than the net might be
tough.

Comment 20

[Paul Chen]

That's all fine and dandy, but there are different ways that we try to determine
file type. For local files, I believe we use GetTypeFromFile(). And that's where
I think we should supress trying to put up the unknown content dialog.

Comment 21

[Conrad Carlen (not reading bugmail)]

Since GetTypeFromFile() already does step 1 and 2 I mentioned, step 3 could be
hooked into that if we really wanted to be good. Until then, supressing the
unknown content dialog by saying the type is TEXT would be a big improvement.

Comment 22

[Marko Macek]

It would be nice if the unknown content dialog had an option to view in navigator.

Comment 23

[selmer (gone)]

Let's finish this up and get it off the beta stopper list.  Wouldn't hold for
this...

Comment 24

[Viswanath Ramachandran]

nav triage: moving to m0.9.3. 

Comment 25

[Paul Chen]

nav triage team:

Yes, we suck. If we've been willing to let this languish this long, what's 
another milestone between friends? Marking mozilla1.0

Comment 26

[benc]

How much more Mac users can tolerate is going to depend on whether or not this 
happens in MacOS X... Mac OS was the first place most people got to use drag and 
drop in applications...

Comment 27

[sairuh (rarely reading bugmail)]

spam: over to File Handling. haven't changed the current owners, but i did take
qa contact for the nonce. pls do retriage/reassign if needed.

Comment 28

[Jesse Ruderman]

See also bug 21985, which would also fix a similar problem for plain text 
*remote* content that happens to have a strange mime type.

Comment 29

[Paul Chen]

saved www.mozilla.org as file "foopy" and used file->open file... and it loads
fine, no download dialog. marking w4m

Comment 30

[sairuh (rarely reading bugmail)]

mass verification of WorksForMe bugs: to find all bugspam pertaining to this,
set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. that it's still a problem with ***recent trunk builds*** on the all
appropriate platform[s]

b. provide clear steps to reproduce (unless a good test case is already in the
bug report), making sure it pertains to the original problem (avoid morphing as
much as possible :)