make clipboard async -- otherwise paste from remote apps can fail.




18 years ago
7 years ago


(Reporter: bzbarsky, Unassigned)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)

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.
Whiteboard: dupeme
Target Milestone: --- → mozilla1.0
*** Bug 89102 has been marked as a duplicate of this bug. ***
*** Bug 84217 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.0 → mozilla1.1
Blocks: 56219
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.
Blocks: 124140
dup of bug 51929?
No... this is actually assigned to the guy who said he'd do the work.  :)
Blocks: 144260
Blocks: 132979
Target Milestone: mozilla1.1alpha → Future
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).
Keywords: helpwanted
QA Contact: tpreston → pmac
*** Bug 51929 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0mozilla1.3
Flags: blocking1.6a?
Keywords: mozilla1.3
Claiming, as I'm working on this.
Assignee: pinkerton → caillon
Keywords: helpwanted
Priority: -- → P1
Target Milestone: Future → mozilla1.8alpha
Posted patch patch for gtk2 (WIP) (obsolete) — Splinter Review
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...
Attachment #144732 - Attachment description: patch for gtk2 → patch for gtk2 (WIP)
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.
Attachment #144732 - Attachment is obsolete: true
Comment on attachment 144873 [details] [diff] [review]
Patch for GTK2

+   * @param  aTransferable The transferable
+   * @param  aWhichClipboard Specifies the clipboard to which this operation
+   * @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
Attachment #144873 - Flags: review?(blizzard)
*** 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.
Assignee: caillon → selection
Priority: P1 → --
QA Contact: pmac
Whiteboard: dupeme
Target Milestone: mozilla1.8alpha1 → ---
Is this bug really linux-only?  
Or just the patch?
(dupes of comment 17 to 19 were all windows reports)
Assignee: selection → nobody
QA Contact: selection
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
Attachment #144873 - Flags: review?(blizzard) → review-
You need to log in before you can comment on or make changes to this bug.