Expose the plugin UI before a user clicks to play

RESOLVED WONTFIX

Status

()

Core
Plug-ins
P5
normal
RESOLVED WONTFIX
5 years ago
4 years ago

People

(Reporter: James Hall, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130307023931

Steps to reproduce:

With about:permissions plugins set to "Always Ask", you cannot tell what url the plugin is loaded from.


Actual results:


For example, at https://hacks.mozilla.org/2013/02/hello-chrome-its-firefox-calling/, there is an embedded youtube video.  However, simply looking at the site I have no idea where the plugin is coming from and whether or not to trust it.


Expected results:


It would be very nice to have a url popup at the bottom (just like with an html link) during mouseover of the Click to Play overlay.

Updated

5 years ago
Blocks: 738698

Updated

5 years ago
Status: UNCONFIRMED → NEW
Component: Untriaged → Plug-ins
Ever confirmed: true
Priority: -- → P5
Product: Firefox → Core
Summary: Cannot see plugin url under Click to Play → Expose the plugin UI before a user clicks to play
Version: 19 Branch → unspecified
Regarding showing the url:

(Quoting Georg Fritzsche [:gfritzsche] from bug 753100 comment 1)
> I don't think this is too useful as:
> a) a URI doesn't necessarily identify a plugin and
> b) object/embed elements don't need to have a URI set

I would add that youtube hosts its flash player at https://s.ytimg.com/yts/swfbin/watch_as3-vflcwIWb1.swf which is pretty useless for determining where it's actually coming from and if it's trustworthy (that's if you embed it directly instead of doing the iframe thing, but you get the idea).
(Reporter)

Comment 2

5 years ago
That makes sense, many users probably wouldn't be interested in that information to start with.  But how many "average users" actually look at the full url popup at the bottom of the screen before clicking the blue words?

It would be just nice to be completely informed about whats going on under the overlay.  Right now it is a mystery and for the users that wouldn't care, it wouldn't be intrusive.

Personally, I know about ytimg and would like to know where the plugin is coming from before blindly clicking on it.  This seems especially important if Click to Play is going to be used to soft block outdated plugins.

Icing on the cake: the popup would also show which plugin is under that particular overlay.

Example:
"[Plugin: Flash] https://s.ytimg.com/..."
I suspect what will be more effective here are other various changes for CTP to make it "just work" in a less-annoying way. Possible examples: whitelist YouTube by default, and autoplay plugins the user will usually play anyway.

To a certain degree, if the user has to look at the plugin's URL to make a choice, we've already lost because that's a bad experience.

If you're a use that simply wants an extra degree of info/control that's not relevant to most users, then this is something probably better suited to an add-on.

Comment 4

5 years ago
Not something we're going to fix in-product.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX

Comment 5

5 years ago
(In reply to Justin Dolske [:Dolske] from comment #3)

> I suspect what will be more effective here are other various changes for CTP
> to make it "just work" in a less-annoying way. Possible examples: whitelist
> YouTube by default, and autoplay plugins the user will usually play anyway.

This is what Firefox 25 does now : autoplay *now*, *together*, the plug-ins I will usually play anyway *later*, *one by one*. When I have 5 songs in YouTube, I want to listen to the 5 songs, *but not at the same time* ! Click-to-play serves not only to let the user decide *whether* to play the plug-in, it also serves to let the user decide *when* to play the plug-in. Firefox was good at that in previous versions, it would be nice to have that back. Thank you.
You need to log in before you can comment on or make changes to this bug.