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]
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.
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.
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.)
Can't move it because Bugzilla seems to misbehave right now. So I'll just close it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
Component: Untriaged → Desktop
Product: Firefox → Tech Evangelism
Version: 35 Branch → Firefox 35
Component: Desktop → Desktop
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.