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

NEW
Unassigned

Status

()

Core
Selection
16 years ago
5 years ago

People

(Reporter: bz, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(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
Status: NEW → ASSIGNED
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
(Reporter)

Updated

16 years ago
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.
Keywords: mozilla1.0, nsCatFood
Blocks: 124140

Comment 5

16 years ago
dup of bug 51929?
No... this is actually assigned to the guy who said he'd do the work.  :)
Blocks: 144260
(Reporter)

Updated

15 years ago
Blocks: 132979
fffffffuture
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

Comment 9

15 years ago
QA->pmac
QA Contact: tpreston → pmac

Comment 10

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

Updated

15 years ago
Keywords: mozilla1.0 → mozilla1.3

Updated

14 years ago
Flags: blocking1.6a?
Keywords: mozilla1.3
Claiming, as I'm working on this.
Assignee: pinkerton → caillon
Status: ASSIGNED → NEW
Keywords: helpwanted
Priority: -- → P1
Target Milestone: Future → mozilla1.8alpha
Created attachment 144732 [details] [diff] [review]
patch for gtk2 (WIP)

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)
Created attachment 144873 [details] [diff] [review]
Patch for GTK2

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

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
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. ***

Comment 20

12 years ago
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.

Updated

11 years ago
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.