Created attachment 8604059 [details] bandicam 2015-05-11 14-52-26-422.avi User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150510030207 Steps to reproduce: 1-go to pingtest.net 2-click on plugin 3-go to firefox customization page Actual results: 4-plugin stays on to front even though tabs switched Expected results: i dont know but at least it shouldnt stay i guess? :/ sorry i am kind of new, this is my first bug. but i really been following this latest bugzilla bugfixes for almost a year :) reproduced scenario video is available at attachment:
Created attachment 8604100 [details] screencast Shockwave Flash 22.214.171.124 Works: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:39.0) Gecko/20100101 Firefox/39.0 Build ID: 20150511004005 Fails: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150510030207 Flash Player won't work in a Nightly non-e10s window (Nightly reports it's disabled though it's not), and I can't seem to enable e10s in FDE. So I can't tell if this is e10s-related or a regular regression.
> Flash Player won't work in a Nightly non-e10s window This is by design :( See, Bug 1158270 Comment 5. > I can't tell if this is e10s-related or a regular regression. I can reproduce the problem on windows7 with e10s enabled However, I cannot reproduce with e10s disabled. So, this is definitely only e10s.
Created attachment 8609809 [details] example1.png Ran into the same issue while watching some MLS games today. While I was watching the game, I quickly switched tabs and the video spilled over to the next tab. It doesn't always happen, but it's pretty easy to reproduce. Once I disabled e10s, I couldn't reproduce the issue anymore. - attached two screenshots to illustrate the issue Used the following STR: - logged into http://live.mlssoccer.com - selected a game and started playing it - once it started playing, quickly switched the tabs and the video spilled over to about:newtab & about:preferences Plugin Info: File: NPSWF32_17_0_0_188.dll Path: C:\WINDOWS\SysWOW64\Macromed\Flash\NPSWF32_17_0_0_188.dll Version: 126.96.36.199 State: Enabled Shockwave Flash 17.0 r0
so it basically doesn't only occurs on customize firefox tab, but pretty much every tab belongs to firefox. can anybody update the title according to problem? im not good at language
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:41.0) Gecko/20100101 Firefox/41.0 Build ID: 20150524030234 Shockwave Flash 188.8.131.52 I can't seem to reproduce this when hardware acceleration is disabled under Options → Advanced → General.
Created attachment 8649480 [details] [diff] [review] patch The customize view triggers weird timing here, we end up with pending plugin updates (mUpdatedPluginDataAvailable is true) while GetParent() is null. Once we get stuck in that situation we never update mUpdatedPluginDataAvailable so we never hide plugin windows. This only happens about 50 percent of the time, and depends on when the final plugin update comes in. It's also specific to customize, new tab doesn't trigger it, the timing is just different. This patch fixes the problem, and doesn't regress any previous issues I've run into.
STR: 1) open a simple windowed flash test case 2) open a second tab and navigate to customize 3) switch back to the test case 4) switch to the customize tab
I can reproduce this on any page, just happened on newtab and bugzilla. Am I seeing a different issue here?
(In reply to Trevor Rowbotham from comment #11) > I can reproduce this on any page, just happened on newtab and bugzilla. Am > I seeing a different issue here? maybe. this can also be caused by a janked main thread, which can be caused by addons.
Created attachment 8649867 [details] [diff] [review] patch merged to tip.
for testing, this work plus the work in bug 1137944: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8b211d925042
Jim, in my normal nightly build, when this happens I can generally interact with the plugin and only sometimes do I get a ghost image of the plugin. However, with the build from comment 15, I was only able get a ghost image of the plugin to appear after switching tabs. The ghost image will go away if I scroll in both my regular nightly build and the build from comment 15, but when I am able to interact with the plugin in my normal nightly build, the plugin will stay on my screen until I switch back to the tab that contains that plugin. The build from comment 15 also had a tendency to go unresponsive when switching tabs. Here is a report from me forcing Firefox to crash when it, I suspect something was deadlocked: bp-0efcf044-2b89-4bde-871b-f78fc2150819
(In reply to Trevor Rowbotham from comment #17) > Jim, in my normal nightly build, when this happens I can generally interact > with the plugin and only sometimes do I get a ghost image of the plugin. > However, with the build from comment 15, I was only able get a ghost image > of the plugin to appear after switching tabs. The ghost image will go away > if I scroll in both my regular nightly build and the build from comment 15, > but when I am able to interact with the plugin in my normal nightly build, > the plugin will stay on my screen until I switch back to the tab that > contains that plugin. The build from comment 15 also had a tendency to go > unresponsive when switching tabs. Here is a report from me forcing Firefox > to crash when it, I suspect something was deadlocked: > > bp-0efcf044-2b89-4bde-871b-f78fc2150819 Great, this is useful. The ghost image is the painting problem in bug 1137944, the interactive plugin window in the wrong tab is *this* bug which appears to be fixed with the patch here.