Status of click-to-play plugins in Firefox 24/26

Benjamin Smedberg benjamin at smedbergs.us
Wed Oct 30 13:08:01 UTC 2013


On 10/30/2013 5:53 AM, Gervase Markham wrote:
>
> What happens if the plugin in the page is not visible? Is the lego block
> all that's left?
Currently yes, although I mentioned that as a concern in my original email.
>
> Anecdote: I am on the firefox-dev mailing list and so probably am more
> aware than 99.999% of the population about the possibility of plugins
> being click-to-play. However, twice in the last few weeks (once for a
> Cisco browser-based Java VPN client and once for Google Hangouts)
> something on the web has entirely stopped working and it's taken me an
> hour to figure out that it was because there was a plugin not running
> that needed to be unblocked.
>
> There was no UI indicating that a plugin had been blocked apart from the
> lego block, which I simply did not notice. Google Hangouts itself takes
> up the entire popup window and yet I assume they don't make the plugin
> visible by default, because there was no "click here to enable plugin"
> UI in the page.
>
> We need to be absolutely certain that, one way or another, the enabling
> UI is obvious. If the plugin doesn't have space on the page, we need
> something else instead.
As noted in a previous thread 
(https://mail.mozilla.org/pipermail/firefox-dev/2013-September/000903.html) 
there are some serious tradeoffs with making things discoverable versus 
protecting users from attacks delivered via ad networks. It's clear to 
me that we want to end up in a state where the UI is *not* discoverable, 
and sites that need to continue using Java have to adapt using 
techniques like those listed at 
https://developer.mozilla.org/en-US/docs/Site_Author_Guide_for_Click-To-Activate_Plugins

In the short term, however, there are enough sites that use hidden Java 
that we may need some sort of compromise. The possible workarounds are 
discussed a bit in my original email, and I'm working with madhav, lco, 
and chadw to identify whether and which workaround we would deploy.

On 10/30/2013 6:16 AM, John Wong wrote:
> I want to discuss a point that might have been suggested/discussed 
> already.
> Even as a developer, the initial blocking "Your Java version is 
> outdated" is not helpful in the case of someone running latest Java 
> runtime.
>
> Expectations:
>
> 1. Just say Java is blocked on Firefox from x version
> 2. Give a help message
>
> A sample message in the UI would look like this
>
> Java runtime is disabled on Firefox starting version x.
>        What does this mean to me? How to re-enable it?
I'm not sure what you mean. There are two cases:

* The user is running an old version of Java (earlier than Java 7 
release 45). In this case we want to prompt the user to update Java.
* The user is running the latest version of Java. Mozilla believes that 
Java is fundamentally insecure and users should only use it when 
necessary, so we present the warning UI but users may still click to 
activate Java on particular sites.

Which of these cases are you worried about, and what exactly is your 
proposal?

--BDS




More information about the firefox-dev mailing list