13.21 KB, application/x-shockwave-flash
242 bytes, text/html
1.52 KB, patch
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150826023504 Steps to reproduce: After update to Firefox 40 Actual results: The cursor inside Flash is no longer shown as hand. It is shown only like there is nothing clickable. So the users do not know where to click inside a flash game / file. Expected results: Mouse should be shown as usual as a hand when there is a clickable link.
could you attach a simple testcase (or public URL to test).
Here is a sample of the bug including the parameters. The mouse comes only when clicking and moving inside the game. http://www.x-oo.com/flash-online-games/kartenspiele/lightning.html Here is a sample "without" the parameters from the title of this report. Here it works fine. But the parameter is needed because of some advertisement and/or layers. http://www.x-oo.com/flash-online-games/kartenspiele/solitaire.html
Broken in both e10s/non-e10s with the Flash testcase. Regression range: m-c: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=51e3cb11a258&tochange=8af644c9b616 m-i: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c24fb4429029&tochange=ffd1b16f058b David Parks — Bug 1018639 - Maintain separate cursors in chrome and client processes. r=roc David Parks — Bug 1018639 - Reset the cursor on WM_SETCURSOR message when pointer is over content. r=jimm
Status: UNCONFIRMED → NEW
status-firefox40: --- → affected
status-firefox41: --- → affected
status-firefox42: --- → affected
status-firefox43: --- → affected
tracking-firefox41: --- → ?
tracking-firefox42: --- → ?
tracking-firefox43: --- → ?
Component: Untriaged → General
Ever confirmed: true
Product: Firefox → Core
FYI, Disabled protect mode of flash plugin fixes the problem (though cursor is flickering when moving it)
Yes but this cannot be a final solution for the normal user. Is there nothing else what can be done ? Is this parameter really a security issue ? I dont think so.
https://helpx.adobe.com/flash/kb/flash-object-embed-tag-attributes.html#main_Browser_support_for_Window_Mode__wmode__values This list contains the basic parameters and there is no security issue in chrome or in IE so far. Only in Firefox. Can this be fixed ?
jimm, can you help find an owner for this since it looks like the regressing bug was e10s related? thanks!
tracking-firefox41: ? → +
tracking-firefox42: ? → +
tracking-firefox43: ? → +
tracking-e10s: --- → ?
It is getting too late to fix this in FF41 given that we don't have a patch ready. Let's try to get this fixed in 42. Also, if this is e10s only, FF41 might be ok as e10s is disabled by default.
status-firefox41: affected → wontfix
It's not only e10s (you can try the testcase in the current FF40 where e10s is disabled by default), this bug is pretty annoying on various websites displaying Flash videos or games because the mouse cursor is flashing.
Summary: <param name="wmode" value="opaque"></param> Cursor in Flash no longer working → Mouse cursor flickers in Flash object with wmode opaque/transparent
The problem with this bug is not a security issue. Changing to wmode to "window" destroys my company's products, because we need overlapping HTML elements. As I secriped (in Bug 1207215, includes demo), Firefox prefers in "transparent"-mode to show the cursor-setting of the HTML-body (resp. of the browser). But not consequently, instead, the pointer-icon flickers between browser-cursor and Flash-cursor when mouse is moving. By clicking and moving at the same time, the Flash-cursor appears correctly. Firefox should not be in conflict with mouse-pointer settings of the Flash-plugin and should give priority to the plugin.
Maybe the same browser-plugin-conflict issue is the well known mouse-wheel problem. Firefox dispatches no mouse-wheel-events to the plugin.
Olly, any idea if someone is available to fix this annoying regression? It affects many video/game websites and some Flash apps for corporate.
No idea. I didn't review the regressing patches. roc might have some ideas, or jimm once he is back from vacation
But by default the regressing patches should be backed out.
Jim will be back in a few days, and since it's the beginning of a cycle, we might as well see if we can fix this on beta before backing out the original patches.
I see the flicker but I don't have any problems with cursors updating to the hand in the test case or this game: http://www.x-oo.com/flash-online-games/kartenspiele/lightning.html Since this reproduces in non-e10s we probably want to track this for m8 and get it fixed.
I backed cset d3a3a4a64303 out, it fixed the flicker problem and didn't reintroduce bug 1018639. I'm not sure why davidp felt we needed that code change.
Created attachment 8668375 [details] [diff] [review] backout d3a3a4a64303
Assignee: nobody → jmathies
Comment on attachment 8668375 [details] [diff] [review] backout d3a3a4a64303 oops, that wasn't a backout patch.
Created attachment 8668401 [details] [diff] [review] backout d3a3a4a64303
Attachment #8668401 - Flags: review?(roc) → review+
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox44: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Jim, could you fill the uplifts request to beta & aurora (if it makes sense)? Thanks
status-firefox40: affected → wontfix
Comment on attachment 8668401 [details] [diff] [review] backout d3a3a4a64303 Approval Request Comment [Feature/regressing bug #]: bug 1018639 [User impact if declined]: Moderate issues with mouse cursor flicker when hovering over flash applets that set a custom cursor. See test case for an example. Windows only. [Describe test coverage new/current, TreeHerder]: Manual testing by me. [Risks and why]: Low, the code that landed in bug 1018639 was e10s specific, which is held on aurora. If backing this patch out breaks something under e10s we'll have plenty of time to fix it. [String/UUID change made/needed]: none
Comment on attachment 8668401 [details] [diff] [review] backout d3a3a4a64303 Thanks, taking it as it fixes a graphic glitch. Should be in 42 beta 6.
status-firefox43: affected → fixed
status-firefox42: affected → fixed
This has also fixed bug 1204362 (which is similar)
You need to log in before you can comment on or make changes to this bug.