Closed Bug 234245 Opened 21 years ago Closed 21 years ago

No way to add arbitrary file types without hand editing MimeTypes.rdf

Categories

(Firefox :: Settings UI, defect)

Product:
Firefox
Component:
Settings UI
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: lrivers, Assigned: bugzilla)

References

Details

Attachments

(1 file)

Attachment with MIME type application/x-zip
647 bytes, application/x-zip
Details 
User-Agent:       
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040213 Firebird/0.8.0+

Since Mac Firefix does not have application/octet-stream as a built-in and I was
tired of seeing the "what do I do with this file" dialogs, I searched in vain
for a way to add arbitrary file types.

Reproducible: Always
Steps to Reproduce:
1. Open preferences
2. Go to Downloads pane
3. Look for "add" or "new" button in the File Types area

Actual Results:  
I looked, did not find. Ended up digging around and finding the MimeTypes.rdf
and adding the octet-stream mime type by hand with a text editor.

Expected Results:  
Had a way to add file types

See also <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=234243">234243</a>
This is by design.  This is something that no normal user would ever use, and 
would normally be set as they encounter the files in question.

Eventually someone will write an extension to allow this, but the percentage of 
the user population that knows what application/octet-stream means is small.  
Very small.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
I question whether eliminating the ability to add file types solves any problems. Why was this 
functionality removed?
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Unless you have information or reasoning that wasn't considered, don't try to
overrule decisions.

This is functionality that most users wouldn't touch, let alone understand.  If
you can convince me that this fits into the concepts expressed in
http://www.mozilla.org/projects/firefox/ue/philosophy/realities.html, then I
will reopen this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → WONTFIX
How does allowing users to add a file type violate some principal of ease of use? How is hand-editing a 
complex XML document a superior user experience? I only discovered this was an issue after 2 bugs in 
the Download scheme forced me to edit my MimeTypes.rdf. This is functionality that exists in 
2004021205 build of Mozilla so why shouldn't it be in Firefox? Did I explain the problem so poorly that 
you are just completely misunderstanding it. What I'd like to see done sounds like a solution to a 
problem not the source of one.

Here's a quote from the document you referred me to:
"they will only make  configuration changes when the need arises (that is, when they wish to optimize 
their browser for a non-standard scenario, particular to their usage patterns.)"

Say, for example, when the standard configuration does not *adequetly* support downloading a file 
type that individual user needs access to many times per day?

Here's another one:
"In much the same way as you're  not constantly in Microsoft Word's Options dialog box tweaking Auto-
Save details - you just expect Word to do the right thing so  you can focus on writing your document"

Case in point, in Word, you have the *ability* to alter details of Auto-Save. In Firefox you shouldn't need 
to add octet-stream or Mac OS X Disk Image file support (seperate bug report), nor should the lack of 
that support result in a  "How do I handle this file" dialog with all its options disabled.  By the same 
token, Firefox should not opt to remove a user interface for addressing those issues, should they exist.
Please also review this document which lists many of the issues I refer to as development priorities.

http://www.mozilla.org/projects/firefox/ue/downloads/
Please also see this thread:
http://forums.mozillazine.org/viewtopic.php?t=16497
if there are problems with how the existing functionality as designed is
working, then we need to fix those issues, not create UI for workarounds.  Less
than one in one hundred normal users even comprehend the concept of MIME types,
let alone known what text/html vs. text/plain does.  If 99% of the population
doesn't know how to use it, its useless UI.  (If you question this, go looking
for how many bugs are filed against Mozilla as a result of binary data being
sent as text/plain.)

If application/octet-stream should be handled a certain way on Mac, the other
bug will need to be fixed.  If the default configuration is inadequate for
users, the solution is to fix the default configuration, not implement UI that
requires user knowledge to fix it.  The goal is to create a UE that doesn't
require interacting with the options dialog, instead it evolves to fit your
usage.  This type of feature doesn't fit anywhere within the goal.

Also, Mozilla's prefs dialog is anything but a paragon of good design.  The
entire point of the original Phoenix project was to eliminate all of the useless
power user features and create a browser that works for and is understood by the
mass market.  This isn't a mass market feature in any sense.

It would be a good power user extension though, since some people like to do
oddball things with MIME types (like open text/plain in emacs, as a strange example)
I wasn't going to really revisit this, but I found this comment from Ben on the
MZ forums, sums it up better than I did:

"Also, when people talk about features in the UI, it'd be helpful if people
thought of the context in which they were using a feature, and what they were
trying to do, before insisting that a particular piece of UI is implemeted. For
instance, rather than just saying we need a new window for this, try and think
about your problem not as a lack of that window, but as the task you were trying
to achieve."
*** Bug 247890 has been marked as a duplicate of this bug. ***
*** Bug 248092 has been marked as a duplicate of this bug. ***
I wonder if this issue warrants some revisiting. Bug 248092 has given a context
where this would be useful. Personally, I don't really care either way, but we
should reconsider this decision and decide whether or not it still stands.
OS: MacOS X → All
Hardware: Macintosh → All
*** Bug 248092 has been marked as a duplicate of this bug. ***
I stand by my assessment of this bug.  If you try to open something where we
don't recognize the mimetype, a dialog appears asking how to handle said
mimetype.  That entry can be later changed as needed.

There is no need to be able to proactively add mimetypes, as they will be added
as needed.  If this is something that certain people feel is necessary, it could
certainly be implemented via an extension.
*** Bug 259990 has been marked as a duplicate of this bug. ***
(In reply to comment #13)
> I stand by my assessment of this bug.  If you try to open something where we
> don't recognize the mimetype, a dialog appears asking how to handle said
> mimetype.  That entry can be later changed as needed.

What if I want to change the default? I use only linux systems and there are
often new tools for an old purpose, e.g. new tools for displaying videos, or
audio files. Different people prefer different ways of achieving the same end:
why should they not be allowed to choose?

Mozilla has a nearly perfect solution. There is a 'helper' panel
(edit->preferences->navigator->'helper applications') that shows current
mappings and allows you to change them or add new ones.

ANY browser should permit such choice (unless you want to restrict the browser
to use by totally naive users, in which case it should NOT be promoted as a
general-purpose browser, which I thought it was meant to be (e.g. replacing IE),
but a 'least common denominator' browser).

Opera also provides a usable scheme for modifying or adding commands to run for
various types of fimes, though it does not call them 'helpers'.

The Mozilla/Opera solution is flawed because it assumes too much knowledge in
most users. Instead of assuming that everyone knows about all the mime types, it
should provide an interface that allows items to be clicked on to get
explanations and advice. It could even be a link to a general page on the
firefox site explaining what's going on and what the various categories and
extensions mean.

But despite being flawed, the mozilla/opera design is not as insulting as
telling users they are either too ignorant to be able to change anything or too
selfish in expecting a feature that that is essential only for a small
percentage of users. If it is essential for experts it should be provided.
(Often non-experts get help from people who know a little more. My wife often
asks me: 'how can I make this do so and so.')

I was *amazed* to see a discussion document about firefox claiming that it is
reasonable to assume that .doc files should be handled by MSWord. Is this a
microsoft employee??? There really are people who prefer Openoffice. Why should
they not not be able to choose?

More importantly one should not be lumbered with a *fixed* immutable mapping.
E.g. the right-click on the link could *always* allow an 'open with' option, so
that for instance if my normal handler for a file type doesn't cope with a
particular file (e.g. which does not conform to standards) then I can try a
different handler which is more tolerant, or something.

Although Firefox is my favourite browser in other respects, this whole area has
caused me so much frustration I am thinking of switching to opera, or just using
mozilla.

> There is no need to be able to proactively add mimetypes, as they will be added
> as needed.

Who is going to decide that they are 'needed'. Why can't a user have the freedom
to decide?
 
> If this is something that certain people feel is necessary, it could
> certainly be implemented via an extension.

If I knew how to program extensions this would be high priority for me. However, 
allowing users to say which tools should be invoked for which tasks seems to me
such a basic requirement for any web browser or file browser that it should be 
built in.

Aaron
(In reply to comment #15)
> (In reply to comment #13)
> > I stand by my assessment of this bug.  If you try to open something where we
> > don't recognize the mimetype, a dialog appears asking how to handle said
> > mimetype.  That entry can be later changed as needed.
> 
> What if I want to change the default? I use only linux systems and there are
> often new tools for an old purpose, e.g. new tools for displaying videos, or
> audio files. Different people prefer different ways of achieving the same end:
> why should they not be allowed to choose?

I have no idea what you're talking about.  Right now, we don't ship with any
predefined defaults on any OS.  If its a file type that hasn't been encountered
yet, we ask the user what they want to do.  If the file type is recognized, we
use the handler/action the _user_ has previously selected for that file type, if
they chose to always remember that action.  At any point, previous choices can
be changed or reset to ask the next time.

The scope of this bug is to allow a user to go into the UI for managing existing
known types and add a _new_ type by specifying mimetype information.  The reason
we don't need this is because if you never get anything with that mimetype, you
don't need it, and if you do hit it, you get asked at that time to choose how to
handle it.

Before you write a long passionate missive, please get your facts straight.
Aaron,

Unfortunately, the people holding the reins on this project are irrationally opposed to adding this 
functionality. It's too bad because I'd probably use Firefox more if it were a little more flexible in this 
regard.

It doesn't matter how much the people who are using it already want to be able to edit their mime 
types, or how eloquently you argue that you'd like to have it and why. They're going to treat you like an 
idiot, so I'd recommend dropping your campaign.
I don't think its irrational to refuse to add UI that's above the comprehension
level of our average user.  I do think its irrational to demand UI which doesn't
have a stated purpose other than a workaround to a behaviour issue.  See comment
8 if you feel like arguing more for this.  There might be an argument for not
showing the dialog and just going straight to save to disk in this case, but
that's nowhere near the scope of this bug.

As a note, we now special-case application/octet-stream since we now check
whether content sent as text/plain is actually binary data, and instead let
people save the file instead of displaying garbage.  So defining any handler for
that specific type, other than Save to Disk, is unsafe and wouldn't be allowed
by this UI even if we had an Add Type button.
(In reply to comment #16)

I apologise: I think I may have misread/misunderstood the bug description.

I wanted to report difficulty in getting firefox to change the way it treated
some file types. For some sorts of files it simply tried to save the file to
disk and would not give me any other option -- e.g. mp3.

I could not find anything in the preferences menus to allow me to change this by
specifying a new file type and indicate how I wanted it to be treated, as I can
in mozilla and opera.

So as instructed I searched for existing bug reports before starting a new one,
and I found this one. Now maybe I had misunderstood, and I should have started a
new bugreport for my problem.

I wrote:
> > 
> > What if I want to change the default? I use only linux systems and there are
> > often new tools for an old purpose, e.g. new tools for displaying videos, or
> > audio files. Different people prefer different ways of achieving the same end:
> > why should they not be allowed to choose?
> 
> I have no idea what you're talking about.  Right now, we don't ship with any
> predefined defaults on any OS.

Well, I had the impression from the behaviour I mentioned above that there was a
predfined default and it was not what I wanted.

Where is it coming from?

> If its a file type that hasn't been encountered
> yet, we ask the user what they want to do.  If the file type is recognized, we
> use the handler/action the _user_ has previously selected for that file type, if
> they chose to always remember that action.  At any point, previous choices can
> be changed or reset to ask the next time.

It's true that I had previously had that sort of experience in Firefox, but not
recently. So I thought the design must have changed, and this thread appeared to
be about whether the current design is right or wrong.

On reading the latest messages I now wonder whether the problem I have had could
be caused by the fact that as my small contribution to the Firefox effort I
frequently install new (nightly) versions in order to be a tester, since I have
neither the knowledge nor the time to contribute code.

Sometimes there is obviously a bug in the new version and I revert to a previous
version after reporting the bug if nobody else has.

Occasionally new versions cause me problems because old extensions stop working,
but usually they catch up later.

It may be that my problems come from not starting with a clean firefox directory
every time. However, that would be too unbearable because I have bookmarks,
passwords, useful cookies, etc. and I would lose them all.

So maybe one of the upgrades was incompatible with my previous preferences and
things stopped working properly, though I did not notice at first because most
file types were still being treated as I expected.

Is it better for people who are not prepared to start with a clean directory
every time not to test new versions?

Or is there a way to start with a new directory then import all important
preferences from the old one? (on Linux).

> The scope of this bug is to allow a user to go into the UI for managing existing
> known types and add a _new_ type by specifying mimetype information.  The reason
> we don't need this is because if you never get anything with that mimetype, you
> don't need it, and if you do hit it, you get asked at that time to choose how to
> handle it.

Alas that was not my recent experience, as explained above.

> Before you write a long passionate missive, please get your facts straight.

The facts are as I described them.

Why they don't fit what is supposed to happen is a mystery, unless my
conjectured explanation is the right one. Perhaps I should simply try to find an
older version of firefox that I can revert to and then wait for a new stable
firefox that does not give me the problem.

Sorry if I've introduced a red herring into this discussion.

Incidentally another problem of the same general sort that I have never been
able to solve is telling Firefox to treat latex files (.tex suffix) as plain
text and just display them. If I choose the 'open with' option there is nothing
that allows me to say 'open with firefox' i.e. just display the contents as
text. But this is not a new problem.
It's there in mozilla too.

I had thought, probably wrongly, that this was part of the same 'bug' being
discussed here.

Aaron
Best guess on the mp3 issue is that its being sent, mistakenly, as text/plain,
and we're recognizing that its not text, so we handle it like
application/octet-stream, which is really generic, and can't be relied on to be
any particular type of file.

As for the .tex files, it depends on how the server sends them.  If its as
something other that text/plain, it may do odd things depending on how the
server is sending them.
> Best guess on the mp3 issue is that its being sent, mistakenly, as text/plain,
> and we're recognizing that its not text, so we handle it like
> application/octet-stream, which is really generic, and can't be relied on to
> be any particular type of file.

As a user I generally don't care what mime-type the server says a file is. If I
tell the browser to open .mp3 files with a certain application I want it to open
all files ending in .mp3 with that application regardles if the server says it's
text/plain, application/octet-stream or some other mimetype. A user with less
computer knowledge than us discussiong this doesn't even know about mimetypes
but (s)he knows that he previously selected an application to open the .mp3
files he downloads and get angry that it doesn't work for all of them.

> As for the .tex files, it depends on how the server sends them.  If its as
> something other that text/plain, it may do odd things depending on how the
> server is sending them.

Once again, the user doesn't care about mime-types but file-extensions (.mp3,
.tex, etc).
Second, the original poster have a point. It's as far as I know impossible to
tell firefox to handle this type itself and just show the file.
Here is another situation I don't know how to handle (despite being *very*
experienced with the Web and with Mozilla):

A bugzilla entry has an attachment of MIME type application/x-zip, which is
correctly transmitted by the server (as seen with wget -S).  When I click on the
attachment link
(http://mucpseu2.muc.sdm.de:5023/bugzilla/attachment.cgi?id=624&action=view)
with Firefox 1.0.4 on Windows XP , I get a popup asking:

   You have chosen to open
      attachment.cgi
   which is a: CGI file
   from: http://mucpseu2.muc.sdm.de:5023

   What should Firefox do with this file?

This is nonsense, because I do not want to associate an action with CGI files
(attachments with different MIME types would all show as attachment.cgi in this
popup), but with the MIME type application/x-zip!  This seems to be impossible
with the present GUI.
Clicking on this attachment with Firefox 1.0.4 on Windows XP brings up a
useless helper application dialog.
Sorry, with the Bugzilla version used here (2.19.1+), the problem does not
appear, due to the fact that the HTTP response suggests a filename:

http response [
  HTTP/1.1 200 OK
  Date: Wed, 25 May 2005 10:31:08 GMT
  Server: Apache/1.3.27 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.12 OpenSSL/0.9.6b
DAV/1.0.3 PHP/4.1.2 mod_perl/1.26
  content-disposition: inline; filename="testfile.zip"
  Content-Length: 647
  Connection: close
  Content-Type: application/x-zip; name="testfile.zip"
]

The bugzilla version we use at work (2.16.4) only produces

http response [
  HTTP/1.1 200 OK
  Date: Wed, 25 May 2005 10:33:15 GMT
  Server: Apache/2.0.48 (Unix) DAV/2
  Content-Type: application/x-zip
  X-Cache: MISS from mucproxy.muc.sdm.de
  Transfer-Encoding: chunked
]

which triggers the problematic Firefox behaviour described in Comment #22.
I use Dreamweaver daily to work on websites. It creates template files with the
extension .dwt and I should be able to view the results of changes to templates
in my preferred browser. But not in Firefox -  it only offers to open it in
Dreamweaver.

I'm not happy about trying to edit a configuration file to deal with this, guess
I'll have to change back to Safari for viewing files in DW. Fooey.

You guys are off base thinking that you have to eliminate depth to give us a
nice simple interface. 

An old saying of Guy Kawasaki --  a great product should be "DICE" = Deep,
Intuitive, Complete, Elegant -- deep meaning you should be able to drill down
and find a way to do anything you want. Elegant means it works seamlessly and
makes you feel good about using it. I guess you can figure out Intuitive and
Complete.
*** Bug 297601 has been marked as a duplicate of this bug. ***
*** Bug 308139 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
Ever confirmed: true
*** Bug 319102 has been marked as a duplicate of this bug. ***
Sigh.

I tried to go read a patent for school.  US Patent Office shows images as TIFF files.  They use an 'embed' tag to do it.  Go look up Viagra or something for an example.

Result: Big window that says 'click here to download plugin' in a big box.  Not a box that says 'how do you want to handle this file?'.

Click on it, FireFox can't find a plugin for this file type, gives a button for 'Manual Install'.  Click on 'Manual Install', gives me the same page from the Patent Office again, with the very same 'click here to download plugin' button.

Nice infinite loop.  Has 'terminal frustration' written all over it.

There's a link at the bottom that says 'Find out more about plugins or manually find missing plugins'.  Click on that.  Get a list of the most common plugins.  Nothing there for TIFF.  Link at the bottom for 'plugins not found here' (plugindoc).  Click on that.  There's a list of architectures.  Click on Linux x86.  Find Plugger and Mozplugger.  Download Mozplugger RPM.  I think that'll solve my problem.  Oh, heck; I've got to hand-edit /etc/mozpluggerrc to add stuff.  Sigh.

Anyhoo, this isn't very user friendly or consistent.  If you're going to have 'Change' and 'Remove', you need to have 'Add'; it's in good UI design manuals everywhere.  FireFox's predecessor did.  Or perhaps get rid of Change and Remove (and the implicit 'View'), because they're "not something a normal user would ever use".

Note: I don't recommend using that last phrase; it tends to make people feel you're calling them abnormal, stupid, etc.  Adds gas to the fire.  And while the name is FIREfox, this isn't what was meant.

Thanks.
Hey, yeah, I just read the 'Realities About Users' page that was linked to from here.  I'm one of those users.  I just want this thing to work, and it's not; there are web sites I can't go to that I used to be able to go to until I upgraded.

I used to know how to fix this using the UI; but now that's gone.
*** Bug 327094 has been marked as a duplicate of this bug. ***
*** Bug 328224 has been marked as a duplicate of this bug. ***
*** Bug 347652 has been marked as a duplicate of this bug. ***
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → preferences
*** Bug 354969 has been marked as a duplicate of this bug. ***
This bug really should be reopened and fixed. Sure, I believe the heavily-traveled part of the UI should DTRT where possible for users who don't know and/or don't care about anything different. But there absolutely needs to be a way for users who do know and do care to get what they need. There is no good reason to gratuitously remove configurability when it isn't in the way of anything. And there are plenty of good reasons to include it. See bug 354971.

I'm just some regular joe user, not anyone who has a history with mozilla.org, so I'm leaving this RESOLVE WONTFIX, but I'm requesting that someone please fix this. It seems like a silly crusade to willfully ignore this problem.

(In reply to comment #1)
> 
> Eventually someone will write an extension to allow this, but the percentage of 
> the user population that knows what application/octet-stream means is small.  
> Very small.

OK Mike, it's now 2-1/2 years later, and this UI bug has gained 35+ comments and 7+ duplicates. (Yeah, I'm counting 354971 too.)

Where's the extension *YOU* promised? Please write it. Or solve the bug by fixing the native UI.
*** Bug 357953 has been marked as a duplicate of this bug. ***
A solution to this problem has existed for several years: the Mimetype Editor 0.2 extension (Mozilla's Helper Application preference panel as a stand-alone extension for Firefox) which can be downloaded from

http://www.extensionsmirror.nl/index.php?showtopic=179

This adds the Mimetype Editor to the Firefox toolbar. However, very sadly, it is incompatible with Firefox 2.0. I have reverted to Firefox 1.5.0.7.
(In reply to comment #40)
> A solution to this problem has existed for several years: the Mimetype Editor

which clearly show FF/Moz is broken here since years ...

> This adds the Mimetype Editor to the Firefox toolbar. However, very sadly, it
> is incompatible with Firefox 2.0. I have reverted to Firefox 1.5.0.7.

... which clearly shows that pretending an extension be a fix for a basic bug in FF is a broken solution.

This bug is a real bug, is causing lot of grief to many users, some of which have taken the time to come here, report, discuss, hoping eventually for real fix. 'RESOLVED WONTFIX' sounds really arrogant here, given the poor, if any, technical reasons offered.



I use 7-zip to unpack .tar.gz files, on a Windows XP box.

One of the websites I use extremely frequently has many tar.gz archives, available through a Web interface. 

I wish to examine the contents of these archives as quickly as possible. This was much more user-friendly before version 2.0.

I don't mind whether I have to add it in the Actions Editor, or it comes up as a menu item during the download process, but this particular lack of feature has been the single-most irritating part of Firefox 2.0. 

Other than that, it's really good. 

It seems that the Mimetype Editor 0.2 extension will not be updated for Firefox 2.0. The solution is to install Firefox 1.5 with the Mimetype Editor 0.2 extension and also Firefox 2.0 (in which the editor extension is present but inactive). One can then use Firefox 2.0 most of the time, and Firefox 1.5 when one wants to edit one of the mimetypes. 
> 
> This bug is a real bug, is causing lot of grief to many users, some of which
> have taken the time to come here, report, discuss, hoping eventually for real
> fix. 'RESOLVED WONTFIX' sounds really arrogant here, given the poor, if any,
> technical reasons offered.
> 

This requires that I switch all my users to IE7 unfortunately.  I have the problem with application/PDF refusing to do anything but save, regardless.  It's not listed in the "file type" handler options dialog, so I can't assign it to Acrobat or the like.  FF 1.X worked just fine.  For my intranet / inventory tracking software to continue to function I'll either have to stay on an outdated (possibly insecure) browser or switch back to IE7 which handles things properly.

I was hoping to find a resolution but the arrogant attitudes I'm seeing from the developers shows they really want all "average-joe" users to jump off a cliff and stop bugging them.

Just so I'm not only complaining I'll add the following notes:
PDF is not listed in the "download actions" settings dialog.
When the server generates the PDF it is flagged "application/PDF"
We do not use the browser plugin for Adobe.
The only dialog that opens upon linking is "Would you like to save this file?  Cancel / Save"
I'm not about to edit all of the mimeTypes.rdf files on all my workstations - I've opened that file and it seems very cryptic.

(In reply to comment #44)
Tony, there is no need for you to change to IE7. Instead, open Firefox 1.5 and download the Mimetype Editor 0.2 extension to your computer from 

http://www.extensionsmirror.nl/index.php?showtopic=179

Open a file manager and drag the extension onto the open Firefox screen. It will then be installed. Restart Firefox 1.5 and under Tools you will see the Mimetype editor with which you will be able to change the settings for pdf files, and indeed any other files. You will also be able to add new types.

Should you subsequently use Firefox 2.0, you will find that the Mimetype Editor is deactivated, however the change you have made using it in Firefox 1.5 will have been kept. Sadly, it seems the Mimetype editor extension is no longer maintained and will not be updated for Firefox 2.0.
(In reply to comment #45)
> (In reply to comment #44)
> Tony, there is no need for you to change to IE7. Instead, open Firefox 1.5 and
> download the Mimetype Editor 0.2 extension to your computer from 
> 
> http://www.extensionsmirror.nl/index.php?showtopic=179
> 
> .... Should you subsequently use Firefox 2.0, you will find that
> the Mimetype Editor is deactivated, however the change you have
> made using it in Firefox 1.5 will have been kept. Sadly, it seems
> the Mimetype editor extension is no longer
> maintained and will not be updated for Firefox 2.0.
> 

This extension works fine when installed via 'Nightly Tester Tools'. But, as an extra kick in the teeth, AMO doesn't have Nightly Tester Tools! (At least, when I searched for it, I got only the "light" version which removes exactly the functionality which we need here).

And even NASTIER, Google still shows a 'cached' comment in the NTT "Light" thread on AMO, which points to the correct download for the full version---
but the same "thought police" enforcement process which INSISTS that we all use an UNMAINTAINED extension (to do this job) also seems to have deleted that comment from AMO!

But, it can be found here:
http://users.blueprintit.co.uk/~dave/web/firefox/nightly

- - - - -
Again, I must agree with all the non-Mozilla commentators and all the people spending their time creating duplicate bugs PLEADING with you to address missing functionality:

Insisting (1) that 'we don't understand what we're doing' when we OBVIOUSLY DO; and (2) providing no solution for your DEFECT, except the piling of unmaintained extensions on top of extensions which apparently CAN'T EVEN BE TALKED ABOUT;

(a) is not effective in solving your users' frustrations and problems.

(b) does not inspire respect or support from us. My patience with you people is truly wearing thin-- Yes, you have the RIGHT to define your own software. But I don't see much 'community' here.

(c) If you want to see another GOOD implementation, you can go look at Konqueror. But I guess the programmers of Opera, IE, and Konq are too responsive to their users needs, too quick to make their products more usable. Mozilla.org seems to have a 'vision', and reality will not be allowed to interfere.
- - - - -
Of course I'm upset-- with good reason. If you don't want these arguments, go ahead and ban me.






(In reply to comment #46)
Yes, the Nightly Tester extension does the trick and I've got rid of Firefox 1.5. Thanks very much.
Hello!

I am a poweruser. I take care about 50 users who needs to download and open 20-30 documents every day to be able to do their work and pay my salary. All of them have problems with firefox and "helper-applications". They have problem because the have made a bad choice witch results in no way to change except modify the program with (unsupported) plugin. 

The problem is that no information is stored about the filetypes so they are not changable. If the user makes the wrong choice they can never make another choice. That is the problem. 

I have users that opens openoffice-documents without a problem and I have users who always get the save(only) option. Why can't I change this behavior?? The add-button is not the problem. The problem is that I can't make another choice.







*** Bug 363549 has been marked as a duplicate of this bug. ***
OK, I've read comment #8, and I still think an "add" button would be
great.  I and my programmer buddies often have to look at
files attached to bugzilla or other issue trackers.
Say they're .patch files.  I would really like to be able
to tell Firefox to treat those as text files without having
to edit some configuration file.

From what I gather, the official answer to my request will
be "users don't want to do that kind of thing, you're not our 
target audience", right?
The Firefox add-on "Mime Edit 0.60" works with the current Firefox (essentially the same as the outdated Mimetype Editor referred to above).
Please reopen - there a no ext for FF 3.5.x !!!

Or not ???
dan: do you have an example of what is currently difficult to do in firefox that uses a popular, public issue tracker?
Here's a somewhat weak example.  The attachment to
http://www.winehq.org/pipermail/wine-patches/2009-November/080909.html
is a patch which is served up with mime type text/x-diff.
If you click on it in firefox, you are correctly
presented with an option to use a text editor, and it works nicely.

However, if you then click on the file in the downloads window,
there is no mime type from the http server to save you, and
there is no easy way to get to a text editor -- the user has to
specify the absolute path to a graphical editor, which is difficult.
(I couldn't do it in 15 seconds of trying.)

Chrome correctly launches a text editor in that case.  But my
complaint is not quite about making that one case work better -
it's about making it easier to find the right app for a file.

If I happen to run into a better example I'll add another comment.
This issue has been reopened in bug 894536.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: