summaryrefslogtreecommitdiffstats
path: root/chrome_elf
diff options
context:
space:
mode:
authorlazyboy <lazyboy@chromium.org>2015-04-30 18:31:09 -0700
committerCommit bot <commit-bot@chromium.org>2015-05-01 01:32:28 +0000
commit6573fb18a3df495e20b26bd00e04d93e6a421b81 (patch)
treebd78115b0420a80cd77de43c99a3cde1a9518710 /chrome_elf
parent53dbf912a44deafb264535185dff77761769f6a7 (diff)
downloadchromium_src-6573fb18a3df495e20b26bd00e04d93e6a421b81.zip
chromium_src-6573fb18a3df495e20b26bd00e04d93e6a421b81.tar.gz
chromium_src-6573fb18a3df495e20b26bd00e04d93e6a421b81.tar.bz2
Do not use ContextMenuParams (after mutating it) to decide where to show platform menu.
Instead, keep ContextMenuParams as is and calculate the position where it is required (RVCMViews/RVCMMac) Mutating ContextMenuParams has consequences, if the param is passed back to blink, then things break b/c it expects the unmodified params (specifically the coordinates). Rotating PDF is one example where the ContextMenuParams is passed back to blink as we call RenderViewContextMenu::RunPluginActionAt(). In theory MediaPlayerActionAt() should also have the breakage. BUG=461667 Test=Easier to test with PDF viewer, Open a page in tab where a PDF is embedded. e.g. http://acroeng.adobe.com/Test_Files/browser_tests/embedded/embed2.html Right click on PDF that are embedded in html page then in context menu choose rotateclockwise. This should rotate the PDF as expected. Review URL: https://codereview.chromium.org/1115013003 Cr-Commit-Position: refs/heads/master@{#327860}
Diffstat (limited to 'chrome_elf')
0 files changed, 0 insertions, 0 deletions