Added code to disable 'paste' if nothing is present in clipboard to paste.

Added code to disable 'paste' if nothing is present in clipboard to paste.

On right click in editable node context menu was always having 'paste'
option as enabled. Added check that if clipboard is not empty
then only show 'paste' option.

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

[ankit, 2014-08-06 08:23:42]

Raising this CL as per discussion  https://codereview.chromium.org/410873005/. 

@avi 
@groby
PTAL

[Avi (use Gerrit), 2014-08-06 14:59:29]

Why are you asking me?

This is a continuation of https://codereview.chromium.org/410873005/ for
technical reasons. Let's continue it with the reviewers you had there.

[darin (slow to review), 2014-08-06 16:31:33]

https://codereview.chromium.org/443073002/diff/1/chrome/browser/renderer_cont...
File chrome/browser/renderer_context_menu/render_view_context_menu.cc (right):

https://codereview.chromium.org/443073002/diff/1/chrome/browser/renderer_cont...
chrome/browser/renderer_context_menu/render_view_context_menu.cc:1376:
ui::Clipboard::GetForCurrentThread()->ReadAvailableTypes(
This is potentially an expensive call, right? Should we worry about this janking
up the UI thread of the browser? Perhaps there is no other way to implement this
behavior though?

[darin (slow to review), 2014-08-06 16:32:25]

How important is it to solve this bug? How often do users clear their clipboard?

[ankit, 2014-08-06 16:40:06]

On 2014/08/06 14:59:29, Avi wrote:
> Why are you asking me?
> 
> This is a continuation of https://codereview.chromium.org/410873005/ for
> technical reasons. Let's continue it with the reviewers you had there.

@Avi
Please correct me if my understanding is not correct.
As per discussion on https://codereview.chromium.org/410873005/. Abarth
has suggested to raise a new CL, so I raised a new CL and added you as 
you are one of the owners for files under 'renderer_context_menu/' folder.

[ankit, 2014-08-06 16:42:56]

On 2014/08/06 16:32:25, darin wrote:
> How important is it to solve this bug? How often do users clear their
clipboard?

When user starts the system, then on clipboard 
there are no items to present.
Currently same scenario is handled when right click is 
performed on omnibox.

[ankit, 2014-08-06 16:44:38]

On 2014/08/06 16:31:33, darin wrote:
>
https://codereview.chromium.org/443073002/diff/1/chrome/browser/renderer_cont...
> File chrome/browser/renderer_context_menu/render_view_context_menu.cc (right):
> 
>
https://codereview.chromium.org/443073002/diff/1/chrome/browser/renderer_cont...
> chrome/browser/renderer_context_menu/render_view_context_menu.cc:1376:
> ui::Clipboard::GetForCurrentThread()->ReadAvailableTypes(
> This is potentially an expensive call, right? Should we worry about this
janking
> up the UI thread of the browser? Perhaps there is no other way to implement
this
> behavior though?

@darin
Not sure about how expensive this call is.
I am not able to find any other way to implement this behavior.

[Avi (use Gerrit), 2014-08-06 18:03:36]

Yes, I'm an owner, but by the time you added me as a reviewer you already had
three other reviewers reviewing one file.

So I left because it looked like you already had it handled. Same situation
here.

[groby-ooo-7-16, 2014-08-06 18:36:03]

Avi: You're the only owner on here.

Ankit: As I suggested on previous CL, please remove non-owners and work with
avi.

[Avi (use Gerrit), 2014-08-06 18:38:11]

On the previous bug incarnation Ankit got a NAK. That at least needs to be
addressed. I won't LG over someone else's explicit objection.

[darin (slow to review), 2014-08-06 23:54:48]

On 2014/08/06 16:31:33, darin wrote:
>
https://codereview.chromium.org/443073002/diff/1/chrome/browser/renderer_cont...
> File chrome/browser/renderer_context_menu/render_view_context_menu.cc (right):
> 
>
https://codereview.chromium.org/443073002/diff/1/chrome/browser/renderer_cont...
> chrome/browser/renderer_context_menu/render_view_context_menu.cc:1376:
> ui::Clipboard::GetForCurrentThread()->ReadAvailableTypes(
> This is potentially an expensive call, right? Should we worry about this
janking
> up the UI thread of the browser? Perhaps there is no other way to implement
this
> behavior though?

To partially answer this question: erg@ tells me that this should not
be expensive on X11 as the current state of the clipboard is updated
asynchronously.

[ankit, 2014-08-07 04:21:10]

On 2014/08/06 23:54:48, darin wrote:
> On 2014/08/06 16:31:33, darin wrote:
> >
>
https://codereview.chromium.org/443073002/diff/1/chrome/browser/renderer_cont...
> > File chrome/browser/renderer_context_menu/render_view_context_menu.cc
(right):
> > 
> >
>
https://codereview.chromium.org/443073002/diff/1/chrome/browser/renderer_cont...
> > chrome/browser/renderer_context_menu/render_view_context_menu.cc:1376:
> > ui::Clipboard::GetForCurrentThread()->ReadAvailableTypes(
> > This is potentially an expensive call, right? Should we worry about this
> janking
> > up the UI thread of the browser? Perhaps there is no other way to implement
> this
> > behavior though?
> 
> To partially answer this question: erg@ tells me that this should not
> be expensive on X11 as the current state of the clipboard is updated
> asynchronously.

@darin
If it is not an expensive call, in that case I think we can proceed with this
change.
PTAL

[ankit, 2014-08-08 15:23:36]

On 2014/08/07 04:21:10, ankit wrote:
> On 2014/08/06 23:54:48, darin wrote:
> > On 2014/08/06 16:31:33, darin wrote:
> > >
> >
>
https://codereview.chromium.org/443073002/diff/1/chrome/browser/renderer_cont...
> > > File chrome/browser/renderer_context_menu/render_view_context_menu.cc
> (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/443073002/diff/1/chrome/browser/renderer_cont...
> > > chrome/browser/renderer_context_menu/render_view_context_menu.cc:1376:
> > > ui::Clipboard::GetForCurrentThread()->ReadAvailableTypes(
> > > This is potentially an expensive call, right? Should we worry about this
> > janking
> > > up the UI thread of the browser? Perhaps there is no other way to
implement
> > this
> > > behavior though?
> > 
> > To partially answer this question: erg@ tells me that this should not
> > be expensive on X11 as the current state of the clipboard is updated
> > asynchronously.
> 
> @darin
> If it is not an expensive call, in that case I think we can proceed with this
> change.
> PTAL

@darin
PTAL

[darin (slow to review), 2014-08-08 18:18:13]

lgtm

[Avi (use Gerrit), 2014-08-08 18:18:32]

I understand abarth's objection now, and that it was for a previous version.
This version looks OK.

LGTM

[commit-bot: I haz the power, 2014-08-08 18:22:22]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ankit2.kumar@samsung.com/443073002/1

[commit-bot: I haz the power, 2014-08-08 21:51:00]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  android_dbg_triggered_tests on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tri...)

[commit-bot: I haz the power, 2014-08-08 23:03:48]

Change committed as 288461