- 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!!!!

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.

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

sorry, map file _type_ to MIME type

filing dupes of dupes of bugs --lame-- via bug 63970. *** This bug has been marked as a duplicate of 45441 ***

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

-->pchen

Marking nsbeta1+, p2, mozilla0.9.1

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.

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) {

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"

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.

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.

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.

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

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

I meant in terms of implementation, not user experience.

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.

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.

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.

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.

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

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

nav triage: moving to m0.9.3.

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

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...

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.

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

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

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 :)