Closed
Bug 756206
Opened 12 years ago
Closed 10 years ago
"click_to_play" flag kills Gmail calling
Categories
(Web Compatibility :: Desktop, defect, P2)
Web Compatibility
Desktop
Tracking
(firefox17-)
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox17 | - | --- |
People
(Reporter: northlayout, Unassigned)
References
()
Details
(Whiteboard: [country-all] [js] )
Attachments
(1 file)
(deleted),
image/jpeg
|
Details |
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•12 years ago
|
||
Deactivating the Click_to_play flag removes the issue.
Component: Untriaged → Plug-ins
Product: Firefox → Core
QA Contact: untriaged → plugins
Blocks: click-to-play
Comment 2•12 years ago
|
||
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.
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
Comment 5•12 years ago
|
||
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.
Comment 7•12 years ago
|
||
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"
Comment 8•12 years ago
|
||
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.
Comment 10•12 years ago
|
||
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.
Comment 11•12 years ago
|
||
In the back of my mind, I am imagining that Click To Play will become default one day :)
Comment 12•12 years ago
|
||
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.
Comment 13•12 years ago
|
||
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:
--- → ?
Comment 14•12 years ago
|
||
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•12 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.
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).
Comment 17•12 years ago
|
||
(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.
Comment 18•12 years ago
|
||
(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•12 years ago
|
||
Georg is going to investigate the actual situation here.
Assignee: nobody → georg.fritzsche
Comment 20•12 years ago
|
||
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.
Comment 21•12 years ago
|
||
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
Updated•12 years ago
|
Assignee: georg.fritzsche → english-us
Updated•12 years ago
|
Whiteboard: [tech
Comment 22•12 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
Updated•12 years ago
|
Comment 23•12 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.
Comment 24•12 years ago
|
||
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.
Updated•11 years ago
|
Comment 25•10 years ago
|
||
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]
Comment 26•10 years ago
|
||
(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)
Comment 27•10 years ago
|
||
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.
Comment 28•10 years ago
|
||
(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)
Comment 29•10 years ago
|
||
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
Closed: 10 years ago
Flags: needinfo?(bogdan.maris) → needinfo?(georg.fritzsche)
Resolution: --- → WORKSFORME
Comment 30•10 years ago
|
||
Thanks. Please file an issue on the Talk Video Renderer notification.
Flags: needinfo?(georg.fritzsche)
Updated•10 years ago
|
Flags: needinfo?(kdubost)
Assignee | ||
Updated•6 years ago
|
Product: Tech Evangelism → Web Compatibility
You need to log in
before you can comment on or make changes to this bug.
Description
•