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.
Deactivating the Click_to_play flag removes the issue.
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.
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.
Reproducible on Nightly 19.0a1 (2012-10-21) on Win 7 x64 with Google Talk Plugin 220.127.116.1132. 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.
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.
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.
Georg is going to investigate the actual situation here.
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.
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.
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.
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.
(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
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?
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.
Thanks. Please file an issue on the Talk Video Renderer notification.