If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

"click_to_play" flag kills Gmail calling

RESOLVED WORKSFORME

Status

Tech Evangelism
Desktop
P2
normal
RESOLVED WORKSFORME
5 years ago
3 years ago

People

(Reporter: northlayout, Unassigned)

Tracking

unspecified

Firefox Tracking Flags

(firefox17-)

Details

(Whiteboard: [country-all] [js] , URL)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Created attachment 624832 [details]
Gmail.JPG

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/15.0 Firefox/15.0a1
Build ID: 20120510145529

Steps to reproduce:

Enabled "click_to_play" flag.
Loaded gmail as usual.

Tried to place a call through Gmail calling.


Actual results:

Get a message from the applet with the following message "Please download the voice plugin to make a call."



Expected results:

There is no button visible to activate the content to make the call.
(Reporter)

Comment 1

5 years ago
Deactivating the Click_to_play flag removes the issue.
Component: Untriaged → Plug-ins
Product: Firefox → Core
QA Contact: untriaged → plugins

Updated

5 years ago
Blocks: 738698
A simple temporary fix would be that click-to-play remembers the activation when I refresh. This way, I could activate the plugin and refresh, and it will all work.
That defeats the purpose of Click-to-Play does it not?
I can definitely confirm this issue happens (reproduced on Linux 64-bit with Firefox 19.0a1). However, I'm wondering if this bug is more about Google providing a better UX for handling CTP plugins. I suppose an alternative would be if we could not use CTP for the Google Talk plugin but I still believe this to be a Google UX issue, not a Firefox issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Version: 15 Branch → Trunk
I am not sure how it defeats the purpose. I click Activae all plugins, and refresh. Then, the plugin executes. If I refresh again, it doesn't. Isn't this pretty standard? equivalent to "temporarily allow" in NoScript ?
That's not how click to play works, at least in Firefox's implementation. Consider for example Flash video. With Click to Play enabled the video is overlayed with a warning asking if want to enable the content. Clicking the overlay loads the content (ie. no page refresh is required). Reloading the page reloads the click-to-play overlay.

Google Talk on the other hand just displays a "download the plugin" text link. We can't really overlay that and it's clear to me that Google's UX does not allow for a blocked/disabled scenario. I really think this is Google's bug and should be resolved WONTFIX; or at the very least moved to Tech Evanglism.
The overlay is one way Click to Play works. Another is to use the plugin icon next to the URL, where you can see the list of plugins needed by this page. On the hanger, one can click "Active .. plugin" for each plugin, or click on "Activate All Plugins".

I am even ok adding another option in the "Activate" drop down saying "Activate and Refresh with plugins enabled"
You are free to do tech evangelism: if Google adopts it, then the refresh becomes unnecessary. But, I am certain this is not the only site where the current setup doesn't work. 

But, while the switch happens, there is really no reason to put this pain on Firefox users.
(In reply to Devdatta Akhawe [:devd] from comment #8)
> there is really no reason to put this pain on Firefox users.

Strictly speaking to *this* bug, I think that's a bit of an over-generalization. We have no evidence to indicate that a large amount of users are hitting this issue. For one, triggering this bug requires changing a pref that is not widely publicized. For another, I think we'd have seen something about this on our feedback channels by now if it was affecting any number of users.

That said, I don't disagree with what you are proposing; I'm just trying to provide another point of view. I'll let those with CTP UX knowledge and expertise comment further as to what should be the "right" solution.

Let me just say, I'm no fan of implementing temporary workarounds in lieu of fixing broken behaviour; unless it's to workaround a serious security or stability issue. In which case, I strongly favour a workaround which does not force new behaviour on a very large set of users just to fix a very small set of users.
Sorry, I forgot to cc the QA owner for Click-to-Play on this bug. Paul, please add your own feedback and ideas to this issue if you can. At the very least the issue is reproducible.
In the back of my mind, I am imagining that Click To Play will become default one day :)
also, Isn't blocking out-dated plugins going to be turned on by default? I think this problem manifests even if just flashplayer is blocked by click-to-play.
David - is there anything we can do here? My feeling is no, in which case we won't track for release since this will only affect old CTP'd plugins.
Assignee: nobody → dkeeler
tracking-firefox17: --- → ?
Reproducible on Nightly 19.0a1 (2012-10-21) on Win 7 x64 with Google Talk Plugin 3.9.1.9832.

I agree with you Anthony, CTP should avoid Google at least for the moment, especially since there are already other known related issues - bug 745187.

Comment 15

5 years ago
Please let's not focus on "someday" and instead focus on right now: this bug is not serious enough to block CTP blocklisting. Even if there were things we could do, I probably wouldn't take them in 17 betas and johns has more important bugs to look at right now.
Assignee: dkeeler → nobody
tracking-firefox17: ? → -
Priority: -- → P2
There really isn't anything we can do right now. In general, there are all sorts of things a site can do to make our (or, to invoke Rice's theorem, any) implementation of click-to-play not work very well, and this happens to be one of them. There has been some talk of doing adding a "refresh with plugins enabled" button, but talking is as far as we've gotten with that.
As long as we don't use the blocklist on this plugin, this won't really be a problem until click-to-play becomes a more directly user-facing feature. At that point, we will want some sort of solution to this, but until then we're fine letting this be (although some evangelism to get Google to change their plugin handling would probably be helpful).
(In reply to Devdatta Akhawe [:devd] from comment #12)
> also, Isn't blocking out-dated plugins going to be turned on by default? I
> think this problem manifests even if just flashplayer is blocked by
> click-to-play.
It is ON on FF 17.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #15)
> Please let's not focus on "someday" and instead focus on right now: this bug
> is not serious enough to block CTP blocklisting. Even if there were things
> we could do, I probably wouldn't take them in 17 betas and johns has more
> important bugs to look at right now.

OK, that was my feeling too Benjamin.

Comment 19

5 years ago
Georg is going to investigate the actual situation here.
Assignee: nobody → georg.fritzsche
A first investigation shows that:
* the plugin is in an iframe which is is hidden by putting it off-screen (top:-99em)
* the plugin seems to instantiate just fine after activating it through the location bar hanger
* when not being click-to-play activated there is scripting activity on the plugin after its instantiation, so the pages JS appears to check on it early after page-load (need to check further to see what exactly is happening there)

This doesn't happen with Chromes C2P implementation, but only because apparently the googletalk plugin isn't blocked by it at all.
Moving over to evangelism due to the reasons outlined in comment 20.
Component: Plug-ins → English US
Product: Core → Tech Evangelism
Whiteboard: [tech
Version: Trunk → unspecified
Assignee: georg.fritzsche → english-us
Whiteboard: [tech

Comment 22

5 years ago
lmandel, I believe you said we have contacts at Google properties? We believe that they need to be aware of CTP and wait for the plugin to instantiate on gmail.
Whiteboard: [tech
Blocks: 819972
No longer blocks: 738698

Comment 23

5 years ago
Due to changes in click-to-play and possibly gmail, it is no longer difficult to activate the plugin. Once upon a time, there was nothing on screen to click-to-play, but now there is a button on the left of the awesome bar. I don't think this bug is necessary anymore.
The click-to-play notification shows fine, but what's being tracked here is a problem with GMail:
* enable click-to-play
* navigate to GMail
* use doorhanger to activate plugins
* try to place a call

The site will still tell you to download the voice plugin instead of noticing that the plugin is now active.
See Also: → bug 932832
Before contacting Google what we are missing here is the piece of code triggering the issue on gmail side.
And how it could be fixed. 

Moving to Desktop.
Assignee: english-us → nobody
Component: English US → Desktop
Whiteboard: [tech → [country-all] [js]
(In reply to Karl Dubost :karlcow from comment #25)
> Before contacting Google what we are missing here is the piece of code
> triggering the issue on gmail side.

What kind of code do you need? The steps are in comment 24, although we now have click-to-play on by default.

We also do have a site-author guide for click-to-play: https://developer.mozilla.org/en-US/Add-ons/Plugins/Site_Author_Guide_for_Click-To-Activate_Plugins
Flags: needinfo?(kdubost)
The simple fix (assuming the problem is still there and due to the same constructs) likely is to poll the IFRAME with the plugin instance from an interval and call the "successful" callback if the plugin is instantiated, rather than doing just a single check. I think we can contact Google with such a recommendation - but since this was last touched a year ago, I'd like somebody with this plugin installed to verify that it's still an issue.
(In reply to Hallvord R. M. Steen from comment #27)
> I think we can contact Google with
> such a recommendation - but since this was last touched a year ago, I'd like
> somebody with this plugin installed to verify that it's still an issue.

Bogdan, can you check?
Flags: needinfo?(bogdan.maris)
In reply to Georg Fritzsche [:gfritzsche] from comment #28)
> (In reply to Hallvord R. M. Steen from comment #27)
> > I think we can contact Google with
> > such a recommendation - but since this was last touched a year ago, I'd like
> > somebody with this plugin installed to verify that it's still an issue.
> 
> Bogdan, can you check?

This is not an issue anymore. Once the plugin is downloaded it can be used to make calls. 

The only potential issue I see is that when a call is made I get an unnecessary message from 'Google Talk Video Renderer' that asks for permission to run. Here is a .gif to show the potential issue: https://db.tt/Ra5LOsXn. If I don`t click on Allow for 'Google Talk Video Renderer' I can still make the call and eventually the message will disappear. Is this something worth checking?

As this issue does not reproduce anymore I will close this as WFM.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(bogdan.maris) → needinfo?(georg.fritzsche)
Resolution: --- → WORKSFORME
Thanks. Please file an issue on the Talk Video Renderer notification.
Flags: needinfo?(georg.fritzsche)

Updated

3 years ago
Flags: needinfo?(kdubost)
You need to log in before you can comment on or make changes to this bug.