diff options
| author | estade@chromium.org <estade@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-07-24 18:32:43 +0000 |
|---|---|---|
| committer | estade@chromium.org <estade@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-07-24 18:32:43 +0000 |
| commit | e18c145118e5ec17688c03cd95e44b9cdd97cce0 (patch) | |
| tree | 989973ca2409db35ade634139d1bfb8e17fe5d94 /DEPS | |
| parent | 4a070b18126823613698958b8ea42d71585a0b6c (diff) | |
| download | chromium_src-e18c145118e5ec17688c03cd95e44b9cdd97cce0.zip chromium_src-e18c145118e5ec17688c03cd95e44b9cdd97cce0.tar.gz chromium_src-e18c145118e5ec17688c03cd95e44b9cdd97cce0.tar.bz2 | |
Paste at the beginning of a middle click rather than after letting the page handle it.
The problem is that the page changes the focused area in the mouse release handler.
Even after this fix, it is possible to paste into the wrong place. The place that gets the text is whichever text input is focused when the browser sends back the clipboard contents, not the text input that is focused when the middle click is handled. This has always been true but seems harmless in most cases.
BUG=17504
TEST=open gmail chat. Put something in your PRIMARY. Click in the text entry area. Middle click in the chat display area. The selection shouldn't paste into the text entry. Otherwise, middle click paste should still work.
TEST=the reduction in the bug acts as expected
Review URL: http://codereview.chromium.org/160065
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21553 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'DEPS')
0 files changed, 0 insertions, 0 deletions