Closed Bug 179942 Opened 23 years ago Closed 22 years ago

loading mozilla document with no extension assumes wrong file type

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Platform:
PowerPC
Mac System 9.x
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: jlfenton65, Assigned: law)

Details

User-Agent: Mozilla/4.0 (compatible; MSIE 5.15; Mac_PowerPC) Build Identifier: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.2b) Gecko/20021016 When a web page is saved as a complete web archive without giving it a file extension in the filename, when you try to reload it, Mozilla thinks it is a PDF file instead of a web archive. Reproducible: Always Steps to Reproduce: 1. Save any page as a complete web page. No extension on filename. 2. Switch to Mac desktop and double click on saved web archive. 3. Actual Results: Mozilla asks for the user to select a helper program to display the file of type PDF is a PDF helper hasn't been selected. It tries to use the PDF display helper program if it has. Expected Results: Shown the saved web page. This is in the default theme of Mozilla. It does not crash the Mac. If you give the web archive an extension, even one that isn't in the MIME list, it works as it is supposed to. It only effects files with no extension in the name.
Hum. Mac OS 9.1. Build 2002111308 I don't undestand why it try to load it as a PDF file what is the mime/type shown by the dialog ? For me the download dialog show: type: "Text Readme" mime/type: application/text The type/creator if the file is "TEXT/MOZZ". In my internet control panel i have 5 entries without extension - mimetype: application/applefile Description: Apple Single File - mimetype: Netscape/tn3270 Description: Netscape tn3270 - mimetype: Netscape/Source Description: Netscape Source - mimetype: Netscape Telnet Description: Netscape/Telnet - application/octet-stream Description: Untyped binary Data Theese entry are not used I have 5 entries with "Text Readme" Description extension: .1st mime/type: application/text extension: .rme mime/type: none extension: .readme mime/type: application/text extension: .readme mime/type: application/text extension: .me mime/type: application/text Changing the description, i found that it use the first of theese entries I suspect that mozilla for a TEXT file use one entry (the first ?) with a application/text mime/type. Note that in this situation, NS4 works correctly, but it don't use the internet control panel, and have probably a special code to handle this
The reporter sent me a hard copy of the dialog. The mime/type is really application/pdf What is the algorithm used by mozilla for opening local files ? i suspect now a random acces to the internet config panel.
For local files on the mac? The algorithm is as follows: 1) Get the extension from the filename ('' in this case) 2) Get the type/creator from the file 3) Call ::ICMapTypeCreator() using the type, creator, and a filename of "foobar.ext" ('foobar.' in this case) 4) If this succeeds, get the MIMEType member of the result and use that as the type. 5) Otherwise, if extension is not empty use that to do some further (irrelevant in this case) 6) Otherwise, fall back on sniffing the data. The only way the sniffer will come out with "application/pdf" for data is if the data starts with the string "%PDF-". Does it? It not, sounds like ::ICMapTypeCreator() is confused (this is part of the system API, not a Mozilla function).
The file name is "tp01", the file type and creator are TEXT/MOZZ, and the first line of the file is <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 It is a web page saved as a "complete" page. Mozilla should be able to recognize it. It DOES if you give it an extension, even if that extension has no helper attached to it. It is only when it has no extension that it thinks it to be a pdf file.
Sounds your internet config is returning that MIME type for files with no extension and of type/creator TEXT/MOZZ... This is about where my knowledge of the situation ends; I know the Moz code but not the exact workings of the Mac API... ccing someone who may.
I Agree with comment 3. Very Clear. Now i know why i try to launch simple text On My Mac ICMapTypeCreator returns an entry containing TEXT/ttxt, extension 1fst, application/text with an input of "TEXT/MOZZ", "foo." This is because i have Kept my internet control panel my setting for NS4 I had not a "TEXT/MOZZ" entries but only "TEXT/MOSS" entries I have changed them and now it works correctely. I suggest in Mozilla preferences a button named "Update Internet control panel settings". There is some thing equivalent in windows, isn't it ? If it is not already done, we cant create en enhancement report for Mozzilla, or transform this one For the reporter i suggest to check Carrefully it's internet control panel settings, specially the entries with an Acrobat Icon, and add entries for Mozilla
The only things mapped to Acrobat Reader in my Internet Control Panel or the File Exchange are files with a .pdf extension or a file type of PDF. I have no entries for either TEXT/MOZZ or TEXT/MOSS. I'm not going to add them either. I'm going to serve as the "typical" computer user: when confronted with this problem, if you ask them to add internet entries for Mozilla, they'll laugh in your face and switch to Explorer. It's got to work without the user needed to access control panels or system configurations. That isn't the "Mac way." As a programmer, I could probably MAKE it work, but then you'd never find the problem. I'm not changing ANYTHING until the REAL problem is unearthed.
Joe, do you have _any_ TEXT/something entries in that control panel? I'm still trying to figure out why we're ending up with a PDF type here. I've only found one reference that sorta describes ::ICMapTypeCreator() so far, and according to that a successful match must have the same type as the thing we are matching against, and having the same creator and extension are nice but not required. There's also some mumbling about an outgoing flag.. In any case, if you could let me know what TEXT/* types you _do_ have defined and more to the point whether PDF is one of such, that would be much appreciated...
Don't focus about extensions, you file has no extension. Focus about mime/types Search an entry with "TEXT" type and an "application/pdf" mime/type - First Check the entries with an Acrobat Icon. See if you have a TEXT/CARO entry, with an application/pdf mime/type - If you don'find Check all your entries, searching a TEXT/Something entrie with an application/pdf mime/type. The icon displayed is the icon of the owner it is not the icon of the launched application. Boris, is there a place in Mozilla site where such algorithms are described ? It may be very usefull for bug reporting.
Jean-Pierre, I assume the first part of the comment was to Joe? As for documentation... There's http://mozilla.org/catalog/libraries/ and then there's http://lxr.mozilla.org/seamonkey/ (this latter is usually the most useful, unfortunately...)
I have two translations for files of type TEXT without an extension: TEXT/ hscd is translated to BBEdit Lite, and TEXT/OMEG is translated to BBEdit Lite. I have two entries for pdf: PDF/hscd is translated to Acrobat Reader, and PDF/dosa is translated to Acrobat Reader. All other translations are by extension with only .pdf being translated to Acrobat Reader. Probably some strange bug in the 9.2.2 mime translation. :^} Something like, TEXT/MOZZ -> TEXT/hscd -> PDF/hscd -> Acrobat Reader I've seen stranger things.
sdagley? pinkerton? Any ideas on what this function is _supposed_ to do?
Joe, compress your internet preferences in stuffit or zip format, and create an attachement with it
Joe i have received your preferences. Note that you can make attachements directely with this page, using the above link "Create a New Attachment". As i said in comment 9, you have a .pdf entry with TEXT/CARO as type/creator Extension: .pdf Type:TEXT Creator:CARO Application name: Acrobat Reader Description: PDFFiles Mime/type: Application/pdf This explains why Acrobat is launched I have deleted this entry, but this not corrects really the problem because after the delete, the choosed entry is: Extension .apd Type:TEXT Creator: ALD3 Application name: "Aldus PageMaker" The only way to resolve this without deleting all TEXT entries is to add an entry for Mozilla Duplicate exactely the existing entries for .htm and .html and replace MSIE by MOZZ So it is not a bug, But i suggest strongly what i said in comment6: Add in Mozilla a way to add MOZZ entries in the internet control panel (under user control, because Mozilla is not MSIE). It is a common thing in Mac Softwares (Stuffit, Graphic Converter, QuickTime Control Panel, and Many others) This is also possible on Windows, but without duplicates entries. Many softwares open a dialog to ask if the user wants to change associations
Of course another option is to add a TEXT/MOZZ entry to IC that either maps the type to text/html or sets it to the application/x-unknown-content-type hack that will allow our content-sniffing to kick in instead. Confirming the bug; hoping that one of the mac people on the cc list will tell me something useful, because I have no idea what the platform conventions for this sort of thing are on the mac.
Status: UNCONFIRMED → NEW
Ever confirmed: true
You wrote: ------ As i said in comment 9, you have a .pdf entry with TEXT/CARO as type/ creator Extension: .pdf Type:TEXT Creator:CARO Application name: Acrobat Reader Description: PDFFiles Mime/type: Application/pdf This explains why Acrobat is launched ------- No it doesn't... how does an association of .pdf to TEXT/CARO have ANYTHING to do with a file with NO extension with a type/creator of TEXT/ MOZZ? A match of the two is obviously a bug on SOMEONE'S part. TEXT/ MOZZ does not equal TEXT/CARO in any book I've ever read. I'd say at the least that the Mac version should check the file type/creator itself FIRST and attempt to load the page if it belongs to Mozilla (anything/MOZZ). If it's NOT got a MOZZ creator, THEN try to use the mime mapping. Seems pretty straight forward to me. Mozilla should be trying to load it's own stuff first and not trying to pass it off. The Mac obviously thinks so... when you double-click a file of creator MOZZ, it launches Mozilla to deal with it just fine - it's Mozilla that's trying to pass it off to Acrobat. Anytime my program is asked to open a file, it checks the creator and uses the type to determine how it should be handled. That's the whole point behind having file types on the Mac - it gives an application a quick way to determine what it should do with its project/data files.
> how does an association of .pdf to TEXT/CARO Very simply. I finally found some documentation on this. See http://www.quinn.echidna.id.au/Quinn/Config/Prog_Docs.html#HighLevelRoutines, the part about ICMapTypeCreator. > TEXT/MOZZ does not equal TEXT/CARO in any book I've ever read. It does according to Internet Config if there are no matches on TEXT/MOZZ or on the extension of the file (which is nonexistent, hence unmatchable, in this case). Since there is no entry for TEXT/MOZZ, the first entry for TEXT/something is chosen (first in whatever the internal ordering is; probably alphabetical). One issue here is that Mozilla's handling of everything is based on MIME types because it's a _web_ browser. So when it gets some data (eg a file) is first reaction is not "should I handle this?" -- it knows it should be trying to handle it. Its first reaction is "How do I handle this?" (because we support lots of different data types, from HTML to images to PDF (with a plugin)). So to figure out how to handle it, we need to know what sort of data we're dealing with. Note that the Mac type/creator system is patently insufficient in this case; the lack of a way to differentiate plaintext and HTML via the type/creator system is a big problem, for example (this is made worse by the fact that Apple seems to demand that HTML be stored with a TEXT type; I could probably find the apple.com reference on that if people really care). So the core problem is that it's not enough for Mozilla to know that the file has a type of MOZZ because we handle so many types. We have to know the mime type. We get the mime type, then throw away the MOZZ part, because the parts of mozilla that handle content dispatch are cross-platform and key off the mime type exclusively. Even if they were not, we would have issues anyway (eg we would handle HTML internally, but as text plain, because that's the mime type that happened to be returned for TEXT/whatever by IC). So it seems that we have a few issues: 1) We can't trust ICMapTypeCreator at all because it will return completely garbled data fairly often (even with an extension it would do this, by the way, if the extension were not known to IC). 2) We can't trust going through the IC database using the low-level functions because I cannot think of a way to devise a reasonable weighting algorithm that would actually work for this case of no extension (and not detect an HTML file with no extension as plaintext or something like that). So it seems to me that the entire type/creator system is entirely useless to us. Or am I missing something? Would adding a TEXT/MOZZ entry help? If so with what mimetype? Should we be using a different API to IC? Would sniffing the file data before going out to IC work? I've been considering doing that anyway; the only thing that has been stopping me was that on "some OSes" (BeOS and MacOS were the examples I had in mind) the OS has pretty accurate information on the filetype. Since this is not true on the Mac, as far as I can tell, and since it's patently not true on Windows or Linux, I'm tempted to just data-sniff first and foremost and only go out to the OS if the sniffer turns up nothing... Someone who actually knows mac programming help me out here; I'm just a poor Unix developer trying to make us do the right thing (which we're manifestly _not_ doing now for all the above reasons). Here's hoping people get into the office on Monday and actually read their mail...
I'm reading my mail but I haven't had any caffeine yet today nor have I read every line of this bug report but I will comment that it sounds like ICMapTypeCreator isn't working right as Mozilla does register the TEXT/MOZZ with the OS via its BNDL resource. Or maybe ICMapTypeCreator just doesn't use desktop database in which case it's of little use as it would only know about things that were explicitly registered.
Well, I vote you do the data-sniffing first. It seems to be the only way to resolve the problem. If the data-sniffing fails, then try the mime type.
Sorry there is no problem. Data sniffing may be wrong. And Mozilla is unable to sniff all file formats and will return incorrect results. The only way to resolve this is to have a correct IC Database. Is it so difficult to add en entry ?
> And Mozilla is unable to sniff all file formats and will return incorrect > results. As it happens, this is only true when sniffing for HTML and I plan to fix that soon anyway. Other than that, our sniffing is very conservative. See the code in nsUnknownDecoder.cpp. If a correct IC database is what is required, we should be creating a correct IC database. That is, Mozilla should add whatever entries are needed. My personal vote is to wait till sdagley has had his coffee and has time to think about this a bit. ;)
Coffee? Ugh! I like my caffeine cold :-) As for thinking about it, I have and I'm sure my answer is going to annoy a subset of Mozilla users. That answer is, as far as Netscape is concerned, the upcoming maintenance release to Netscape 7.0 will be the final Mac release for anything prior to Mac OS X. If this bug is specific to Mac OS 9 and earlier as marked it's not going to get any attention from the Mac folk at Netscape. I believe we've arranged for an external developer to address pre-OS X bugs but I need to find out if that's in fact true and how bugs are handed off to them. If this turns out to be a Mac OS X bug as well we have an additional problem in that Apple wants us to use the LaunchServices APIs rather than the Internet Config APIs under OS X. In theory these APIs maintain seperate databases of info and have a bi-directional communication to keep them in sync. In reality we know that, at least in 10.2.x, there are instances where this does _not_ happen. There's also the issue that Apple has decreed that file extensions are the only file type mapping system that should be used for OS X. I can't begin to stress what a bad idea I think that is. Unfortunately, due no doubt to that mindset, LaunchServices provides no API to get a type/creator pair from a mime type. One might think since OS X is *nix based the magic number system would come into play to identify files but so far I have seen no signs of OS level support for that.
OK. So the real answer is that we need to reconsider/rewrite all the mac mime service code anyway, eh? ;)
I just took a look at a MSIE 5.x web archive. They use a file type/creator of WAFF/MSIE. Why is Mozilla trying to use TEXT as the type for a web archive? Its not a text file, or an html file... it's a complete web page with pages and scripts and style sheets and etc. Use a different file type like Explorer and look for it during the open command like everyone else. I suggested this back in the beginning.
Wait. If we save as "html only" the problem does not happen?
Not that I ever use the app myself but I understand that Mac IE's web archive is actually a cache file. Sounds like a slick idea for bundling up a page/site but we don't have that capability (yet)
I just checked. Yes, it has the same problem with html-only. The problem is more serious than I thought - any TEXT/MOZZ file is coming up as whatever your first TEXT entry is. In my case, PDF.
This bug is targeted at a Mac classic platform/OS, which is no longer supported by mozilla.org. Please re-target it to another platform/OS if this bug applies there as well or resolve this bug. I will resolve this bug as WONTFIX in four weeks if no action has been taken. To filter this and similar messages out, please filter for "mac_cla_reorg".
Since Mozilla is no longer supported on Mac OS X pre-OS X I am attepting to test the remaining open bugs (all 175 of them). The test client will be the Mozilla (SeaMonkeys) 1.6 running Mac OS X 10.3.2 Result/Status: Bug no longer exist. File opens in default web browser
Mac OS Classic bug. Marking WONTFIX.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.