Code review comment for lp:~osomon/oxide/touch-selection-api

> I’m currently adding unit tests for WebView.editingCapabilities, and facing an
> issue: the current implementation emits editingCapabilitiesChanged whenever
> the selection bounds change, which seems to cover most use cases, but one:
> when the user issues the Copy command, the contents of the clipboard change,
> and the editing caps potentially change with it (if the clipboard was empty,
> the PasteCapability becomes true). Emitting editingCapabilitiesChanged in
> WebView::executeEditingCommand() just after calling
> contents::WebContents::Copy() doesn’t do the trick, as copying content to the
> clipboard is async (and thus by the time the signal is emitted the content
> might not have been copied to the clipboard yet).
>
> In fact the problem is more general than that: if content is copied to the
> clipboard outside of the application, there’s no way to get notified of it and
> update the editing caps. There’s a comment in
> chrome/browser/ui/views/frame/browser_view.cc (above
> BrowserView::CutCopyPaste()) that suggests that this is currently not possible
> anyway.
>
> Is WebView.editingCapabilities a good idea after all?

We need some way of exposing this from WebView in order to support editing commands in an application menu. If possible, I'd like to not have this information duplicated in 3 different places (it's already exposed specifically for context menus).

Is the lack of notifications Chromium specific, or is that something we can get from Qt? (I'm not sure what QClipboard::dataChanged does)