 Mae'r adegau eistedd. a fydd yn gwahanol y gallwn. Ieem ni, rwy'n gwahanol. Felly, yw'r adegau, rwy'n gwahanol. Mae'n gwahanol. Rwy'n gwybod. Mae'n ddigwydd, ac ydy'r perffyald. Mae'n rwy'n gweithio'n gweithio'n gweithio. A'r pethau'n gymdau. Rwy'n gweithio... Mae'r ddechrau a phasdwyd ac mae'n gweithio. Mae'n gobeithio'n gobeithio'n gweithio. Mae'n gweithio'n gweithio. OK. I'll talk, talk, talk, and I'll shoot anyone that looks like they're leaving. If the... No, never mind. Can you just try to get the eye? Here we go. Perfect. So my thesis is that web copy and paste is a disaster. And anyway, here we go. So beforehand, it's good to look at always the competition. Before we get too worried about the fact something doesn't work in collaboration online. Let's try the competition. So if you copy and paste this Google spreadsheet, which is just a fairly standard xysx file, there's no magic tricks or nasty things in it, and you copy it in Google Docs. This is what you get, which is pretty good. So I mean, we get some of these numbers and things, but no charts, all the formulae are broken and so on. If we do an Excel, interestingly, we get a different set of brokeage. So in this case, we actually get some of the conditional formats coming across and all the numbers are zero and stuff and still no charts. And of course, in the old collaborate online, I guess prior to 4.2, you would get a text import dialogue, which was not great. So we need to fix that. Of course, if you were pasting inside the same document, you had this internal copy and paste, which basically keeps the stuff on the server and just moves it around. It's as good as or as bad as our internal copy and paste was originally. And of course, no data moves around. It's rather nice. It stays on the server and all is good. But the customers complain because they copy and then they're surprised that they can't paste it in another tab or so. So how can we fix that? Well, we look at the web clipboard paste APIs, and they're very, very weird and they're pretty mixed. I don't know if you've ever seen these dialogues. Your browser can't access the clipboard. Have you seen the one? So we have an equivalent, which is limited access. Use these keyboard shortcuts. There's quite a lot of work have gone into these. You'll see on Macs, they often have a Mac sign instead of a control sign. Someone's put a lot of love and care into explaining to the user why it's so bad, although not very good explanation. So there's a whole load of horrible things here. Security is, of course, a primary concern. But in terms of security, you can often work around it. So you have to have selected text in order to be able to copy something onto the clipboard. So, well, why not just create a hidden text entry and put the text in it and then select it and then you can copy onto the clipboard. Great. So there's a whole load of things like this and you just have to keep tweaking and fooling around and retrying this nonsense until you're actually allowed to write stuff to the clipboard. And since none of this is visible to the user, all of that security foo is a total waste of time and just makes things fragile and broken. So ironically, IE11, which is the bet noir of web developers, it is the browser from hell that breaks all the modern JavaScript you want. And every time you think you've got a good idea to clean up your JavaScript, it doesn't work on IE11, actually had a really good idea, which was this. When you wanted to do a copy of paste, it would go, oh, well, do you want to let this web page actually use the clipboard? And this is, you would think, a reasonably sensible thing to ask. Unfortunately, it didn't catch on. So what can you do? So Google Docs has an even more refreshing approach. So Google's Chrome ship a browser that doesn't work by default for copy and paste, presumably so their security team gets off scot-free out of jail. It's not our problem that he was watching your copy and paste buffer as you typed in another file. But Google Docs, obviously they want their users to make it usable. So the same company ships a plug-in for its own browser that you must go away and install in order to be able to copy, cut and paste. So it would be just great if this team talked to this team and actually installed, you know, just tried to fix the situation. Of course, in theory, there are all sorts of horrible things you can do with copy and paste. So for example, if you have PNG images, you can create a relatively small PNG file that explodes. It's just the optimal compression thing to like terabytes of nothing and can consume all your memory in theory. And so it's a massive security risk to allow anyone to paste a PNG. So interestingly, and we'll come to this later, when you paste images, they typically decompress to operating system resources, flat buffers of pixels, which are much bigger all the time, but in the corner case might be smaller. Crazy. Anyway, so the other problem is that they really don't want that little bad hat app sitting there, snooping your clipboard all the time. So yes, so there is all sorts of other bad ideas. Like so jQuery is something that's supposed to make writing software easy in JavaScript. I don't know if you've read JavaScript, but the basic idea of JavaScript is to sort of hybridize Perl with like a single global state store, which is the DOM, like a massive global variable. So you search with all these ridiculous regular expressions in your massive global variable and you grub around. Anyway, but one of the nice things is that when you tap, for example, the click event, which is supposed to be a privileged event, so you can actually access the clipboard when someone's actually interacted with it in the event handler. But of course the click event actually isn't this, jQuery making up an event from something in a timer somewhere later that lost your privilege. So yeah, some pretty horrible stuff. On iOS we then have to have, we actually have to have an href to hash in order to get the privilege to be able to get stuff off the clipboard. This is kind of like the world's least documented misfeature and it only affects iOS. Interestingly, as a general rule, Chrome will run any JavaScript that you give it perfectly, even if the JavaScript is wrong. You know, even with the bugs in it, it works in Chrome for some reason. No one knows why this is, but on every other browser it just breaks. So yeah, IE11, so there is at least a copy paste API so you can get an object for the clipboard and you can write to it or read from it. One of the great wonders of this is that when you read from it you sometimes get an error, but sometimes you don't get an error depending on browser. So you don't really know if there is nothing on it or whether you just failed to read. In other cases, when you try and write to it it says, oh I successfully wrote, but it's actually writing it to like an isolated app-specific secure clipboard that no other application can read from, which is kind of great. So I succeeded in doing something useful. So even detecting that it's failed is quite hard. IE11, though, excels all of these things. It doesn't have any way to really access the system clipboard except for text. But what you can do is you can create a hidden content editable which you can shove HTML into, pre-select it and then force the browser to copy what happened to be selected onto the clipboard if you're lucky. There's a wonderful blog about this with all of this state machine and time-at-handlers, and it's exciting. But amazingly, if you debug this for a week it works. So anyway, you can copy and paste HTML into IE11, which is awesome. For secure types, I talked about the unpack bitmap. You've got a choice of text-blane, text-HTML, and text-RTF. That's it. You'll notice the recurring text theme. So then you get to mobile. A mobile is particularly exciting because again this security thing is all very nice. Press control C or control V to do a paste. That's great. You have a security context. The user really wanted to do that. There wasn't some bad-hacked actor catching a tab. But the problem is on a mobile phone you don't really have a paste button. So what do you do? IOS has a special paste button. Gboard does have some kind of paste built in but it throws away any HTML. It just stores text. And as it throws the HTML away it also inlines lots of tags that were in the header that aren't anything to do with stuff and paste them into your document. So Gboard is a nightmare for various reasons. And we can't detect whether we succeed, which is pretty bad. So there's an exact command thing we have to do to say do the paste. But it's unreliable. So you get callbacks and you then have to have increment sort of counters of was I called, was I not called and try and guess whether you succeeded. And yes, IOS as I explained earlier is particularly exciting about debugging. So all of that would be bad enough but it's worse. The clipboard APIs are all synchronous. What does that mean? That means that you have to have the data in your hand when you want to put it on the clipboard. It has to be in the browser on the device during the secure context while the user clicks something or taps control V. It's no use putting it on the clipboard later. It's not going to work. So all the controls see cut and copy. The problem is that we don't really want to put all of the text you select in every format in the client as soon as you select it. That's really stupid. That's like loads of data. And actually it's even worse than that. If you select in a spreadsheet, you know, like a whole spreadsheet, that's like a million rows with 16,000 columns. It's more than two to the 32 cells. You really don't want to serialize that and then send it to the client just in case someone presses control C. That would really suck. And actually this is fundamentally unsolvable. There's just no API for the web there to do this at all. You have to get another interaction from the user to get that context to be able to do it. So what do we do? So it's all pretty exciting. What we do is, well, when you have a simple selection, like a small chunk of words or a little thing, we push these to the browser's HTML. As you select it, we go, they'll probably want to do something with it. Push it to the browser. And if you want to paste it to another online instance window, what we do is we shove into that browser a magic cookie. I think you'll get a bit of that later. So you can detect it's the same thing. So if you're pasting in the same document, it should all just be fine. It detects that it's the same thing. It shortcuts it. Nothing leaves the server. All is good. Yeah. Unfortunately for the complex cases, first of all we show this dialogue blah blah blah blah blah blah blah. You have to click start download when you want it because we don't necessarily want to download it. And then you have to click again to get it onto the clipboard. So it's a pretty sad experience, but it's the best we can do. So what can you do? Well, it's not quite the best we can do. We can do a little bit better in various cases. So we insert this cookie here, which basically says multiple levels of escaping are a bad thing. That's basically, so I think this is a whoppy source, which is already escaped and we re-escape it and then we put it in this thing here. And so if it's got our meta in it, then it came from us. And now we can do something cool. And otherwise, you know, and we could potentially download the data ourselves and push it without using the web browser, which is kind of cool. You'll remember that we can paste text HTML and that can contain the metadata. How am I doing for time? Eight minutes? Yeah. I use 12. I use 12. Eight minutes, perfect. It is a 20-minute slot, right? Oh, it's 30 minutes. 25. Ah, I can relax. I shall speak more slowly. Right. So yes. So when we notice it's our data that's being pasted, we can download it from wherever it came from. So if you're pasting between documents or even actually between tabs on the same document, we will download this hidden in the background to a show progress bar. We'll re-upload it and then populate the clipboard and do a paste on that new view, which is all cool. Yeah, and it's just a bit of a faff game because it's all asynchronous, the download and upload APIs, which the browser likes because it doesn't block the user, obviously. Yeah. So it's download of data. Yeah. So the other problem is that things like embedded images, you often get just one stream. There's all sorts of capabilities and multiple streams in the clipboard's API so you can shove lots of images and things in there. But my impression is that none of these work at all. So you basically get one type. You get either an image or you get an HTML or something else. So we did a chunk of work to base 64 encode lots of images. So the HTML has the images in it. The problem is that all of this stuff here, the magic downloading and re-uploading behind the scenes has to be done in a sensitive way. It works with high-availability scaling and will work nicely across nodes. You'd think it would be nice to short-circuit in the data centre between one machine and another machine, but this is almost certainly a disaster area in terms of look-ups and access to each other and so on because they're all living in some paranoid demilitarised something. So actually it turns out to be better to download the whole clipboard to your client and then push it all back again, arguably to the same server than it is to do anything else, particularly when it's across tabs. So we have a new clipboard endpoint and that's pretty good. Of course there's lots of random gotchas, copy and paste in dialogues. What do you do when there's no... The kit clipboard is empty initially. So how do you paste something? Because the server doesn't think it's got anything on a clipboard to paste. So you just shove something in to start with. And what happens when you close the document? I mean, this is the perennial problem on the desktop that you have clipboard managers for that when you select something and you exit the document, I shall step back. So a properly designed clipboard API essentially is a negotiation. So when you select a huge number of cells in your spreadsheet, and I don't know if you've seen cut and paste in a spreadsheet but when you cut and paste in a spreadsheet it corrects all your formulae. It behaves very differently. So anything that refers to this as you move it into a spreadsheet, which is exactly what you want. But it's a side, but as you do this you essentially negotiate where the stuff is coming from. So you say, oh, I've got a selection. Oh, that's interesting. What can it be? And they provide a long list of things it can be. Oh, we could serve this spreadsheet as a PNG. We can have it as a JPEC. You can have it as a Starview metafile, just like a vector thing. Oh, we can have it as an EMF metafile, which is Microsoft's API. We can have it as an RTF chunk. ODF fragment, we can have it. You know, there's just dozens of different interchange formats. Great long list of them. And the hope is then that the client goes, oh, I don't like HTML much, but I quite like RTF. Let's see what he's got from an RTF perspective. And they grab that, just that. And this is how any sensible API should be designed. Of course, it's not really like that. But this is basically how you get around not converting the spreadsheet to 10 formats when you do a simple copy and paste of a large area. Anyway, anyhow, when you lose the clipboard, often you lose this thing as well, because clipboard managers don't really want to grab in every format, usually, unless they're quite expensive ones. But when you close the document, the application is not there to negotiate with anymore. It can't tell you what formats there were on the clipboard. It can't really do much. You really have to serialize that and stash it somewhere else. So then there's a new wonderful way that when an application is closing and it has a live clipboard, we then serialize that clipboard. And this makes the kit shut down, which used to be quite simple and pleasant of the form P kill minus 9 bang. That kind of thing. It's actually a very clean way to kill a process on Linux. It frees all its memory, the OS deals with the stuff. It is now some horrible handshake. Have I got the clipboard? Is it saved? What's going on? But anyway, we did that. So afterwards, the punchline is that you get a rather better result. You're having a text import dialogue. You get all of the content you want, all your conditional formatting. You even get the numbers, not being zero. So we're already doing quite well versus both Office 365 and Google Docs. So that's quite a nice improvement. And of course, you can copy and paste the charts across as well. So if you do that explicitly, you can actually get your data from one tab to another on the web. You would think this is kind of easy, but we thought it was kind of easy. You can do a few weeks of work and so on. And then you discover these lurking horrors. And then there are other horrors that you just can't do anything about. So if you're on a Mac, as some people are, who have more money than cents, who had more money than cents, then as you paste from Safari, so you go to Wikipedia and you select some images and some text, you get RTF. And RTF is something we really know about. We've got a brilliant RTF filter. We can do awesome stuff. Lovely. You can see the images in the RTF. So you just kind of lose them if you use RTF. And it's a bit difficult to know that there should have been images there and that they aren't there now. And so now you should really use something else, right? It's kind of dysfunctionally unfortunate. So we turn off our nice powerful RTF filter for Mac just to make our Mac users happy so that we can get HTML instead, which tends to have links in it to images. But unfortunately, fixing Safari is not as easy as you might hope. Particularly getting deployed is practically impossible. And of course, wouldn't it be nice if we could accept RTF from Word on Mac, which will do a really good job with RTF and then be able to do all sorts of rich content stuff? Well, of course, by design, you can't tell who's sending you the data because that would suck if applications accept data from some and not from others and that sort of thing. That lists one or the other terribly easily. So what about that? Then the security. So we now have a web endpoint that will serve you up what was on the clipboard. And of course, we give a huge hash for this. Obviously it would be terrible if someone saw your clipboard. But even that might not be secure enough for the wonderful penetration testing people that exist out there. So we expire this then. So we accept this key and the previous key and every two or four minutes configurable. You can rotate this and just throw stuff away so that people can't get it. Or if you're particularly paranoid, you can disable copy and paste completely by just using the WAPI property for that. One of the slight downsides of this is that LibreOffice was very good at generating text. It had nice bullet characters in it. It had good layout. It was beautiful. But now we really need HTML because the HTML has this magic cookie in it. You can't really transmit that as text, plain text without people getting a massive URL with triple encoding in it in their text, which annoys them. So, unfortunately, and you might find this hard to believe, I found it almost impossible to believe. But if you have a web browser that is excellent at laying out text and it does nothing but make text look pretty, okay it does some other stuff too, but it's a core part of its function, from JavaScript you can't actually convert HTML into text in any meaningful way. There is no API that will do this for you. Anything you do produces something horribly ugly, sort of, I suppose, stashing it in yet another... No, this is a really hard problem. And you can go to Stack Overflow and find all sorts of people's regular expression monsters to try and parse HTML and remove all the bits they don't want. But this is unbelievable. Anyway, so maybe I'm an idiot, but you can... So anyway, currently we try and strip the HTML tags out manually, and it's not as beautiful as it could be and the result is not wonderful. So there's a bit of a regression of text playing copy and paste, which is a shame. So someone can tell me how it's supposed to be done maybe later. So there you go. So we have just the most awesome capability of transmitting and transferring data in all sorts of different formats. And it's really cool. We do a really good job of it in the core. And we can, you know, just years and years of pasting evil junk from A to B in applications. But the real problem is just the web has just appalling APIs here. Oh, I guess since I wrote these things we also have a problem on Android, which is that the Android, everyone has been inspired to write terrible content negotiation APIs for copy and paste. I don't know how we can have bit-rotted so far. I mean, Windows does it better than this, you know? I mean, really? But anyway, Android is... I guess it probably comes from trying to do a little bit better than plain text. So yeah, so in Android again we just use this web cookie thing for HTML and we have like a local file. And if we detect it from ourself we use the local file to talk to ourself because that's actually just way better than trying to jam it through the HTML transport. So anyway, connecting is an epic. The web API sucks. At least the Android API sucks. Online can now do good things. It leads in its class. That's my hope. It's still not perfect. Go and try it. You'll discover that actually some things are particularly nasty, like when you're copying and pasting between presentations, what should you do? You have a shape and it uses five styles or lots of styles in this thing to style it. And then you paste it into another document that has styles of the same name that have different properties. So what do you do? Yeah, but the problem is you then have to detect that they're different, right? And how different is different? And probably what possibly some people want to do is adopt the new styling and theming of the new document, like styles should be separate from documents. So you should be able to copy this and put it there and it looks new and exciting, not old and boring. But the net result is that if you use draw and you use shapes a lot you can fall over this problem and think it's broken. That's actually a feature. Or something. I don't know. Anyway. And these guys did lots of the work, including me and we can't do anything without people paying for it. So we're very grateful to our customers and our partners for helping. So that's that. Any questions? And did I ever run yet, Nicholas? No, not yet. Oh well there you go, six minutes. That's my highly opinionated rant on web copy paste APIs, which generally suck. Anyone at all, Olivia you're looking deeply pensive. I think you've got a... OK. Well thank you very much then. You've been very patient.