ummary of the last 100 comments, since people clearly aren't reading
them before leaving their own redundant comments.

This affects:
- Multiple distros
- Both 32 and 64 bit
- Browsers other than Chrome, but it seems to be worse in Chrome for reasons
  that aren't yet clear.

One user reports it affects gnash as well, but that may be a different bug.

The upstream Ubuntu bug is a trainwreck of useless comments but you can
subscribe to it to learn about updates:
  https://bugs.edge.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/410407

The problem seems to be made worse by:
- compiz (some people found turning it off fixes the problem; others find it
          doesn't matter)
- nspluginwrapper (as with compiz, unclear whether it fixes)
- GTK 2.18's client side windows (setting GDK_NATIVE_WINDOWS=1 works for some,
                                  not for others)

Known workarounds aside from toggling the above:
 - Hold down middle mouse button while clicking left button

In general, even if it's a Flash bug we are interested in working around it
if possible.

From now on, I will delete any new comments that aren't adding new information.
Please click the star button on the bug to get informed of updates.

This is a very helpful comment from the Ubuntu bug.  Perhaps there's an off-by-one in our 
positioning somewhere?

"I have a theory as to the cause.  I'm experiencing this in Chromium with
Compiz on, but I don't think it's the fault of either.  When you hover
over certain buttons/items in a flash box, they register as links with
the OS, and the mouse changes to show that.  For most cursors it changes
to be a hand, on mine, the cursor just blinks, to each their own.
However, when the cursor is in link mode over flash, and you click, the
cursor is moved to the right by 1 pixel.  I can verify that it's not
just my mouse moving because it works on A) my trackball, and B) my
touchpad, with my hands off the ball/pad respectively.  Flash registers
this click/move as a Drag, not a Click, and doesn't click the button.  I
can 99% guarantee this, because if I move my mouse to the left at JUST
the right rate, the 1 pixel shift is counteracted, the click goes
through as a click, and the button registers.  This also explains the
right-click trick, and very rapid click trick, as both of those register
clicks before flash can shift the cursor.  I'd like confirmation, from
anyone with a low enough resolution monitor and a trackpad with separate
buttons, to see the shift, and that it's only on links in flash."

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=31734 

------------------------------------------------------------------------
r31734 | evan@chromium.org | 2009-11-11 15:49:51 -0800 (Wed, 11 Nov 2009) | 15 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/plugin/plugin_thread.cc?r1=31734&r2=31733

linux: work around "flash does not register any clicks" bug

I had a flash of inspiration!  Setting GDK_NATIVE_WINDOWS in the
environment doesn't work because we don't propagate the setting down
into the plugin subprocess.  I confirmed that setting it manually
fixes it.  That is, on this computer I previously had the no-clicks
bug and with this change the problem is solved.

Note: there are multiple confusing levels to this bug; if
nspluginwrapper gets involved I still encounter the problem.
But this definitely fixes the problem for me.

BUG=20654

Review URL: http://codereview.chromium.org/384059
------------------------------------------------------------------------

Hi evan, 
I can confirm that it fixed the problem for me!
I just upgraded to  build 31785 and it solved my problem.
Wow finally a breakthrough with this annoying bug.
Thank you evan.

PS: I know I'm off topic but maybe this helps someone.
This fix, the fact that you set GDK_NATIVE_WINDOWS=1 also helped me with another 
issue I had.
I am using Easystroke for mouse gestures. And before this fix, it would never 
register gesture strokes on a flash clip. 
That is solved as well with this fix :D
So thanks again!
(I haven't checked but maybe somebody has complained about this or submitted a bug 
report about this)

 Issue 27108  has been merged into this issue.

 Issue 27673  has been merged into this issue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=31734 

------------------------------------------------------------------------
r31734 | evan@chromium.org | 2009-11-11 15:49:51 -0800 (Wed, 11 Nov 2009) | 15 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/plugin/plugin_thread.cc?r1=31734&r2=31733

linux: work around "flash does not register any clicks" bug

I had a flash of inspiration!  Setting GDK_NATIVE_WINDOWS in the
environment doesn't work because we don't propagate the setting down
into the plugin subprocess.  I confirmed that setting it manually
fixes it.  That is, on this computer I previously had the no-clicks
bug and with this change the problem is solved.

Note: there are multiple confusing levels to this bug; if
nspluginwrapper gets involved I still encounter the problem.
But this definitely fixes the problem for me.

BUG=20654

Review URL: http://codereview.chromium.org/384059
------------------------------------------------------------------------

(No comment was entered for this change.)

So, evan, what more do we do with this bug?

Should we mark it fixed and open new bugs if your fix doesn't work for other 
configurations? That is my preference.

I think I was leaving it open and tagging it mstone-4 to remind myself to merge it to 
the branch.  I agree with your preference otherwise.

This made the 249 branch, so I'm closing.

If you are still having problems with clicking on Flash and have verified you're using 
the newest Google Chrome you can find, please file a new bug with as much system info 
as possible (in particular the output of "nspluginwrapper -l").