542938 - Firefox should give a setting that disables oncopy, oncut & onpaste event handling

Status: RESOLVED FIXED

(Core :: DOM: Events, enhancement)

Description

[Anderson]

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]

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]

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]

(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]

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]

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]

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]]

Attachment: 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]]

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)]

Comment on attachment 595183 [details] [diff] [review]
Patch v1

Let's try one of the usual suspects.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

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]]

(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]]

Attachment: Patch v2

Moved pref to all.js

Comment 13

[Robert Accettura [:raccettura]]

(In reply to Gavin Sharp (use [e-mail] 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]

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]

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][[e-mail]]]

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]]

Attachment: 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]]

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]

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]

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/[e-mail]-65db5faf09e2

Comment 21

[Ed Morley [:emorley]]

(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: [e-mail]]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/19a59b40b90a

Comment 23

[Robert Accettura [:raccettura]]

Attachment: Patch v4

Updated

Comment 24

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/19a59b40b90a

Comment 25

[kie000]

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]

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] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(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]

WHY dom.event.contextmenu.enabled have GUI config,
dom.event.clipboardevents.enabled No GUI config Orz...????

Comment 29

[Daniel Kabs, reporting bugs since 2002]

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.

Comment 30

[M E]

Preface: I know this is an ancient bug, and I second the comment immediately above this one.

But where is the exposed preferences setting Josh refers to? Gone? I searched high and low. (Used dom.event.clipboardevents.enabled for now.)

(In reply to @Josh Triplett from comment #3)

(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.)

(Meta:

1. I'm finding apparent ADA violations even on sites SPECIFICALLY FOR DISABLED people, like at onpaste="return false" blocking paste at https://www.etimesheets.ihss.ca.gov/login, etc.
2. Related is a recent security flaw where other apps, e.g. TikTok, were running in the background were accessing the clipboard and stealing stuff - and Apple initially ignored the clipboard vulnerability - Forbes, Ars, BBC , https://nakedsecurity.sophos.com/2020/06/30/ios-14-flags-tiktok-53-other-apps-spying-on-iphone-clipboards/ -
3. Perhaps the W3C is the place to push for resolution, using the ADA violation angle as a club to force it to be addressed? Why? I initially brought the issue up with Apple Support (same bug in Safari) and they insist it's not a bug because it happens in Firefox too.)