And So It Begins… The Disinteroperability of the Web (Or Just a Harmless Bug…?)

When does a keyboard shortcut *not* do the same thing as the menu command it shortcuts? When it’s a Google docs copy command in Google Chrome, maybe?

Although I know that I, and I suspect many of the any readers of this blog, use keyboard shortcuts unconsciously, intuitively, on a regularly basis: ctrl/cmd-f for within page search, -c for copy, -x for cut, and -v for paste. I also suspect that keyboard shortcuts are alien to many, and that a more likely route to these everyday operations is through the file menu:

or (more unlikely?) via a right-click contextual pop-up menu:

As keyboard shortcut users, we assume that the keyboard shortcuts and the menu based operations do the same thing. But whether a bug or not, I noticed today in the course of using Google docs in Google Chrome that when I tried to copy a highlighted text selection using either the file menu Copy option, or the contextual menu copy option, I was presented with this:

(The -c route to copying still worked fine.)

With Chrome well on its way to becoming the world’s most popular browser, allowing Google to dominate not just our searchable view over the web, but also intermediate our direct connection to the web through the desktop client we use to gain access to it, this makes me twitchy… Firstly, because it suggests that whilst the keyboard shortcut is still routing copied content via my clipboard, the menued option is routing it through the browser, or maybe even the cloud where an online connection is present? Secondly, because in prompting me to extend my browser, I realised I have no real idea of what sorts of updates Google is regularly pushing to me through Chrome’s silent updating behaviour (I’m on version 19.0.1084.46 at the moment, it seems… 19.0.1084.46.

A lot of Google’s activities are driven by technical decisions based on good technical reasons for “improving” how applications work and interoperate with each other. But it seems to me that Google is also closing in on itself and potentially adopting technical solutions that either break interoperability, or include a Google subsystem or process at every step (introducing an alternative de facto operating system onto out desktop by a thousand tiny updates and extensions). So for example, whilst I haven’t installed the Chrome copy extension, I wonder if I had: would a menu based copy from a Google doc allow me to then paste the content into a Word doc running as a Microsoft Office desktop application, or paste it into my online WordPress editor. And if so, would Chrome be cacheing that copied content via the extension?

Maybe this is something and nothing. Maybe I’m just confused about how the cut-and-paste thing works at all. Or maybe Google is starting to overstep its mark and is opening up an attack on host operating system functions from installed browser base. Which as the upcoming most popular browser in the world is not a bad beachhead to have…

PS At least Google Public DNS isn’t forced onto Chrome users as the default way of identifying the actual IP address of a website that is used to actually connect the browser to it from an entered domain name or clicked on link…

Author: Tony Hirst

I'm a Senior Lecturer at The Open University, with an interest in #opendata policy and practice, as well as general web tinkering...

6 thoughts on “And So It Begins… The Disinteroperability of the Web (Or Just a Harmless Bug…?)”

  1. I’m using Chromium 18.0.1025.168 (Developer Build 134367 Linux) Ubuntu 11.10, and I get a slightly different error message, telling me that those operations are unavailable from the Edit menu, but can still be accessed with keyboard shortcuts (which are then listed).

  2. My guess would be that command-C simply copies (using your host OS’s built-in routines) the selected HTML source from the screen. Pasting that back in is equivalent (as far as Google Docs is concerned) to typing it afresh. This is limited in that it can’t always copy non-inline metadata, or off-screen content.

    However, if you use part of the Google Docs UI to trigger the copy/paste operations, then the javascript code which runs the UI has to have access to the host OS’s clipboard, which it wouldn’t normally have. Otherwise it would have to use its own non-OS clipboard, and you would only be able to paste back into Google Docs and not into other applications – and then if you pasted, it wouldn’t be immediately obvious whether it should paste the local Google Docs clipboard or the OS clipboard. Confusing.

    They could have implemented a workaround such as duplicating the content selection into a visible user-selectable area, selecting it (which you can do in javascript), then triggering a client-side copy operation (ditto) to get the data on to the system clipboard. I’ve done this on some hacky code in the past. But it’s ugly as heck, so instead they’ve gone for a slightly less ugly option: requiring a browser plugin.

  3. That’s sneaky! I hadn’t noticed this “update” as I only ever use the keyboard commands. It is rather odd though.

  4. What’s even more surprising that having installed the app a) it doesn’t appear to improve copy/paste e.g. I still can’t copy a chart from Spreadsheet to Doc (this app appears to be to enable offline use) and b) it doesn’t appear in my chrome extension settings chrome://chrome/extensions/ so the only way I can remove it is via the chrome store

Comments are closed.

%d bloggers like this: