[Mac] Don't load -pasteAndGo: menu entry which will be bounced.

[Mac] Don't load -pasteAndGo: menu entry which will be bounced.

AutocompleteTextfieldEditor implements guards in -paste: and
-pasteAndGo: to prevent pasting in giant texts.  Modify the
right-click menu to not load -pasteAndGo: if it's going to be bounced
anyhow.

BUG=214622
TEST=Generate large clipboard, right-click omnibox, check for "Paste and Go" item.


Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=190574

[Scott Hess - ex-Googler, 2013-03-22 23:38:28]

This prevents the bad case, 9999 chars is stuck a bit janky, but not nearly so
bad.

There definitely are better solutions which should be prodded.  It just bugs me
that we're setting up a menu item which we can guarantee will not work.  It's
likely/possible with this change that the check in -pasteAndGo: can be removed,
and/or that the -validateMenuItem: for -pasteAndGo: could be removed.  Maybe? 
I'm not sure.

[Mark P, 2013-03-23 00:47:08]

lgtm

On 2013/03/22 23:38:28, shess wrote:
> This prevents the bad case, 9999 chars is stuck a bit janky, but not nearly so
> bad.
> 
> There definitely are better solutions which should be prodded.  It just bugs
me
> that we're setting up a menu item which we can guarantee will not work.  It's
> likely/possible with this change that the check in -pasteAndGo: can be
removed,
> and/or that the -validateMenuItem: for -pasteAndGo: could be removed.  Maybe? 
> I'm not sure.

Maybe?  What if the clipboard changed after the context menu is created?

There's no harm in leaving that check in pasteAndGo or that check in
validateMenuItem, right?  Let's be defensive.

--mark

[commit-bot: I haz the power, 2013-03-25 17:47:41]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/shess@chromium.org/12544034/1

[Scott Hess - ex-Googler, 2013-03-25 17:51:00]

On 2013/03/23 00:47:08, Mark P wrote:
> lgtm
> 
> On 2013/03/22 23:38:28, shess wrote:
> > This prevents the bad case, 9999 chars is stuck a bit janky, but not nearly
so
> > bad.
> > 
> > There definitely are better solutions which should be prodded.  It just bugs
> me
> > that we're setting up a menu item which we can guarantee will not work. 
It's
> > likely/possible with this change that the check in -pasteAndGo: can be
> removed,
> > and/or that the -validateMenuItem: for -pasteAndGo: could be removed. 
Maybe? 
> > I'm not sure.
> 
> Maybe?  What if the clipboard changed after the context menu is created?
> 
> There's no harm in leaving that check in pasteAndGo or that check in
> validateMenuItem, right?  Let's be defensive.

Yeah, but it's extra code which provides friction.  Once you start thinking
about how the pasteboard can change while the context menu is visible, you
realize that you can't do things the way we're doing it.  Instead of adding if
the pasteboard is right, the code would need to always add, and then
enable/disable as things change, BUT in the past bugs have been logged to not
show items which are disabled in this menu, so I don't think there's any
positive outcome.

Anyhow, remember to comment all of this out if you want to test deeper changes
on OSX :-).

[commit-bot: I haz the power, 2013-03-26 06:52:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/shess@chromium.org/12544034/1

[commit-bot: I haz the power, 2013-03-26 07:32:10]

Change committed as 190574