729587 - Drag and Drop data:image base64 encoding should be disabled by default

Status: UNCONFIRMED

(SeaMonkey :: Composer, defect, P5)

Description

[Square Candy Design]

Attachment: firefox-base64.jpg

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Build ID: 20120215223356

Steps to reproduce:

Dragging images into popular rich-text editors: TinyMCE (wordpress), CKEditor, etc.


Actual results:

From the perspective of the average WYSIWYG user, the image has been "uploaded" to the server.  They see this as a success, but now they have possibly multiple MB of base64 encoding in the middle of their HTML output, so the entire image must load before the HTML below it does. 


Expected results:

I feel that this "feature" should be disabled by default, with an option to enable in settings.  Discussions on the issue found here:
http://stackoverflow.com/questions/6708747/firefox-allows-desktop-image-files-to-be-dragged-in-to-ckeditor
http://www.tinymce.com/forum/viewtopic.php?id=5090
Obviously this is a problem that many are struggling to find some JS hack to solve. Disabling it by default at the browser level is the best long-term solution.

Comment 1

[Square Candy Design]

http://drupal.org/node/1193036

Comment 2

[(mostly gone) XtC4UaLL [:xtc4uall]]

I can confirm that Firefox behaves differently than Chrome on this, e.g. on http://www.tinymce.com/tryit/full.php .

Dropping a Picture File in Chrome leads to an Image View of the file: Path and not being dropped into the WYSIWYG-View.

Comment 3

[Square Candy Design]

Reproduced behavior in YUI editor, NicEdit, WYMeditor as well: 
http://yuilibrary.com/yui/docs/editor/editor-exec.html
http://nicedit.com/demos.php
http://files.wymeditor.org/wymeditor/trunk/src/examples/01-basic.html

Comment 4

[Kari Söderholm]

The same behaviour occurs when you paste image data from the clipboard.

I think it's neat that Firefox supports this. I can see uses for it. But it should be configurable through JavaScript to suit your application's needs.

For now I would like to block this behaviour on some configurations to force end-users of some CMS installations to do a traditional upload of images instead of pasting/dropping images to the editor to be saved inline with the HTML content.

This problem is only with Firefox. I checked this doesn't happen in IE, Chrome or Safari.

Btw. When viewing content, these inlined images display as broken images in IE8 and older.

Comment 5

[Vianney Stroebel]

This should not be the default behaviour. It creates gigantic base64 strings inside content, which I've seen crash a pretty beefy LAMP server (probably due to the CMS trying to parse it at some point).

The Drupal community is trying to handle this problem with JS or PHP based regex replace, but these are CPU-intensive too and it doesn't seem fair to me that web developers and sysadmins all over the world should have to deal with an arbitrary and unjustified change of behaviour from just one web browser.

Vianney

Comment 6

[Michael Brown]

Yes I agree this should not be the default. I now have to write server side code to strip out this data from CKEditor as there isn't any way to disable the behavior. Really confusing for users, especially when you are already handling drag & drop on the page and WYSIWYG editors are messing with your user experience.

Comment 7

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Comment 8

[cvmiller]

I can confirm this issue in Composer with the most recently released version for x86_64 on Linux (seamonkey-2.53.10.2.en-US.linux-x86_64.tar.bz2). Drag and Drop an image results in a Base64 blob, rather than a HTML reference to the image.
This prevents using Seamonkey/Composer as a WYSIWYG HTML editor.

Request a preference option to enable/disable Base64 on images (when using Drag & Drop).

Comment 9

[Jens Stutte [:jstutte]]

Hi Mirko, we might want to re-triage this.

Comment 10

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

cvmiller: could you please be so kind and provide an example for Firefox to reproduce this?

I tried drag and dropping an image from www.mozilla.org to https://www.tiny.cloud/docs/demo/full-featured/ and it's included as an image not a Bas64 blob.

Comment 11

[cvmiller]

There is a misunderstanding of the problem. The problem is when an image from a file manager (such as Thunar) is "drag-and-dropped" on to a Mozilla Composer Window. The image is displayed in Mozilla Composer, but rather than an <img> link, it is a Base64Blob.

You can obtain mozilla-composer from:
https://www.seamonkey-project.org/

Comment 12

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

(In reply to cvmiller from comment #11)

There is a misunderstanding of the problem.

Thanks for the response. There might also be a misunderstanding of this bug-ticket's scope :-).

The problem is when an image from a file manager (such as Thunar) is "drag-and-dropped" on to a Mozilla Composer Window. The image is displayed in Mozilla Composer, but rather than an <img> link, it is a Base64Blob.

Is it clear, that's happening because of Gecko-specific code? As I couldn't reproduce that in Firefox, I doubt that. If you can provide a concrete reproduction scenario for Firefox, that would be helpful.

You can obtain mozilla-composer from:
https://www.seamonkey-project.org/

Thanks, tried it and understand the problem for Seamonkey-users.