techno.blog("Dion")

copy: function(copytext) {
    try {
        if (netscape.security.PrivilegeManager.enablePrivilege) {
            netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
        } else {
            clipdata = copytext;
            return;
        }
    } catch (ex) {
        clipdata = copytext;
        return;
    }
 
    var str = Components.classes["@mozilla.org/supports-string;1"].
                              createInstance(Components.interfaces.nsISupportsString);
    str.data = copytext;
 
    var trans = Components.classes["@mozilla.org/widget/transferable;1"].
                           createInstance(Components.interfaces.nsITransferable);
    if (!trans) return false;
 
    trans.addDataFlavor("text/unicode");
    trans.setTransferData("text/unicode", str, copytext.length * 2);
 
    var clipid = Components.interfaces.nsIClipboard;
    var clip   = Components.classes["@mozilla.org/widget/clipboard;1"].getService(clipid);
    if (!clip) return false;
 
    clip.setData(trans, null, clipid.kGlobalClipboard);
},
 
data: function() {
    try {
        if (netscape.security.PrivilegeManager.enablePrivilege) {
            netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
        } else {
            return clipdata;
        }
    } catch (ex) {
        return clipdata;
    }
 
    var clip = Components.classes["@mozilla.org/widget/clipboard;1"].getService(Components.interfaces.nsIClipboard);
    if (!clip) return false;
 
    var trans = Components.classes["@mozilla.org/widget/transferable;1"].createInstance(Components.interfaces.nsITransferable);
    if (!trans) return false;
    trans.addDataFlavor("text/unicode");
 
    clip.getData(trans, clip.kGlobalClipboard);
 
    var str       = new Object();
    var strLength = new Object();
    var pastetext = "";
 
    trans.getTransferData("text/unicode", str, strLength);
    if (str) str = str.value.QueryInterface(Components.interfaces.nsISupportsString);
    if (str) pastetext = str.data.substring(0, strLength.value / 2);
    return pastetext;
}

try {
    if (netscape.security.PrivilegeManager.enablePrivilege) {
        netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
    } else {
        clipdata = copytext;
        return;
    }
} catch (ex) {
    clipdata = copytext;
    return;
}

Event.observe(document, "beforecopy", function(e) {
    e.preventDefault();
    $('copynpaster').focus();
});

Event.observe(document, "copy", function(e) {
    var selectionText = _editor.getSelectionAsText();
 
    if (selectionText && selectionText != '') {
        e.preventDefault();
        e.clipboardData.setData('text/plain', selectionText);
    }
 
    $('canvas').focus();
});

_editor.ui.actions.deleteSelection(selectionObject);

e.clipboardData.getData('text/plain');

setup: function() {
    if (Prototype.Browser.WebKit) {
        this.install(new Bespin.Clipboard.DOMEvents());
    } else {
        this.install(new Bespin.Clipboard.Default());
    }
}

26 Responses to “Supporting the system clipboard in your Web applications; What a pain!”

1. Bill Mill Says:
   February 26th, 2009 at 9:49 am

   So, in summary, can you or can’t you make it work with firefox in any sort of reasonable way? I’m confused.

2. Boris Says:
   February 26th, 2009 at 10:10 am

   Fundamentally, the problem you’re running into is that being able to place text controlled by a web page into the system clipboard without the user selecting it and copying it is considered a security bug in Firefox.

   So you need to make sure that whatever setup you use doesn’t involve doing that, or anything that appears to be that to Firefox.

   This is a hard problem.

3. Boris Says:
   February 26th, 2009 at 10:11 am

   To be precise the hard problem is how to design an API that would work for you, and couldn’t be abused by a malicious web page. I’d love to see any proposals you have in m.d.platform.

4. Jeff Schiller Says:
   February 26th, 2009 at 10:15 am

   Missing the link for W3C DOM Level 3 Events spec…

5. Jeff Schiller Says:
   February 26th, 2009 at 10:24 am

   … and actually I couldn’t find ‘beforepaste’ described in any W3C specification

6. Emmanuel Pirsch Says:
   February 26th, 2009 at 10:49 am

   Did you explore a signed Java applet (jnlp style)?

   This may not be a popular choice, but by signing the applet and specifying which permissions you seek. The user will have the choice to grant permissions permanently or not.

   This will also give you access to binary (images for example) copy and paste.

   Note that you really should use the applet tag with a JNLP file as this will give you a much better applet environment (Java plugin) than the browser applet environment.

   From there, you can easily communicate from/to javscript to/from the applet. And this will work with any A grade browser.

7. Jeff Schiller Says:
   February 26th, 2009 at 10:49 am

   By the way, I applaud this noble experiment, but…

   I guess I haven’t heard a solid reason why canvas was used over more conventional HTML 4.01. Even over here where you justify it by saying: We need control. Control over what exactly? Font? Text Color? Background Color? Hover Tooltip? What else?

   It seems like Google Docs does just fine with giving me an editable text document that is cross-browser, text which can be richly styled, text which the browser and system know is selectable, copyable, linkable, can be checked in a spell-checker, can be ubiq’ed, etc. And it’s a document that can be edited by multiple people simultaneously. It seems they do it using nothing but HTML 4.01 elements.

   It seems like a lot to give up – and I’m not sure all the things you’re trying to gain.

   You mention performance… I didn’t do the experiments but I have a hard time believing that a page-sized div of HTML elements (spans, etc) that is dynamically changing as you scroll wouldn’t be as performant as programmatically formatting, styling and drawing the text on a canvas.

8. Ben Galbraith Says:
   February 26th, 2009 at 11:07 am

   @Jeff Schiller: Do the experiments, read the blogs and comments from folks who have tried to do it (Daniel Glazman comes to mind immediately, others may be out there), and I think you’ll come around.

   You might also note that this isn’t a novel approach; Eclipse, IntelliJ IDEA, NetBeans, Visual Studio, and many others have all hand-rolled their code editors from scratch.

9. smaug Says:
   February 26th, 2009 at 11:12 am

   Drag events and clipboard handling aren’t specified in W3C DOM Events spec.
   HTML 5 draft does include them.

10. smaug Says:
    February 26th, 2009 at 11:14 am

    Oops, didn’t mean drag events but copy+paste, those are (also) in HTML 5

11. smaug Says:
    February 26th, 2009 at 11:19 am

    And I misremember that :(. copy+paste events are from Microsoft.

12. Robby Colvin Says:
    February 26th, 2009 at 11:20 am

    A little off topic, but do you know where I can buy those onesies?

13. Wladimir Palant Says:
    February 26th, 2009 at 1:44 pm

    Yes, getting clipboard access from a web application is a security hole – and the fact that you can still do it with Flash is troubling. If I were you I wouldn’t count too much on that hack, Flash 11 will likely break it again.

    However, why can’t you use existing mechanisms? Since you draw everything in the canvas yourself, I don’t think you care too much about input focus. Why not have an invisible text field that takes focus instead of the canvas? Whenever the user selects something in the canvas you copy the selected text into the text field and select it there. This way when the user presses Ctrl+C it will work automatically. Cut and paste operations in the text field can be detected and you can easily get the pasted data out. I realize that this isn’t quite as simple as I made it sound but at least that would be a stable approach.

    Copy and paste buttons on the toolbar are a different thing of course, for that you will have to work around existing security mechanisms – meaning that it might be better to consider some different UI approach.

14. Dao Says:
    February 26th, 2009 at 3:59 pm

    What Wladimir said. Given that you want the hidden textarea anyway for accessibility, that seems like the way to go.

15. Arthur Blake Says:
    February 26th, 2009 at 4:50 pm

    Where can I get those copy & paste onesies?

16. Tom Robinson Says:
    February 26th, 2009 at 5:19 pm

    In Cappuccino we bypass the oncopy family of events completely, and simply capture the key combinations, then focus / select the hidden input field and fill it with data appropriately.

    This works in every browser, but there are a few downsides, namely copy/paste can only be triggered by the key commands, not the “Edit” menu items.

    Perhaps a combination of of the two techniques would work better, using the oncopy/paste events if they’re supported, falling back to key events.

17. voracity Says:
    February 26th, 2009 at 7:18 pm

    I find myself constantly oscillating between thinking that this is a great and innovative project to being worried that the choice to snub *hackable* web technologies (with what appears to everyone like Mozilla’s blessing) will do more harm to the web than Microsoft’s neglect of IE6.

    When I inspect BeSpin with Firebug, I see a div element with id=editor that contains a canvas element with id=canvas — and that’s it. I can’t use Firebug to manipulate the editor (like resize, move or delete elements). I can’t put CSS declarations in my user agent style sheet that will have any effect on the BeSpin text editing — and furthermore, I can’t use any extension that manipulates fonts, colors, etc. on my behalf. Even Firefox’s Zoom Page function has no effect on BeSpin. When I run a “Find on Page”, I can’t find any of what I’ve typed. Even the copy & paste problem you describe in this post arises partly because you’ve spun your own UI. What about testrunners? I use Selenium IDE to automate my website testing. Completely useless with BeSpin. The ScrapBook extension, which lets you save webpage clippings? Useless again with BeSpin. Spellcheckers? Useless. Context-sensitive searches? Useless. The list of browser features and extensions that this breaks just goes on and on.

    And then there’s Ubiquity. Oh what irony that Ubiquity becomes completely useless on a fellow labs project given what the word ubiquity means!

    BeSpin is still hackable in one very important regard: because it uses the browser’s Javascript engine, I can use something like GreaseMonkey to alter it’s behaviour. But BeSpin is its own system — I have to learn the BeSpin system in order to do any hacking on it.

    What happens if everyone starts thinking this kind of thing is a good idea and developing their own BeSpin-like projects? We’ll have 10000 different websites with 10000 different systems that people have to learn in each new case to do something basic like change their font!

    To be fair, you’ve proposed adding a custom DOM within the canvas. This may address some of my concerns, but unless you are proposing to make that custom DOM a wider standard, it really doesn’t address anything. You may as well just dump out plain text, because the tags are meaningless by virtue of having no common interpretation. (Because that’s what meaning is!)

    I don’t wish to sound too critical. I realise this is an experiment and I think it’s a great exploration of what’s possible and is a very promising project in itself. But unless you address hackability, then I cannot support the project.

    (Aside: I find myself constantly trying to defend web hackability. Whether it be because of Flash, Silverlight or Java, or information hiding and non-mutability in ES4, or security practices that haven’t been subjected to a proper cost/benefit analysis. Where is the FSF when I need them? :) )

18. voracity Says:
    February 26th, 2009 at 7:40 pm

    Apologies, Firefox’s zoom does work, it just looks horrible.

19. Dave Johnson Says:
    February 26th, 2009 at 9:07 pm

    We have done something similar Dion where we capture the ctrl + c keydown event on whatever DOM element you want then put whatever text you want to copy into a hidden textarea and focus the textarea with the text selected. The keyup event will cause a native copy to happen and the selected text will then be on the system clipboard. Paste works in a similar way.

20. Chris Thornton Says:
    February 27th, 2009 at 3:43 am

    For those interested, here is my article summarizing the Flash clipboard vulnerability. http://www.clipboardextender.com/defective-apps/clipboard-virus-not-exactly-but-still-dangerous

21. Barney Carroll Says:
    February 27th, 2009 at 5:14 am

    Obviously your app has its own special wares to bring to the table (or you wouldn’t be interested in developing this), but the way I see it there’s two ways to go about this:

    1) Access to the global OS clipboard proper – I’d be very worried for the future of the web if you succeeded in doing this while sticking to non-proprietary W3 tech.

    2) Create your own clipboard + cut & paste methods that stick to your app – context menus & events bound to Ctrl+C/X/V operating with mouse coords and focus respectively on a textarea.

    Regards,
    Barney

22. Jesse Ruderman Says:
    February 28th, 2009 at 12:30 am

    “contentEdible” is a delicious typo.

23. Sam Foster Says:
    March 5th, 2009 at 1:53 am

    @Voracity – good points. I agree that a part of the “open” in the Open Web is being lost here. Being able to poke, prod and tweak a thing in the browser, at runtime is very much a part of what gives the Open Web its value. No black boxes.

    But that’s a digression from the subject of this post. The applet seems to be the way to go, if you cant do it all with a hidden field. The applet and js api you wrap around it just need to bridge the gap – put a facade up that smooths away the funkiness you describe here, until such time as sanity is brought to the subject. That would give you your IE compatability too (when you need it).

    I know everyone has this knee-jerk reaction when it comes to java applets, but seriously, why not?

24. Pies Says:
    March 5th, 2009 at 2:45 am

    Just loose the UI icons and use the hidden input/textarea solution. I don’t see a point in programmer’s editor having icons for commonly used functionalities like Copy/Paste.

25. John Dowdell Says:
    March 5th, 2009 at 4:08 pm

    From what I understand, if the browsers tracked user-initiated JavaScript events, and could pass the info to plugins, the old way would still work.

    (Or you could just put the button in Flash, which can track user-initiated events.)

    That “zeroclipboard” hack… that’s a clickjacking exploit, isn’t it? Browsers really need to guarantee that What You See Is What You Click. Hacking atop the fault doesn’t seem sustainable.

    jd/adobe

26. brett Says:
    August 21st, 2009 at 9:07 am

    any idea if mobile safari supports clipboard access? it’s not obvious form the docs if they do…

Leave a Reply