Issue 9997  has been merged into this issue.

 Issue 9998  has been merged into this issue.

thanks for the report.

this is similar to  issue 16083 

Safari fails too
IE and FF are OK

 Issue 19468  has been merged into this issue.

(No comment was entered for this change.)

Bug filed upstream : https://bugs.webkit.org/show_bug.cgi?id=28648

(No comment was entered for this change.)

 Issue 22029  has been merged into this issue.

I'm not so sure that this is a WebKit bug.  Brett would know though since he 
implemented zooming.

 Issue 26921  has been merged into this issue.

 Issue 31237  has been merged into this issue.

 Issue 36526  has been merged into this issue.

Upstream bug (with a rdar number): https://bugs.webkit.org/show_bug.cgi?id=26424

(No comment was entered for this change.)

I'm not able to reproduce this issue on Safari/ToT Webkit on Mac.  Zooming in and 
clicking the a plugin works as expected.

 Issue 37738  has been merged into this issue.

 Issue 38799  has been merged into this issue.

 Issue 35808  has been merged into this issue.

This affects windowless plugins on all platforms; since all plugins on the Mac are windowless it's much more 
severe there (and Carbon plugins need specific extra workarounds), so  bug 26466  is tracking the Mac 
separately to implement a temporary workaround.

The reason Mac Safari isn't affected by this is almost certainly that it uses OS-level views for plugins, causing 
it to use a different event dispatch path for plugin events.

(Note that comment 25, the multi-monitor setup on the Mac, is a completely unrelated--and now fixed--
bug.)

(No comment was entered for this change.)

 Issue 31098  has been merged into this issue.

So that people don't get confused when testing this: the Mac version of Chrome will no longer show the 
symptoms of this bug, because of the workaround landed in  bug 26466 . The underlying problem (inconsistent 
size vs coordinate information coming into the plugin host) is still just as true for Mac Chrome as for the other 
platforms, however.

The WebKit bug report has a nice URL to test it out:

http://www.longwhiteclouds.co.nz/kidslaurensquiz.php

The flash animation draws a cursor where it thinks the cursor is, very useful to 
confirm when this will be fixed.

On a related note, can someone confirm if this is happening on Safari for Windows, 
because this bug will soon be 1 year old over on webkit and noone has complained of 
anything like it (except for https://bugs.webkit.org/show_bug.cgi?id=28648 which 
jasneet has filed earlier and is a duplicate of the current upstream bug)

Yes, I've just installed safari 4.0.5 and it behaves in exactly the same way.

I don't get why but it's working fine for this URL:

http://www.engadget.com/2010/04/02/quake-ii-gwt-port-proves-html5-isnt-just-for-
video/

...and still doesn't for the other one I posted earlier:

http://www.neowin.net/news/the-iphone-4g-from-sprint-kind-of

What's the differences between those two usecases? Both are embedded in a webpage, 
both use flash, could the difference be about the video's encoding?

The first uses windowed mode (no wmode specified, so it gets the default of "window"), the second uses 
windowless mode (wmode is set to "transparent"). This bug only affects windowless plugins.

(Both URLs behave the same on OS X, because all plugins are windowless on the Mac.)

Please just star this issue if you want to get updates on progress. We know exactly what the issue here is, so 
more reports aren't necessary at this point.

I'm going to remove a lot of the old comments, since there is quite a bit of duplicate or confusing information 
here at the moment.

 Issue 42912  has been merged into this issue.

 Issue 42935  has been merged into this issue.

(No comment was entered for this change.)

 Issue 43414  has been merged into this issue.

 Issue 43290  has been merged into this issue.

 Issue 43676  has been merged into this issue.

 Issue 35102  has been merged into this issue.

 Issue 45519  has been merged into this issue.

 Issue 46308  has been merged into this issue.

 Issue 48850  has been merged into this issue.

 Issue 48783  has been merged into this issue.

 Issue 50162  has been merged into this issue.

 Issue 46814  has been merged into this issue.

 Issue 50529  has been merged into this issue.

 Issue 50896  has been merged into this issue.

 Issue 50880  has been merged into this issue.

Fixed. Please see issue https://code.google.com/p/chromium/issues/detail?id=50997 for details.

 Issue 50997  has been merged into this issue.

https://bugs.webkit.org/show_bug.cgi?id=42987

Adding ForMerge, since Darin suggested merging this to the M6 branch in  bug 50997 .

 Issue 49335  has been merged into this issue.

If someone does merge this to M6, please merge  bug 51078  as well.

 Issue 50219  has been merged into this issue.

(No comment was entered for this change.)

 Issue 49436  has been merged into this issue.

 Issue 47878  has been merged into this issue.

 Issue 52747  has been merged into this issue.

 Issue 48013  has been merged into this issue.

This issue is marked as M6. Are you sure it is? Dear owner, please update the milestone accordingly.

This isn't going to make m6 at this point.  Moving to M7, please close if this is already landed on the trunk.

I fixed it and merged to M6 a long time ago.
Could you please verify it?

If you merged this to M6, is there a reason you didn't merge  bug 51078  as requested above? There was never any indication that this was merged to M6, so I hadn't worried about it.

 Issue 53772  has been merged into this issue.

 Issue 43720  has been merged into this issue.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)