Thanks for the trace.  It shows that each paste event causes the Blink main thread to sleep for 100ms.  Unfortunately, this codepath is not sufficiently traced so the cause of the sleep is unclear (it's just a generic "RunTask").  Because the problem is OS X specific, I suspect it's blocking on an operating system call.  It may indeed be the call that causes the "Edit" menu to blink.

If you want to investigate this further, I'd suggest finding where that is in the code and more TRACE_EVENT0 narrowly around the OS call (and I would be fine approving a patch adding such TRACE_EVENT0 to help other people in the future).  Then the next step may be to figure out if there is a different way to invoke it, for example in an asychronous mode if that exists, so we can get the same performance as Firefox and Safari.

For history CL that
do handle input cmd+V message immediately be renderer without
sending it back to browser process, but has side effects because we will
don't blinking by top menu item:
https://codereview.chromium.org/2338923003/

I have an similar experience in paste into Google spread sheet on Mac. This is happened sometimes but not every time. It is hard to re-produce.

Note: On Edit menu items, "Copy" and "Cut" aren't grayed when there are no selections in Chrome. It this an expected behavior? I'm not using MacOS frequently. So, I'm not sure.

It seems this is content/ or chrome/ changes rather than Blink changes. Since, it is caused by Blink changes, all platforms are affected.

Please do bi-sect which change makes pasting slower.

yosin@, the bug originally reported is definitely Mac-only, consistently takes 100ms, and 100% reproducible.  You're describing a non-reproducible, larger magnitude, cross-platform behavior, so I think you should file a separate bug.

+yosin@, see my comment above.

>#c8, I attempt to test on my Mac book and I aware this is Mac only issue.

BTW, the last change of ui/base/clipboard/clipboard_mac.mm
http://crrev.com/2276183002 on Aug 30, 2016

Unable to repro this issue on MAC (10.11.6) for Google Chrome Stable Version - 53.0.2785.116

Tested this issue on Mac OS 10.12 using chrome latest stable M53-53.0.2785.143. Observed no lagging in pasting the items in chrome. 

As per comment #8 adding @erikchecn for more updates on this bug and removing bisect label for now.

I did some research into a similar problem here: https://bugs.chromium.org/p/chromium/issues/detail?id=651203

The problem is that ([[NSApp mainMenu] performKeyEquivalent:event]) blocks the main thread for about 100ms. I suspect this is unusual, and Chrome is doing something weird to trigger this, but I don't know what that is.

As #12, this is not Blink side issue.
Remove component:Blink* tag.

I uploaded [1] a sample in  http://crbug.com/603881#c24  of the ~million ObjC method calls that are made when AppKit does [[NSApp mainMenu] performKeyEquivalent:event]

A portion of this is due to `Bookmarks` -- pressing a shortcut on Chrome Mac will ask every bookmark you have whether it wants to `perform` that shortcut. It recurses through all folders and the code is not well optimized. There may be some things we can do by adding a delegate for the `Bookmarks` NSMenuItem, or putting a "Show bookmarks here" item before actually populating the menu, so only users who use the Bookmarks mainMenu item are affected.

There is actually a use case for this code path -- it's possible we have users that set up keyboard shortcuts for their bookmarks via System Preferences, and this relies on us having populated `Bookmarks` fully. (see attached).

(there is also a lot of other gunk in that sample -- it's not just bookmarks).

[1] https://bugs.chromium.org/p/chromium/issues/attachment?aid=268851

 Issue 677860  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cf95689a88664eb44716632cc7320d18ed3324ba

commit cf95689a88664eb44716632cc7320d18ed3324ba
Author: Trent Apted <tapted@chromium.org>
Date: Wed Nov 22 00:01:10 2017

Mac: Lazily populate bookmarks menus.

Currently the first time you press a key (any key) in WebContent
on Chrome Mac, Chrome makes a NSMenuItem for every bookmark you have,
and spawns tasks to convert each favicon. These then persist in memory
to service the Bookmarks menu on the menubar.

On my profile with ~1000 bookmarks, Chrome jumps from 95MB to 105MB
resident memory if I open about:blank and press a key. And there is
noticeable lag. Each browser window's App menu also has a full
bookmarks tree, populated once the 'Bookmarks' item is hovered over,
and persisted in memory; taking up about 800kB (approximately doubling
the browser process memory used by a single-tab browser window).

In order to populate these lazily, the bookmarks menu must respond `NO`
to -[NSMenuDelegate menuHasKeyEquivalent:..]. Otherwise the menu is
fully populated on the first key event to see if any bookmark titles
match the event. With this in place, we can leave all bookmarks
submenus empty, but set a delegate that AppKit uses to populate the
menu when the user first shows it.

Bug:  33102 ,  647183 ,  733921 ,  786845 
Change-Id: Idc0a28cf9483f7161dc3fbe9bd6cda717e65de98
Reviewed-on: https://chromium-review.googlesource.com/778644
Commit-Queue: Trent Apted <tapted@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#518459}
[modify] https://crrev.com/cf95689a88664eb44716632cc7320d18ed3324ba/chrome/browser/app_controller_mac.mm
[modify] https://crrev.com/cf95689a88664eb44716632cc7320d18ed3324ba/chrome/browser/app_controller_mac_browsertest.mm
[modify] https://crrev.com/cf95689a88664eb44716632cc7320d18ed3324ba/chrome/browser/ui/cocoa/app_menu/app_menu_controller.mm
[modify] https://crrev.com/cf95689a88664eb44716632cc7320d18ed3324ba/chrome/browser/ui/cocoa/bookmarks/bookmark_menu_bridge.h
[modify] https://crrev.com/cf95689a88664eb44716632cc7320d18ed3324ba/chrome/browser/ui/cocoa/bookmarks/bookmark_menu_bridge.mm
[modify] https://crrev.com/cf95689a88664eb44716632cc7320d18ed3324ba/chrome/browser/ui/cocoa/bookmarks/bookmark_menu_bridge_unittest.mm
[modify] https://crrev.com/cf95689a88664eb44716632cc7320d18ed3324ba/chrome/browser/ui/cocoa/bookmarks/bookmark_menu_cocoa_controller.h
[modify] https://crrev.com/cf95689a88664eb44716632cc7320d18ed3324ba/chrome/browser/ui/cocoa/bookmarks/bookmark_menu_cocoa_controller.mm

Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!

Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!