275286 - Clicking on an embedded object with no handling plugin should allow download

Status: RESOLVED WONTFIX

(Toolkit Graveyard :: Plugin Finder Service, enhancement)

Description

[[e-mail]]

if there is an applet or object embedded in the page that can only be shown with
a certain plugin, clicking in the plugin space should come up with a dialog that
lets the user choose whether
*) to search for and download the apropriate plugin (as done now)
or
*) download the file to the local computer
*) download the file and process it by some external program

This would be immensely practical especially on non-Windows computers, where
many plugins are not available or not as convenient as on Windows, but where you
have still stand-alone programs for handling these files.

While in some situations Page info -> media can provide a workaround for this,
there are several problems with that method:
*) you need a lot of clicks to do it that way - my proposal would make it a lot
easier
*) if there are several objects in the page, it is hard to figure out which one
you want - in the proposal you simply get the one you click on
*) if the embedded object occupies the whole frame or page in a popup with th
menu bar suppressed, there is no way to get to this page in FF

Comment 1

[Doron Rosenberg (IBM)]

Too geeky.  View source and wget it :)

Comment 2

[[e-mail]]

This is not geeky but user friendly. Please remember that many objects can only
be used with some standalone program under linux and even under Windows people
might want not to install each and every plugin for handling embedded objects.
So where is the geek factor when your browser simply offers you the possibility
to download the data (e.g. the media file) for viewing in your favorite media
player?

The reply of suggesting this to be too geeky and suggesting to use view source
(which as I pointed out is not even possible in all cases) would be funny if you
had not marked this wontfix. But on what grounds did you assign this resolution? 

Maybe somebody does fix it and thus improve the usability of FF. 

Comment 3

[Wolf [:wolf]]

Doron is module owner for PFS. That would be the grounds.

Also, doesn't the Media tab of Page Info provide a save as button for embeded
items? Doesn't require Viewing Source or using wget and doesn't require any new
features being added that are of low-use for most users either.

Comment 4

[[e-mail]]

This is an identicall issue for all OS, not just Linux.

And if you read the original description you will find an answer to your
question: many sites provide their media content in pop up windows that have the
menu bar removed and where the embedded object takes up all the space of the
window or a frame. In such a case it is impossible to even show the Page Info ->
Media dialog.

Apart from that, a page can contain several embedded objects of the same
(unsopported by a plugin) type and even if Page Info -> Media is accessible,
finding out which of these objects you want is often only possible by trial and
error downloading of all of them. 

BTW: the grounds I would like to see here is a sincere discussion of why this
should not be fixed and why this is not, as I propose, and improval of the
usability experience for many FF users. Not a snappy and rather arrogant remark
that indicates no interest whatsoever to even consider a suggestion for improval. 

None of the functions currently implemented for plugin installation would be
affected or made more complicated. The only thing that would change is that when
clicking on an uninstalled plugin object a dialog would appear that offers to
download the object. Clicking OK would simply go to the standard dialog for
downloading files with unknown (or known) MIME type, just as if the media would
have made available by a download link instead of an object. 

Comment 5

[Mike Connor [:mconnor]]

I agree with doron that this isn't especially useful (especially since some plugin formats don't work on download) and adding a bunch of code to make a rare case work with less effort is a net loss.  This just isn't worth the codesize or effort, for the edge cases it really covers.

Comment 6

[[e-mail]]

(In reply to comment #5)
> I agree with doron that this isn't especially useful (especially since some
> plugin formats don't work on download) and adding a bunch of code to make a
> rare case work with less effort is a net loss.  This just isn't worth the
> codesize or effort, for the edge cases it really covers.
> 
This is not intended to solve all issues but will solve a large majority of issues. It is not a rare case at all: nearly all pages that offer media content offer it in a form that does not provide a download link but expects some, usually Windows/OS only, plugin. There is nothing that supports your claim that this is just relevant for edge cases.

So, what do you expect a user to do in those cases? How do you expect a Linux user to deal with the problem of some popup that offeres media only for different browsers or OS plugins? 

Why is it necessary to apodictically make thos WONTFIX instead of letting the comunity solve it, if the ressources are there? 

Comment 7

[[e-mail]]

One afterthought: have you actually used FF on Linux with sites that depend on plugins? In 99% of the non Flash or Java cases what happens is this: you get to see the plugin placeholder, click on it and are asked if you want to install the plugin, followed by a message that no plugin exists. This is the best way to cause frustration. If the popup would *in addition* offer the simple option to download the object and store it locally, those who know what to do with it would be at least *able* to do it while all others can easily ignore it. 

What is the problem with that except vastly improved usability?