fine-uploader
fine-uploader copied to clipboard
Allow paste to upload in Firefox, safari, and possibly IE
Currently, this is only supported in browsers that fully support the clipboard API, which means Chrome. Support for upload via paste will be a bit more complicated and potentially limited (depending on the approach) for browsers that do not fully implement the clipboard API. See case #487 for details regarding support for upload via paste already added for browsers that support the clipboard API.
I'd like to see paste support in Safari, Firefox & optionally IE, but most importantly Safari for us.
Keep in mind that this will require server-side cooperation from integrators like yourself who want this feature outside of Chrome. In short, you'd have to proxy pasted images from your own server if the image is from a different domain if the server hosting the image doesn't implement the CORS spec (or if the browser doesn't support CORS for images).
The main use case for us is to be able to paste screenshots which are saved directly into the clipboard on Mac.
This is typically how our testers send us bug reports. If they have to save the screenshot to their desktop it gets far too cluttered far too quickly.
Mac OS has a keyboard shortcut which allows saving a screenshot to the clipboard.
Sent from my iPhone
On 31/10/2013, at 3:20 am, Ray Nicholus [email protected] wrote:
Keep in mind that this will require server-side cooperation from integrators like yourself who want this feature outside of Chrome. In short, you'd have to proxy pasted images from your own server if the image is from a different domain in many cases.
— Reply to this email directly or view it on GitHub.
For that particular workflow, CORS shouldn't be a factor. I can see how this might be useful, but I'm wondering why you don't just suggest your testers use Chrome to make their lives easier. I can certainly increase the priority of this feature, though.
We can definitely do that in the interim, although it would be simplest for them if they didn't need to worry what browser they were reporting from—the plan is to build a tool we can drop into our websites which logs bugs & screenshots to our system, without needing to have the system itself open.
This would also ideally be opened up to end users should they encounter an issue with the system.
That all makes sense. I'm going to schedule this feature for 4.1 (the current release cycle). I was originally going to put it into 4.1, but moved it out after lack of response from users. With your comments and internal requests, I think it makes sense to look into this for 4.1.
Great, thanks for that, thats fantastic news.
Keep in mind that there are some unknowns here that make this potentially tricky. I know this can be done, but I haven't spent a lot of time considering exactly how I'm going to fit this into the existing feature set and supported workflows. Nonetheless, I'll be looking into it during this cycle.
After some more research, I've concluded that the only additional browser I can support for this feature is Firefox. Safari and IE simply cannot handle pasted images from the clipboard. The method for obtaining an image pasted from the clipboard in Firefox requires the use of a contenteditable <div>.
It looks like I will have to hide this <div> and focus it whenever the user starts their paste operation by pressing CMD/CTRL. This will, of course, take the focus away whatever element already has focus. I suppose I could return focus to the original element after the paste is complete, but this will likely cause problems where the upload form contains form fields (such as text input fields).
Another option would be to embed the specified paste target/container as a child of a contenteditable <div>, and simply handle the paste event when it reaches this parent. This would not require I mess with focus, and would (theoretically) ensure the feature works in FF just as it does in Chrome (to the user) since the paste container must be focused for the image paste feature to work in Chrome. However, this would prevent integrators from specifying document or <body> as a paste target in Firefox. It will also likely break (poor) selectors on sites that take hierarchy into account.
I'm thinking that, given the obstacles associated with enabling this feature in Firefox, I should put this off until a later date (perhaps until Firefox implements the Clipboard API).
Thanks for looking into this—a shame that the browser vendors haven't fully implemented support yet, but I guess that's the way of things.
It looks like it would be best to shelve this for now.
Internet Explorer 11 appears to have the same behavior as Firefox (i.e., can only paste images into contenteditable elements) [1]
[1] - http://msdn.microsoft.com/en-us/library/ie/dn265023(v=vs.85).aspx#clipboard
Blocked until these browsers support the Clipboard API.
It looks like several browser support this now. Has it been addressed?
To my knowledge, this is still only properly and completely supported in Chrome. Do you have evidence of support in other browsers? Did something change in Firefox recently to allow support?
On Tue, Oct 14, 2014 at 7:56 PM, dfoor [email protected] wrote:
It looks like several browser support this now. Has it been addressed?
Reply to this email directly or view it on GitHub: https://github.com/Widen/fine-uploader/issues/774#issuecomment-59142977
Here's the current support as per caniuse:
http://caniuse.com/#search=clipboard
Yea, I saw that. I believe that has claimed support for Firefox for a while, but it has been broken as long as I can remember. Haven't tried again recently. I'll test it out on other browsers and update this case. Feature detection for this feature has been impossible due to lack of a ClipboardEvent constructor function, which still seems to be an issue in most browsers.
On Tue, Oct 14, 2014 at 8:32 PM, Sam Sehnert [email protected] wrote:
Here's the current support as per caniuse:
http://caniuse.com/#search=clipboard
Reply to this email directly or view it on GitHub: https://github.com/Widen/fine-uploader/issues/774#issuecomment-59145912
Looks like Firefox (and possibly other browsers) still require the paste target to be a contenteditable div, and the only access to the file is via a data URI which then must be converted to a Blob. This is far from ideal, so I’m still calling this not supported.
— Sent from Mailbox
On Tue, Oct 14, 2014 at 8:37 PM, Ray Nicholus [email protected] wrote:
Yea, I saw that. I believe that has claimed support for Firefox for a while, but it has been broken as long as I can remember. Haven't tried again recently. I'll test it out on other browsers and update this case. Feature detection for this feature has been impossible due to lack of a ClipboardEvent constructor function, which still seems to be an issue in most browsers. On Tue, Oct 14, 2014 at 8:32 PM, Sam Sehnert [email protected] wrote:
Here's the current support as per caniuse:
http://caniuse.com/#search=clipboard
Reply to this email directly or view it on GitHub: https://github.com/Widen/fine-uploader/issues/774#issuecomment-59145912
I see--thanks for looking into this; I got excited when I saw it on caniuse and just wanted to check.
Would it be possible to convert the target on a browser case basis, and then use something like this to do the conversion?
Conversion of a data URI to a Blob is the easy part. Fine Uploader already has code to do that internally in the scaling/image preview modules. We’d have to determine which approach to use to extract the pasted image, perhaps based on the paste target? I can see how pasting to upload may be useful in other browsers, but I don’t see it as a high priority to get this working outside of Chrome (relatively speaking). Also, the required approach to get a handle on the pasted image is a bit kludgey, as it involves using setTimeout or setInterval to wait for the browser to create the IMG element after the paste with a src attribute representing the pasted image.
I’ll keep this open, and perhaps we’ll get to it at some point.
On Wed, Oct 15, 2014 at 12:17 PM, dfoor [email protected] wrote:
I see--thanks for looking into this; I got excited when I saw it on caniuse and just wanted to check.
Would it be possible to convert the target on a browser case basis, and then use something like this to do the conversion?
Reply to this email directly or view it on GitHub: https://github.com/Widen/fine-uploader/issues/774#issuecomment-59241555
Hello, any news on the subject? 2 years passed and was wondering if browser now fully support it. I have no experience of other browsers, but services like Slack or Trello do provide it regardless of the browser, or not? I've tried this example http://jsfiddle.net/FhUwn/392/ and it works in IE 11 as well
was wondering if browser now fully support it
Good question. Further investigation with backing evidence is the next step before going forward.
Good question. Further investigation with backing evidence is the next step before going forward.
I don't have enough knowledge to understand if Trello's or Slack's or the example I posted on JSFiddle solve the problem in the same way or not. By looking the code in JSFiddle are you able to determine if the solution put in practice will work because indeed the browsers are now fully supporting the feature, or if a workaround is put in place?
That fiddle is a bit noisy and I don't have the time to read through it. The best approach would be to see how far we can get with the implementation in Fine Uploader that already works for Chrome. Perhaps it is as simple as making a few trivial adjustments to make use of support for the clipboard API in other browsers.
I checked caniuse and the situation seems to not have changed in regards to the need of having a content editable div. And that jsfiddle uses that. The question is: how on hell Trello/Slack/Jira and the myriads of other services do?
They must use a contenteditable div of course