Dropping image file onto `contenteditable` causes inserting `<img>` element but not show the image set to `src` attribute as data URI
Categories
(Core :: DOM: Editor, defect)
Tracking
()
People
(Reporter: masayuki, Unassigned)
References
Details
STR:
- Open
data:text/html,<div contenteditable><br></div>. - Drag an image file from desktop or the filer.
- Drop it onto the
contenteditable.
ER:
<img> element should show the image with data URI.
AR:
<img> file is inserted, but the data URI isn't loaded as image.
Oddly, loading the data URI in new tab works fine. Does Gecko have some limitation about <img src="data:image/...">?
Note that Chrome always load the image file as new document. (I.e., their editor does not handle file drop.) And Safari does nothing if file is dropped onto contenteditable. So, it might be better to stop HTMLEditor handling file drop (I mean that HTMLEditor should just dispatch beforeinput event but does nothing) on web content.
WDYT, Makoto-san and Smaug?
|
Reporter | |
Comment 1•5 years ago
|
||
On Thunderbird's composer, the <img> element loads the data URI as expected.
If this feature is required only by comm-central and BlueGriffon, it may be better that they handle beforeinput event whose inputType is insertFromDrop, insertFromPaste and insertFromPasteAsQuotation by themselves. If so, we could drop a lot of code from HTMLEditorDataTransfer.cpp.
|
||
Comment 2•5 years ago
|
||
Yes, we do the data URL "manually":
https://searchfox.org/comm-central/rev/aa0c76715434b622ba922f0bc3023b166fcff93d/mail/components/compose/content/MsgComposeCommands.js#2720
This is unrelated but in the same context:
https://searchfox.org/comm-central/search?q=symbol%3A%23loadBlockedImage&case=false®exp=false&path=mail%2Fcomponents%2Fcompose%2Fcontent%2FMsgComposeCommands.js
|
|
Reporter | |
Comment 3•5 years ago
|
||
Thank you, Jorg, that's really good news for us!
|
|
||
Comment 4•5 years ago
•
|
||
On Windows, open https://www-archive.mozilla.org/editor/midasdemo/ and drop an image. Then check the source box. I see a data: URL as expected. What's the bug? Edit: Using FF 68.4.1 ESR.
|
||
Comment 5•5 years ago
|
||
As Web based editor, it is better to use drag&drop API to insert image. So I think that WebKit's behavior is simple. Should we need telemetry data to know whether user uses this feature?
|
|
Reporter | |
Comment 6•5 years ago
|
||
(In reply to Jorg K (GMT+1) (PTO to 26th Jan 2020, sporadically reading bugmail) from comment #4)
On Windows, open https://www-archive.mozilla.org/editor/midasdemo/ and drop an image. Then check the source box. I see a data: URL as expected. What's the bug? Edit: Using FF 68.4.1 ESR.
Ah, sorry, I was tested on my testsite, but I realized that the data URI is blocked by its "Content-Security-Policy". So, this should be marked as INVA.
(In reply to Makoto Kato [:m_kato] from comment #5)
As Web based editor, it is better to use drag&drop API to insert image. So I think that WebKit's behavior is simple. Should we need telemetry data to know whether user uses this feature?
Yeah, I'm still thinking that we can drop these complicated code from m-c since the other browsers don't support this, and Thunderbird supports it by itself. I'll file a bug to collect the telemetry.
Description
•