Add a preference so "autocopy" on mouseup happens only on desired platform or if user wants it

RESOLVED FIXED in M17

Status

()

Core
Selection
P3
normal
RESOLVED FIXED
18 years ago
8 years ago

People

(Reporter: Charles Manske, Assigned: Charles Manske)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

18 years ago
The "autocopy" feature is expected only on UNIX systems. But a pref will
allow UNIX users to turn it off and Windows/Mac users to turn it on if they
want it.

Comment 1

18 years ago
This pref already exists.  You seem to be saying that the pref is enabled on 
Windows.  I don't think it is.  Kin tried to middle-mouse yesterday on Windows 
and it didn't work (because he hadn't set the pref).

Resolving this as fixed since the pref requested already exists.
For the record, the pref is "middlemouse.paste"
Here is the url where the pref is defined for all platforms:
  http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/all.js#497
The url is redefined to true in unix.js.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
we are placing the data on the transferable on all platforms even though it's not 
going through to the clipboard, which could be slow for large selections.

should we wrap the pref at a higher level?

Comment 3

18 years ago
Kathy: why should autocopy be tied to middlemouse paste?  They seem like very
different functions even though they're often used together.  middlemouse.paste
wasn't intended to be the pref for autocopy, otherwise it would have been called
something more general like unixStyleClipboard.

I'm reopening because I don't think this makes sense.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 4

18 years ago
I was just about to reopen this anyway because:
The pref may exist, but that's not why Kin didn't get "autocopy" on Windows.
The real reason is because the relevant code is only compiled on UNIX! (I.e.,
the pref isn't being used.) That was added by me recently until I figured out
how to do the pref stuff.
If the pref exists, great, so I will do the right thing in the nsSelection
to use the pref.
I will resolve with Akkana if we need another pref besides "middlemouse.paste"
Assignee: mjudge → cmanske
Status: REOPENED → NEW
Target Milestone: --- → M17
(Assignee)

Comment 5

18 years ago
I will add a pref: "clipboard.autocopy" that will be true by default for UNIX 
and false for other platforms.
Status: NEW → ASSIGNED
(Assignee)

Comment 6

18 years ago
Created attachment 9723 [details] [diff] [review]
Diff for new preference and selection code to use it

Comment 7

18 years ago
I don't understand how the diff attached on 6/6/2000 13:43 fixes the problem 
pinkerton describes (placing the data into a transferable on all platforms).

Comment 8

18 years ago
this bug is really part of 41045, it got separated out for tracking purposes, 
this fix needs to be checked in to totally satisfy 41045
(Assignee)

Comment 9

18 years ago
New pref and test for value in nsSelection.cpp checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

18 years ago
To answer brade's question: the issue has nothing to do with placing data
into a transferable -- whether that works or not is a separate issue. This 
bug addresses whether or not we install the nsIAutoCopyService listener 
in the nsSelection constructor, thus do we even attempt to do the "autocopy"
when a selection is made. We shouldn't do it by default on platforms (Windows,
Mac) that don't normally support this feature. But having an appropriate pref
allows UNIX users to turn the feature on, or Mac/Windows users to try it out.
Of course we don't currently expose the pref in the UI!

Comment 11

18 years ago
2 issues:  

Akkana--to get middle-mouse paste to work, do you also need to set this new 
autocopy pref or are these truly independent?

Charley--seems like a proper fix for this bug would also include the performance 
issue Mike Pinkerton suggests.  Should we file a separate bug for that issue?
(Assignee)

Comment 12

18 years ago
The prefs are completely independent, although the defaults are the same for
both: true for UNIX, false for everyone else.
Yes, there should be a separate bug(s) for any autocopy implementation or
performance issues.

Comment 13

18 years ago
I don't think it's the autocopy implementation that needs fixing but the 
preference that wraps the implementation (if I understand pinkerton's suggestion 
correclty).  I'm not sure I agree that a separate bug should be written that is 
basically to move this pref to a higher-level so that the pref actually disables 
everything related to autocopy.  Seems like this was a poor implementation if we 
didn't take into account pinkerton's suggestion for appropriately wrapping the 
preference.

I will file a new bug and cc those on this bug.

Comment 14

17 years ago
*SPAM*: Changing the QA contact of all open/resolved Selection bugs from 
elig@netscape.com to BlakeR1234@aol.com.  After the many great years of service 
Eli has given to Mozilla, it's time for him to move on; he has accepted a 
position at Eazel.  We'll be sad to see him go, and I'll do my best to fill his 
spot...
QA Contact: elig → BlakeR1234
I work on Linux (Ubuntu 8.04 Hardy Heron) using Firefox 3 RC2 (from hardy-proposed repo), I have clipboard.autocopy turned on and it does NOT work. So it doesn't seem that You're right saying that it works on *nix...
Hmm... I did reset some other switch (type: string) having "autocopy" in name (but I don't really remember the name) and it started to work...

However, it would be useful to be able to disable auto-copying from URL-bar and enable auto-copying usual text (as it's made in AutoCopy extension - but this one doesn't work with RC2).
You need to log in before you can comment on or make changes to this bug.