Last Comment Bug 542938 - Firefox should give a setting that disables oncopy, oncut & onpaste event handling
: Firefox should give a setting that disables oncopy, oncut & onpaste event han...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: unspecified
: All All
: -- enhancement with 13 votes (vote)
: mozilla13
Assigned To: Robert Accettura [:raccettura]
:
: Andrew Overholt [:overholt]
Mentors:
http://palegreaovivo.blogspot.com/201...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-28 19:34 PST by Anderson
Modified: 2014-08-18 20:52 PDT (History)
20 users (show)
gavin.sharp: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch v1 (2.00 KB, patch)
2012-02-07 14:26 PST, Robert Accettura [:raccettura]
no flags Details | Diff | Splinter Review
Patch v2 (1.79 KB, patch)
2012-02-07 18:12 PST, Robert Accettura [:raccettura]
bugs: review+
Details | Diff | Splinter Review
Patch v3 (addressing review comments) (3.02 KB, patch)
2012-02-08 16:53 PST, Robert Accettura [:raccettura]
robert: review+
emorley: review+
Details | Diff | Splinter Review
Patch v4 (1.80 KB, patch)
2012-02-13 18:17 PST, Robert Accettura [:raccettura]
no flags Details | Diff | Splinter Review

Description Anderson 2010-01-28 19:34:42 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.9.2) Gecko/20100125 Ubuntu/10.04 (lucid) Firefox/3.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.9.2) Gecko/20100125 Ubuntu/10.04 (lucid) Firefox/3.6

Since Firefox 3.0, scripts can handle oncut, oncopy and onpaste events and manage a clipboard (bug #280959). But this "feature" is now used to tell site owners what contents I'm copying from their sites. I think this is a privacy issue; I'm really bothered with it.

I suggest Firefox to have an option (Edit => Preferences => Content => Enable JavaScript => Advanced) that allows the user to disable the "oncopy", "oncut" & "onpaste" event handling. That option could be called "Allow scripts to... Manage cut, copy & paste events".

If my suggestion can't be accepted, I also will be happy if you implement such setting in "about:config" only.

Reproducible: Always

Steps to Reproduce:
1. Install Live HTTP headers extension
2. Access http://palegreaovivo.blogspot.com/2010/01/atualizacao-voo-da-banda-metallica.html
3. Open Live HTTP window and make sure it captures requests.
4. Select some words from the page
5. Press CTRL+C
6. In Live HTTP window, you will see POST requests to http://(...).tynt.com/traces/ just after step #5
7. Go back to step #4

Actual Results:  
Site owner can discover what I copied from his site.

Expected Results:  
It shouldn't happen anything...

Some URLs regarding the privacy issue:

https://adblockplus.org/forum/viewtopic.php?p=29796
http://yro.slashdot.org/story/10/01/14/1818222/Tynt-Insight-Is-Watching-You-Cut-and-Paste
http://support.mozilla.com/en-US/forum/1/519535
http://www.tynt.com/
Comment 1 Josh Triplett 2010-02-20 13:56:20 PST
Confirming and setting platform all/all.

This has another side effect: in addition to privacy issues, these events allow sites to prevent these events by returning false.  That represents a major functionality limitation.

I'd argue that this should have a higher importance than "enhancement", and get treated as a bug rather than a feature request, but I'll leave that for others to decide.
Comment 2 David Booth 2010-06-02 10:44:51 PDT
See comments by Tim Berners-Lee on this problem:
http://lists.w3.org/Archives/Public/www-tag/2010Jun/0008.html

I hope this can be fixed/improved.

A related problem is when sites hijack the right-click menu.  The browser should not let that happen.  That is NOT a function I want the page to be able to usurp.
Comment 3 Josh Triplett 2010-06-02 11:36:57 PDT
(In reply to comment #2)
> A related problem is when sites hijack the right-click menu.  The browser
> should not let that happen.  That is NOT a function I want the page to be able
> to usurp.

Firefox already has a setting for that: dom.event.contextmenu.enabled .  Exposed as a checkbox in preferences, too.  (That said, sites sometimes seem to find ways to break right-click other than the context menu event.)
Comment 4 Alliz Gub 2010-07-21 14:50:06 PDT
I agree with this bug.
Same privacy issue with tynt.com on http://wiki.linuxquestions.org.
Some websites ask to type in your email address two times without the possiblity to paste it (onpaste=false). 
Some websites try to prevent you to copy content by using onselect=false.
Comment 5 Alliz Gub 2010-07-22 04:31:10 PDT
A bookmarlet will do the trick, for the time being.

javascript:(function(){var H=["cut","copy","paste","contextmenu","mousedown"], Z=[], s="", j; function R(N,a){ while (N[a]) { Z[a]=Z[a]?Z[a]+1:1; N[a]=null; } } function zapEH(N) { var a,i,C; for (j in H) R(N,"on"+H[j]); C=N.childNodes; for (i=0;i<C.length;++i) zapEH(C[i]); } zapEH(document); for (j in Z) s += j + " (" + Z[j] + ")\n"; if(s) alert("Zapped event handlers:\n\n"+s); else alert("No event handlers found.");})();

This will remove any oncut, oncopy, onpaste, oncontextmenu, onmousedown events.
(Because with onmousedown='return false;' you can't select text.)
You have to click it for each page.

You can change the list of the forbidden events in var H, you can decide not to trigger an alert() at the end.
It comes from forums.mozillazine.org/viewtopic.php?f=7&t=1165 (back in 2002!)
Comment 6 Danny Moules 2010-11-22 02:33:56 PST
Am I okay to take this one? Behaviour that like this really ticks me off, we should definitely implement it via prefs for the privacy-conscious.
Comment 7 Robert Accettura [:raccettura] 2012-02-07 14:26:56 PST
Created attachment 595183 [details] [diff] [review]
Patch v1

Block the clipboard DOM events from firing when dom.event.onClipboardEvent.enabled is set to false.  It defaults to true.
Comment 8 Robert Accettura [:raccettura] 2012-02-07 14:29:58 PST
Also: likely the first C I've written since ~2005, and I totally don't know who reviews this stuff anymore ;)

/be gentle
Comment 9 Joe Drew (not getting mail) 2012-02-07 17:09:47 PST
Comment on attachment 595183 [details] [diff] [review]
Patch v1

Let's try one of the usual suspects.
Comment 10 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-02-07 17:22:30 PST
Can't comment on the pref-checking code, but you'll want to set the default pref in all.js rather than firefox.js, and you want to set the actual pref, not the sync.* variant of it (which just controls whether sync syncs the pref between profiles).
Comment 11 Bill Gianopoulos [:WG9s] 2012-02-07 17:30:32 PST
(In reply to Robert Accettura [:raccettura] from comment #7)
> Created attachment 595183 [details] [diff] [review]
> Patch v1
> 
> Block the clipboard DOM events from firing when
> dom.event.onClipboardEvent.enabled is set to false.  It defaults to true.

I don;t at all understand why this should be a sync preference.
Comment 12 Robert Accettura [:raccettura] 2012-02-07 18:12:38 PST
Created attachment 595281 [details] [diff] [review]
Patch v2

Moved pref to all.js
Comment 13 Robert Accettura [:raccettura] 2012-02-07 18:14:52 PST
(In reply to Gavin Sharp (use gavin@gavinsharp.com for email) from comment #10)
> Can't comment on the pref-checking code, but you'll want to set the default
> pref in all.js rather than firefox.js, and you want to set the actual pref,
> not the sync.* variant of it (which just controls whether sync syncs the
> pref between profiles).

You're right… it's been a while for me. :)

Patch updated.
Comment 14 Alfonso Martinez 2012-02-08 01:49:21 PST
IMHO, the valid use cases of these events are related mainly to online WYSIWYG editors based on contentEditable. 

They try to emulate MS Word and the like, so having a way to preprocess the data that it's being pasted can help the strip out unwanted features, eg: some people might not want to allow external images, or perform a basic paste without all the styles carried over, or strip just some tags or attributes.

The Copy and Cut in this case should be related to the fact that the editor might use "placeholders" or other kind of elements while editing that are converted to a different HTML when saving, so in this case the copy and cut events would allow them to replace their internal code that it's being copied with the HTML that would be generated otherwise (or BBCode, WikiCode, etc...)

The point is: if this preference gets added, then it will be enabled by many people due to the abuse of some sites, but then they will file bugs on those javascript editors because the clipboard operations aren't working correctly. And this can affect also other editors like Orion or ACE.

So please, keep this info in mind.
Comment 15 :aceman 2012-02-08 04:27:33 PST
Then it could be added into the set of per-site preferences so it can be enabled only for specific sites (like zoom, cookies, pop-up windows, passwords etc. are today). See about:permissions.
Comment 16 Olli Pettay [:smaug] 2012-02-08 08:37:24 PST
Comment on attachment 595281 [details] [diff] [review]
Patch v2


>   // next, fire the cut or copy event
>-  nsEventStatus status = nsEventStatus_eIgnore;
>-  nsEvent evt(true, aType);
>-  nsEventDispatcher::Dispatch(content, presShell->GetPresContext(), &evt, nsnull,
>-                              &status);
>-  // if the event was cancelled, don't do the clipboard operation
>-  if (status == nsEventStatus_eConsumeNoDefault)
>-    return false;
>-
>+  if(Preferences::GetBool("dom.event.onClipboardEvent.enabled", true)){
add space after 'if' and before '{'

> pref("dom.event.contextmenu.enabled",       true);
>+pref("dom.event.onClipboardEvent.enabled",  true);
Strange preference name.
Perhaps dom.event.clipboardevents.enabled
or dom.event.cut_copy_paste.enabled

In the future please use -U 8 -p when creating patches
Comment 17 Robert Accettura [:raccettura] 2012-02-08 16:53:02 PST
Created attachment 595583 [details] [diff] [review]
Patch v3 (addressing review comments)

Addressing review comments.  Moving over flag.

I don't have commit privileges for the hg repo (AFAIK), so I'll entrust this one to someone who does.
Comment 18 Ed Morley [:emorley] 2012-02-09 08:13:52 PST
Comment on attachment 595583 [details] [diff] [review]
Patch v3 (addressing review comments)

(To keep autoland to try happy about permissions)
Comment 19 Mozilla RelEng Bot 2012-02-09 08:21:29 PST
Autoland Patchset:
	Patches: 595583
	Branch: mozilla-central => try
	Destination: http://hg.mozilla.org/try/rev/65db5faf09e2
Try run started, revision 65db5faf09e2. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=65db5faf09e2
Comment 20 Mozilla RelEng Bot 2012-02-09 17:30:22 PST
Try run for 65db5faf09e2 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=65db5faf09e2
Results (out of 211 total builds):
    success: 178
    warnings: 19
    failure: 14
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/autolanduser@mozilla.com-65db5faf09e2
Comment 21 Ed Morley [:emorley] 2012-02-10 12:59:53 PST
(In reply to Olli Pettay [:smaug] from comment #16)
> >+  if(Preferences::GetBool("dom.event.onClipboardEvent.enabled", true)){
> add space after 'if' and before '{'

This review comment needs to be addressed. Also please can you add a commit message & tweak your .hgrc to automatically add the patch author meta (https://developer.mozilla.org/en/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F) :-)
Comment 22 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-02-13 10:09:06 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/19a59b40b90a
Comment 23 Robert Accettura [:raccettura] 2012-02-13 18:17:58 PST
Created attachment 596890 [details] [diff] [review]
Patch v4

Updated
Comment 24 Marco Bonardo [::mak] 2012-02-14 02:23:48 PST
https://hg.mozilla.org/mozilla-central/rev/19a59b40b90a
Comment 25 kie000 2012-07-30 03:58:27 PDT
I strongly object to websites mucking around with *MY* clipboard, particularly the ability to clear the clipboard, no site should ever have that right.

Sometimes I wish to be able to paste an email address twice without some overbearing corporation deciding that I'm some kind of moron who can't type my 3char @ 5char .com  email address correctly.
Comment 26 keegkey 2012-08-30 13:41:35 PDT
Setting pref "dom.event.clipboardevents.enabled" to false causes pasted text to disappear immediately when cursor is moved in scratchpad or stylish-editor.
Comment 27 Virtual_ManPL [:Virtual] - (ni? me) 2012-08-31 01:00:36 PDT
(In reply to keegkey from comment #26)
> Setting pref "dom.event.clipboardevents.enabled" to false causes pasted text
> to disappear immediately when cursor is moved in scratchpad or
> stylish-editor.

Please report a bug about it and link it to this bug. Thank you.
Comment 28 taglife 2012-10-02 08:18:01 PDT
WHY dom.event.contextmenu.enabled have GUI config,
dom.event.clipboardevents.enabled No GUI config Orz...????
Comment 29 Daniel Kabs, reporting bugs since 2002 2013-11-20 06:57:48 PST
Thanks for giving us the "dom.event.clipboardevents.enabled" option. This is what makes Firefox different! Firefox returns the power to the users so the users have a choice.

Note You need to log in before you can comment on or make changes to this bug.