Closed Bug 1140351 Opened 9 years ago Closed 9 years ago

Can't paste into TinyMCE when dom.event.clipboardevents.enabled=false

Categories

(Web Compatibility :: Site Reports, defect)

Firefox 35
x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: keegkey, Unassigned, NeedInfo)

References

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150130194334

Steps to reproduce:

Go to http://www.tinymce.com/tryit/basic.php and try to paste anything into editor with CTRL+V


Actual results:

Nothing happens


Expected results:

Pasted text should show up in editor
With these, pasting does not happen if dom.event.clipboardevents.enabled=false:

firefox-33.1.1.ru.linux64
firefox-34.0.5.en-US.linux64
firefox-35.0.ru.linux64
2015-03-08-03-02-27-mozilla-central-firefox-39.0a1.ru.linux-x86_64

However, if I disable JS and reload the page, it's just an HTML code editor.

What is it different from?
QA Whiteboard: [bugday-20150309]
Flags: needinfo?(keegkey)
Now I also tested Linux-x86_64-en-US versions: 35,34,31,26 and you are right, when property is set to false ctrl+v doesn't work in all of tested versions, therefore this is either very old regression or was never working correctly.

I noticed pasting issue since I upgraded to roundcube v1.1 from v1.0. 
Pasting works if I disable tinymce paste plugin in roundcube, but then MsWord cleanup/formating on paste does not work. 
Also if JS is disabled as you mentioned pasting also works but then you don't have rich text editor anymore.

Either way I believe that copy/paste should work always, regardless of the preference dom.event.clipboardevents.enabled being set or not.

As far as I understand dom.event.clipboardevents.enabled only enables web developer to hook into copy/paste clipboard events to do some additional processing if desired but if hooks aren't available meaning clipboardevents.enabled is set to false, then it should fail silently and allow user to continue with copy/paste operation as usual.

If any more info/testing is needed I'm happy to assist.
Flags: needinfo?(keegkey)
Could be that tinymce disables pasting and relies on the events to insert pasted text itself. If there's a problem on Firefox end here, the way to move forward is create a minimal testcase for the bug.
Flags: needinfo?(keegkey)
Keywords: testcase-wanted
Summary: Regression, when dom.event.clipboardevents.enabled=false, since ff v35 → Can't paste into TinyMCE when dom.event.clipboardevents.enabled=false
Spoofing as for example Safari makes pasting work again.. :-]
Is this common that people disable the clipboard events though configuration. We block the browser default behavior and use the paste events to filter HTML contents. There doesn't seem to be a way to feature detect if this option is there or not the event simply doesn't fire if set to false.

We use a fallback method of listening for keyboard events and move around focus to try to grab the contents being pasted.

This isn't a Firefox bug and not sure why someone would wan't to disable that event.
(In reply to Spocke from comment #5)
> This isn't a Firefox bug and not sure why someone would wan't to disable
> that event.

http://dev.w3.org/2006/webapi/clipops/#other-security-and-privacy-considerations
(In reply to Spocke from comment #5)
> Is this common that people disable the clipboard events though
> configuration.

It's hardly common.. as with most obscure about:config options, some people will find and use them.

> We block the browser default behavior and use the paste
> events to filter HTML contents. There doesn't seem to be a way to feature
> detect if this option is there or not the event simply doesn't fire if set
> to false.

Good point. Though perhaps the discussion in bug 1052569 on whether to disallow overriding/blocking of ctrl-c/v/x will end up in a fix that resolves this bug? (Seems nobody reported the requested separate bug over there though).

> We use a fallback method of listening for keyboard events and move around
> focus to try to grab the contents being pasted.

Perhaps there's some browser sniffing involved when applying the fallback?

> 
> This isn't a Firefox bug

Thank you for confirming that :)

(I'll move this to tech evangelism since it's an issue with the site's code, but we should probably just close it.)
Keywords: testcase-wanted
Can't move it because Bugzilla seems to misbehave right now. So I'll just close it.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
See Also: → 1052569
Component: Untriaged → Desktop
Product: Firefox → Tech Evangelism
Version: 35 Branch → Firefox 35
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.