This is spun off of bug 55312. Given a laggy network and a fast computer we currently fail to paste correctly into Mozilla if the paste is coming from an app running on a remote computer. The only real solution to this is to make the clipboard async; assigning to pinkerton, since he's mentioned implementing that. Bug 55312 checked in a workaround that should be OK for a bit, but as computers get faster this will become a problem again.

this is a dupe of a bug i already have, but i can't find it.

*** Bug 89102 has been marked as a duplicate of this bug. ***

*** Bug 84217 has been marked as a duplicate of this bug. ***

This is a major usability problem on Unix, still. While pasting from remote apps is passable now, we still cannot paste large amounts of text. We just forget to do it. See comments in bug 56219.

dup of bug 51929?

No... this is actually assigned to the guy who said he'd do the work. :)

fffffffuture

at least adding helpwanted... this is one of the few really major usability problems of Mozilla on Linux (the fact that I can't paste a chunk of text into a textarea reasonably).

QA->pmac

*** Bug 51929 has been marked as a duplicate of this bug. ***

Claiming, as I'm working on this.

So this should get the ball rolling. I want to patch gtk1 eventually, and do some more fixup here but I suppose some comments would be nice on this. Of note, I changed nsIClipboard::supportsSelectionClipboard() because it wasn't generic enough. There could be more clipboards than just two (will someone ever use secondary? will we ever support app specific clipboards ala some office suites?) and having a mask returned is more robust. I also changed the constants to be more IDL-ish. I also removed nsIClipboardOwner since it was unused by anything I could find, and bryner and blizzard seemed to be ok with that. I dealt with other platforms by just having the async method call the sync method and then immediately fire the callback. That seemed to be the sensible thing to do...

Ok, let's try this. It fixes some issues the previous one had with calendar, xlib, and updates the places I just forgot to change (oops). Also, this avoids some potential crashes in the editor callbacks.

Comment on attachment 144873 [details] [diff] [review] Patch for GTK2 widget/public/nsIClipboard.idl + * @param aTransferable The transferable + * @param aWhichClipboard Specifies the clipboard to which this operation applies. + * @param aClipboardListener Specifies the clipboard to which this operation applies. + * @result NS_OK if no errors + */ + void getData(in nsITransferable transferable, in unsigned long clipboardID, + in nsIClipboardListener listener, in nsISupports data); param names don't match here and on the other functions on this interface... also, you should probably generate a new iid with uuidgen or something instead of just incrementing it

*** Bug 268053 has been marked as a duplicate of this bug. ***

*** Bug 270533 has been marked as a duplicate of this bug. ***

*** Bug 239083 has been marked as a duplicate of this bug. ***

*** Bug 243758 has been marked as a duplicate of this bug. ***

*** Bug 190723 has been marked as a duplicate of this bug. ***

I'm also experiencing the same bug on all my Windows XP computers when having the Remote Desktop client open. I also use VNC some times and I don't think that this bug arises on VNC. I've noticed that it actually fails copying what's in the address bar. It can copy text and everything else perfectly. Note that my operating systems are Windows XP profesionnal and Home Edition.

Is this bug really linux-only? Or just the patch? (dupes of comment 17 to 19 were all windows reports)

This bug as originally filed is Linux-only. Whoever marked Windows bugs as duplicates is mistaken. If there is a Windows issue, it should be filed as a separate bug.

Comment on attachment 144873 [details] [diff] [review] Patch for GTK2 patch doesn't apply any longer and blizzard probably no longer is the right reviewer. minusing