Google Drive Gains Support for Cut, Copy, and Paste Shortcuts Across Multiple Chrome Tabs

[Unggoy Murderer]

Yeah, or, the copy keystroke is saved into your Google Drive from one tab, and then when you go to the other tab, the paste keystroke command is sent to Google Drive (where the actual file copying and pasting occurs, duh), and the resulting html/js view is sent back to your browser. This wouldn't need to break the sandboxing of tabs.

I have no idea why it is only (currently) Chrome specific, but I would like to hope that that isn't an IE6-esque behaviour, as you say.

As I mentioned in the original message, that would indeed be valid. However, I doubt it would be a suitable solution due to the additional networking load, and it wouldn't work offline (a lot of Google's web apps run the same stuff offline on Chrome OS).

 

[porte9]

As a web dev, this isn't quite as trivial as you think. I suspect this is a "work around" to tab sandboxing.

Each tab has its own process and memory, and they won't be able to access and / or modify each others content. So when you did cmd+c on one tab, the other wouldn't be "aware" of the content that has been "copied". Google have probably added a feature to Chrome that will listen for this behaviour, then pass it between the sandboxed processes safely.

I suppose they could pass the information back to the server and then have it retrieved on a polling basis, but that would be extra load on infrastructure, and wouldn't work offline.

Just even more evidence that Google Chrome is the new IE 6.

They could have just put the URLs to be copied in the clipboard.

 

[Unggoy Murderer]

They could have just put the URLs to be copied in the clipboard.

It's not as easy as that either. Clipboard access is a major privacy concern, and browsers implement pretty stringent APIs to moderate access to it, or block access to it altogether.

Writing to the clipboard is generally straightforward, however the retrieval will be a minefield of compatibility.

 

[kc9hzn]

As a web dev, this isn't quite as trivial as you think. I suspect this is a "work around" to tab sandboxing.

Each tab has its own process and memory, and they won't be able to access and / or modify each others content. So when you did cmd+c on one tab, the other wouldn't be "aware" of the content that has been "copied". Google have probably added a feature to Chrome that will listen for this behaviour, then pass it between the sandboxed processes safely.

I suppose they could pass the information back to the server and then have it retrieved on a polling basis, but that would be extra load on infrastructure, and wouldn't work offline.

Just even more evidence that Google Chrome is the new IE 6.

This reminds me of trying to pass Redux stores between windows of Electron instances. (There may have been better ways of doing what I was trying to do, but because specifically, I was working with OpenFin pop outs and docking windows, it’s not like there was a lot of documentation out there on the best way to handle such things with React. Plus, it was a bit of a “when all you have is a hammer, everything looks like a nail” situation. For what it’s worth, OpenFin is based on Electron, which is based on Chrome, of course.) I realized that each window had its own memory space, which meant that each window had its own Redux store. I had to use OpenFin’s message passing features to pass the Redux store around (or at least the information that needed to be mirrored across Redux stores).