User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/15.0 Firefox/15.0a1 Build ID: 20120503030512 Steps to reproduce: * Enable plugins.click_to_play in about:config * Switch to a page with embedded flash content (i.e. youtube) * Click "Click here to activate plugins." Actual results: The flash content plays but interaction is not possible. The elements react to hovering correctly but clicking does not have any effect. Keyboard controls (tabbing through available elements) works however. Once I switch to another tab and back, clicking works. Expected results: After activating the plugin, clicking should work.
Still present in FirefoxNightly 16.0a1 2012-06-13.
I reproduce this bug still on http://hg.mozilla.org/mozilla-central/rev/bb4b37094b9f. (In reply to Dennis Lichtenthäler from comment #0) > Once I switch to another tab and back, clicking works. I focus the other element in a same page, clicking works too.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Unable to interact with plugin content when click to play is enabled → click does not work on a plugin content when a plugin is just activated
This bug happened: * Firefox Beta 14.0b8 * Firefox Aurora 15.0a2 2012-06-23 * Firefox Nightly 16.0a1 2012-06-23 This bug should fix before release Firefox 14.
Component: Untriaged → Plug-ins
Product: Firefox → Core
QA Contact: untriaged → plugins
No longer blocks: 711552
(In reply to Yuki Keiichi from comment #3) > This bug happened: > * Firefox Beta 14.0b8 > * Firefox Aurora 15.0a2 2012-06-23 > * Firefox Nightly 16.0a1 2012-06-23 > > This bug should fix before release Firefox 14. The setting is not yet user facing yet, so no need to track for release. Sending over to Jared for initial investigation.
To note, I have only heard this reported with youtube.com. I'm not sure what is happening there, but I talked with Margaret and we think that we should move the click-to-play event handler to the actual plugin instead of the overlay (bug 741130). That might fix this bug. Re-assigning to dkeeler since he is going to work on fixing bug 741130.
Assignee: jaws → dkeeler
Depends on: 741130
Duplicate of this bug: 755094
(In reply to Jared Wein [:jaws] from comment #5) > To note, I have only heard this reported with youtube.com. Yep, I'm unable to reproduce this with anything other than youtube videos.
(In reply to Dennis Lichtenthäler from comment #7) > Yep, I'm unable to reproduce this with anything other than youtube videos. I'm unable to reproduce this too. (on Today's nightly, http://hg.mozilla.org/mozilla-central/rev/e61399f31505 )
(In reply to OHZEKI Tetsuharu [:saneyuki_s] from comment #8) > (In reply to Dennis Lichtenthäler from comment #7) > > Yep, I'm unable to reproduce this with anything other than youtube videos. > > I'm unable to reproduce this too. (on Today's nightly, > http://hg.mozilla.org/mozilla-central/rev/e61399f31505 ) Oops! Sorry, I have missed the test. This bug is REPRODUCED on Today's nightly on OSX 10.7, http://hg.mozilla.org/mozilla-central/rev/e61399f31505.
No longer depends on: 741130
Duplicate of this bug: 775709
I can reproduce this too (Aurora 16.0a2 (2012-07-22))
This is bug is due to "mouseup" dom events not being sent to the plugin due to this check: http://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsPluginInstanceOwner.cpp#2098 Before the click is delivered, mContentFocused should be set to true here: http://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsPluginInstanceOwner.cpp#2083 However the "focus" dom event is never delivered to the pluginInstanceOwner with click-to-play. Still looking into how to properly fix this.
With click-to-play enabled, the focus event was delivered before the actual plugin instance owner was loaded. Fixed by syncing the focus state when the frame is set on the plugin instance owner.
Comment on attachment 649335 [details] [diff] [review] Fix focus issue with click-to-play Josh, can you review this?
This could really use a mochitest.
Comment on attachment 649335 [details] [diff] [review] Fix focus issue with click-to-play Good point, post-poning review request until this has a test.
Attachment #649335 - Attachment is obsolete: true
Pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=de8ccadbf88d
The test failed on try, even on 10.6 which runs the test fine for me. Adjusted successive click tests to do the same thing to find out: https://tbpl.mozilla.org/?tree=Try&rev=9786a523e1d9
Attachment #650956 - Attachment is obsolete: true
"to (In reply to Georg Fritzsche [:gfritzsche] [away 11-19 Aug] from comment #19) > Adjusted successive click tests to do the same thing to find out: ... if this is a problem with the test enviroment.
Figured out the issue with the test not working. Georg said he'd be out for a bit, so I'll be shepherding this to landing. Asking for review from Josh.
Comment on attachment 651559 [details] [diff] [review] patch v4 Excellent fix, thanks Georg and David!
Attachment #651559 - Flags: review?(joshmoz) → review+
This was the run: https://tbpl.mozilla.org/?tree=Try&rev=e88d375f6e57 Marking checkin-needed.
(In reply to David Keeler from comment #23) > This was the run: https://tbpl.mozilla.org/?tree=Try&rev=e88d375f6e57 Green on Try. https://hg.mozilla.org/integration/mozilla-inbound/rev/6943b37c68cc
Flags: in-testsuite? → in-testsuite+
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Sorry, backed out for bug 783723: https://hg.mozilla.org/integration/mozilla-inbound/rev/7a1a745a45f2
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla17 → ---
* Fix intermittent failures through SimpleTest.waitForFocus() * Avoid causing failures on subsequent tests if the test for this bug fails Josh, can i carry over the r+ for this fixed patch?
Attachment #651559 - Attachment is obsolete: true
(In reply to Georg Fritzsche [:gfritzsche] from comment #28) > Created attachment 655568 [details] [diff] [review] > patch v5 Try run for this patch: https://tbpl.mozilla.org/?tree=Try&rev=7d088f4af68d
(In reply to Georg Fritzsche [:gfritzsche] from comment #28) > Josh, can i carry over the r+ for this fixed patch? Yes
(In reply to Georg Fritzsche [:gfritzsche] from comment #29) > Try run for this patch: > https://tbpl.mozilla.org/?tree=Try&rev=7d088f4af68d Green on Try. https://hg.mozilla.org/integration/mozilla-inbound/rev/31a27d47d242
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
This is important enough for CTP that it should be uplifted, I believe: see bug 792550 which is probably a dup and affects embedded youtube videos, which are one of the primary use cases that should work.
Georg - please nominate for Aurora approval when you get the chance.
Comment on attachment 655568 [details] [diff] [review] patch v5 [Approval Request Comment] Bug caused by: Click-to-play feature when active User impact if declined: E.g. Youtube Flash not responding to button click unless switching tabs or otherwise refocusing plugin element. Testing completed (on m-c, etc.): Been on nightly for a while, no negative feedback so far. Also verified locally. Risk to taking this patch (and alternatives if risky): Low-risk, worst-case is probably causing other focus issues. String or UUID changes made by this patch: none.
Attachment #655568 - Flags: approval-mozilla-aurora?
Attachment #655568 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
After following the steps to reproduce from comment 0, I could not interact with the flash content on www.youtube.com or flash trailers in imdb.com for the build ID: 20120503030512. For the same steps in comment 0 for Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Firefox/17.0 beta 4 Build ID: 20121031065642 flash content is working on every mouse action. Also other flash content sites like trailers on imdb.com or vimeo.com.
Video controls are working fine with CTP enabled on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/18.0 Firefox/18.0. Verified fixed
You need to log in before you can comment on or make changes to this bug.