Comment 106 for bug 25830

Revision history for this message
In , Jsfbbz (jsfbbz) wrote :

I disagree.

This is a common enough problem, and being one where the people causing the
problem, or at least capable of solving it, are generally not the ones suffering
from it, and may not be open to fixing it since the people capable of actually
explaining what the problem is are a very small subset of their audience, or
they may not be directly contactable through the corporate bureaucracy, this
merits very careful thought about how the problem can be mitigated from the
client side.

There are cases where a resource can be opened, will force the "Save As" dialog,
and if saved and double-clicked will immediately open the browser which will
render it fine. This is quite clearly a ridiculous situation! We know why it
happens but the user experience is just stupid.

Certainly there are a few common media types which, for a user who can see what
the resource ought to be handled as, they should be able to easily override the
Save As prompt and cause the resource to be opened by that built-in handler. I'm
thinking here "Plain Text", "HTML", "JPEG image", "GIF image". Plus a few more.
PNG, XML etc. The list isn't huge, will cut out 99.9% of erroneous mimetype
problems, and if a confused user chooses the wrong thing they can always try
again and are in no worse situation than they started off.

Possibly this should be defaulted based on the resource "filename extension" - I
can't see that being a problem (in many cases it just won't work, but is no
worse than not doing so). Defaulting based on the first few bytes of the
resource would be better. Possibly, if we really want to keep that dialog
absolutely as simple as possible then it should be made an expandable dialog
with an "Advanced/More>>>" button - I don't see a problem with that either.

But there *does* need to be an escape route, because the failure mode results in
far more effort than is reasonable to work around, currently. It *should* just
work transparently, yes, but it sometimes doesn't and in those cases it really
doesn't need to fail that badly.

Choosing obvious stuff from a list is an absolute minimum. The real expert user
will also want to be able to type in a literal mimetype. Hide these by default
if you're really worried about scaring some users, but they ought to exist somehow.

(I'd also like to point out that "unknown mimetype" is not the only problem -
there are cases where the mimetype is recognised but mislabelled. In these cases
it would be useful to be able to invoke something similar to the Save As dialog
manually on a link. The example that springs to mind is download sites that
mislabel PKZIP or Windows executable files as text/plain. In fact I'd really
like to see a check for resources starting in PK or MZ and throwing a dialog
saying "Are you sure you want to open this as text or HTML", but that's getting
beyong the scope of this bug.)