Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED in mozilla13

Status

()

Core
DOM: Events
--
enhancement
RESOLVED FIXED
8 years ago
3 years ago

People

(Reporter: Anderson, Assigned: raccettura)

Tracking

unspecified
mozilla13
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

8 years ago
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

8 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86 → All

Comment 2

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

7 years ago
(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

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

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

7 years ago
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.
(Assignee)

Updated

6 years ago
Assignee: nobody → robert
Status: NEW → ASSIGNED
(Assignee)

Comment 7

6 years ago
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.
(Assignee)

Updated

6 years ago
Attachment #595183 - Attachment is patch: true
(Assignee)

Comment 8

6 years ago
Also: likely the first C I've written since ~2005, and I totally don't know who reviews this stuff anymore ;)

/be gentle
Comment on attachment 595183 [details] [diff] [review]
Patch v1

Let's try one of the usual suspects.
Attachment #595183 - Flags: review?(bugs)
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).
Assignee: robert → nobody
Component: Preferences → DOM: Events
Product: Firefox → Core
QA Contact: preferences → events
Assignee: nobody → robert
(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.
(Assignee)

Comment 12

6 years ago
Created attachment 595281 [details] [diff] [review]
Patch v2

Moved pref to all.js
Attachment #595183 - Attachment is obsolete: true
Attachment #595183 - Flags: review?(bugs)
(Assignee)

Updated

6 years ago
Attachment #595281 - Flags: review?(bugs)
(Assignee)

Comment 13

6 years ago
(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

6 years ago
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

6 years ago
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 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
Attachment #595281 - Flags: review?(bugs) → review+
(Assignee)

Comment 17

6 years ago
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.
Attachment #595281 - Attachment is obsolete: true
Attachment #595583 - Flags: review+
Keywords: checkin-needed
Comment on attachment 595583 [details] [diff] [review]
Patch v3 (addressing review comments)

(To keep autoland to try happy about permissions)
Attachment #595583 - Flags: review+

Updated

6 years ago
Whiteboard: [autoland-try]

Updated

6 years ago
Whiteboard: [autoland-try] → [autoland-in-queue]

Comment 19

6 years ago
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

6 years ago
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

Updated

6 years ago
Whiteboard: [autoland-in-queue]
(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) :-)
https://hg.mozilla.org/integration/mozilla-inbound/rev/19a59b40b90a
Flags: in-testsuite-
Keywords: checkin-needed
Target Milestone: --- → mozilla13
(Assignee)

Comment 23

6 years ago
Created attachment 596890 [details] [diff] [review]
Patch v4

Updated
Attachment #595583 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/19a59b40b90a
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 25

5 years ago
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

5 years ago
Setting pref "dom.event.clipboardevents.enabled" to false causes pasted text to disappear immediately when cursor is moved in scratchpad or stylish-editor.
(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

5 years ago
WHY dom.event.contextmenu.enabled have GUI config,
dom.event.clipboardevents.enabled No GUI config Orz...????
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.
You need to log in before you can comment on or make changes to this bug.