989621 - Images with non-file URLs copied from FF appear broken after (auto/manual) saving of draft; pasting images into TB composition does not use <img src="data: URI"> (inconsistent with drag & drop)

Status: NEW

(MailNews Core :: Composition, defect)

Description

[Thomas D. (:thomas8)]

Somewhere on the way from Firefox (right-click on image, "Copy image") to pasting into Thunderbird composition editor, there are bugs that cause images to NOT be inserted as data: URI as bug 490879 suggests to have implemented. So if somebody could check if this has regressed, been backed out or what other bugs there are, and in which products, I'd be grateful.

STR:

1) for each of the following URLs: load image URL in FF

a) https://encrypted-tbn2.gstatic.com/images?q=tbn:ANd9GcQed_VflTa0OvSRg2F0Lssc5wLEy6O2SKXPRbM7XpTmapAMgC7uyA
b) http://forum.2-ventiler.de/vbgallery/d/56016-3/fahrrad+logo-1.jpg

2) in FF, right-click on the image, "Copy image";
in TB composition (POP3 account), right-click, "Paste";
double-click on image to verify image src

3) for comparison, drag the images into TB composition (POP3 account)
double-click on image to verify image src

4) Ctrl+S to save composition


Actual result

2a) image with non-file URL copied from FF has invalid image src in TB (and does not use data: URI); first shows correctly in composition, but rendered as "broken image icon" upon saving of draft in step 4

mailbox:///C:/Dokumente%20und%20Einstellungen/User/Anwendungsdaten/Thunderbird/Profiles/foobar.default/Mail/pop.googlemail.com/Drafts?number=12345&q=tbn:ANd9GcQed_VflTa0OvSRg2F0Lssc5wLEy6O2SKXPRbM7XpTmapAMgC7uyA

2b) image with file URL copied from FF has valid image src in TB (but still does not use data: URI)

http://forum.2-ventiler.de/vbgallery/d/56016-3/fahrrad+logo-1.jpg

3) only *dragging* images into TB (regardless of non-file URL or not) will correctly use data: URI per this bug (and takes ages to pop up image properties dialogue for big image b):

a) data:image/bmp;base64,Qk36EAMAAAAAAIoAAAB8A[snip]
b) data:image/bmp;base64,Qk2KDDUAAAAAAIoAAAB8A[snip]


Expected result:

copying/pasting of image a) should work; do not create broken src link which is mixed from local path and original URL query

pasting of images should always insert them as data: URI (per bug 490879), as currently done when dropping images into TB composition

Comment 1

[rsx11m]

(Quoting myself from bug 490879 comment #38)
> I would assume that Firefox puts a text/html part onto the clipboard given
> that you are copy-pasting an <img> HTML element. On the other hand, there
> should also be an image/* flavor if you've used "Copy Image" which
> Thunderbird would need to prefer over the text/html part when pasting, then
> it should be encoded as data: URI there. Assuming that you are on Windows,
> the image part may only be available as DIB and thus would need to be
> recoded as PNG or JPEG depending on clipboard.paste_image_type, hence
> pasting the reference has the advantage of retaining the original encoding
> of the web page as is.

Clearly, the current approach of passing the image by reference and downloading the image from the source breaks if the context is lost (e.g., secure sites requiring login, image depends on context like cookies, etc.), thus recoding the image may be the lesser of two evil.

I don't think that this is a regression. The behavior has always been like that even before bug 490879 landed changing the temporary file into a data: URI for pasting.

Comment 2

[rsx11m]

(In reply to Thomas D. from comment #0)
> 2a) image with non-file URL copied from FF has invalid image src in TB (and
> does not use data: URI); first shows correctly in composition, but rendered
> as "broken image icon" upon saving of draft in step 4
> 
> mailbox:///C:/Dokumente%20und%20Einstellungen/User/Anwendungsdaten/

How did you create a mailbox: URI in Firefox? This shouldn't be available there. Within Thunderbird itself, mailbox: URIs should resolve (if they are still valid at the time the message is sent, but that's a different bug).

> 3) only *dragging* images into TB (regardless of non-file URL or not) will
> correctly use data: URI per this bug (and takes ages to pop up image
> properties dialogue for big image b):

This is also subject to bug 557708, thus drag-and-drop produces (potentially broken) BMP data URIs (which would suggest that here as well the image is recoded to DIB at the source for transfer over the clipboard but not recoded to PNG or JPEG when pasting).

Comment 3

[Thomas D. (:thomas8)]

(In reply to rsx11m from comment #2)
> (In reply to Thomas D. from comment #0)
> > 2a) image with non-file URL copied from FF has invalid image src in TB (and
> > does not use data: URI); first shows correctly in composition, but rendered
> > as "broken image icon" upon saving of draft in step 4
> > 
> > mailbox:///C:/Dokumente%20und%20Einstellungen/User/Anwendungsdaten/
> 
> How did you create a mailbox: URI in Firefox? This shouldn't be available
> there. Within Thunderbird itself, mailbox: URIs should resolve (if they are
> still valid at the time the message is sent, but that's a different bug).

No, you misunderstood.
FF URL was:
a) https://encrypted-tbn2.gstatic.com/images?q=tbn:ANd9GcQed_VflTa0OvSRg2F0Lssc5wLEy6O2SKXPRbM7XpTmapAMgC7uyA

After copying that image into TB composition (via context menus in FF and TB), TB wrongly converts that into the following broken image src:

mailbox:///C:/Dokumente%20und%20Einstellungen/User/Anwendungsdaten/Thunderbird/Profiles/foobar.default/Mail/pop.googlemail.com/Drafts?number=12345&q=tbn:ANd9GcQed_VflTa0OvSRg2F0Lssc5wLEy6O2SKXPRbM7XpTmapAMgC7uyA

> I don't think that this is a regression. The behavior has always been like that even before bug
> 490879 landed changing the temporary file into a data: URI for pasting.

Only that in the *live* composition (don't know about saved draft), we do NOT even point to temporary files (snapshots owned by TB), we just point to the original source file on the web, which, as you correctly confirmed, is entirely out of our control as the source can become inaccessible any time for a number of reasons. But the UI/behaviour wrongly suggest to the user that image has successfully been copied into the composition, because it appears there, and the dataloss surprise will only come upon saving of draft or sending.

Comment 4

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #3)

> After copying that image into TB composition (via context menus in FF and
> TB), TB wrongly converts that into the following broken image src:

TB's wrongdoing occurs immediately after saving as draft (manual/automatical), and the image turns into broken image icon because the created local path is obviously invalid:

> mailbox:///C:/Dokumente%20und%20Einstellungen/User/Anwendungsdaten/
> Thunderbird/Profiles/foobar.default/Mail/pop.googlemail.com/
> Drafts?number=12345&q=tbn:
> ANd9GcQed_VflTa0OvSRg2F0Lssc5wLEy6O2SKXPRbM7XpTmapAMgC7uyA

Comment 5

[rsx11m]

Ok. I don't know what "q=tbn:..." does, but I'd expect to see something like "part=1.2" as a reference after saving as draft instead. This may be part of bug 557708 though (or at least triggered by it).

Comment 6

[Thomas D. (:thomas8)]

(In reply to rsx11m from comment #5)
> Ok. I don't know what "q=tbn:..." does, but I'd expect to see something like
> "part=1.2" as a reference after saving as draft instead. This may be part of
> bug 557708 though (or at least triggered by it).

As shown in comment 0 and comment 3, "q=tbn:..." is part of the original FF image URL a):
https://encrypted-tbn2.gstatic.com/images?q=tbn:ANd9GcQed_VflTa0OvSRg2F0Lssc5wLEy6O2SKXPRbM7XpTmapAMgC7uyA

So for some reason TB uses the part of the browser URL after the questionmark and merges that with a local path (which behaviour might be related to the expected structure of TB mime parts URLs cited by you).

Btw, image URL has the common pattern of google image search preview images:
http://www.images.google.com/images?q=fahrrad
Right-click on any preview image, "Show image" to get such URLs having "serverURL/images?q=tbn:..."

Comment 7

[WADA:World Anti-bad-Duping Agency]

Image location after, compose, Insert image with the URL, several save, end composition, Edit Draft.
Image location correctly points draft mail.
> mailbox:///C:/Documents%20and%20Settings/wada/Application%20Data/Thunderbird/Profiles/wkeci8t7.ZZZ/Mail/pop.ops.dti.ne.jp/Drafts?number=53156&part=1.2
HTML part correctly points Content-ID.
    <img alt="" src="cid:[e-mail]"
      height="163" width="308">--------------060408010001070809090702
Embed image part. Content-Type is set as text/html wrongly. (site rerurns image/jpeg correctly)
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: base64
 Content-ID: <[e-mail]>

It looks that following URL is text/html for Thunderbird. (site rerurns image/jpeg correctly)
> https://encrypted-tbn2.gstatic.com/images?q=tbn:ANd9GcQed_VflTa0OvSRg2F0Lssc5wLEy6O2SKXPRbM7XpTmapAMgC7uyA

Comment 8

[WADA:World Anti-bad-Duping Agency]

"text/html in message source of draft mail in Drafts" was set by first save after Insert image with the URL.
Image location after the first save is still URL, and preview shows image correctly.
> https://encrypted-tbn2.gstatic.com/images?q=tbn:ANd9GcQed_VflTa0OvSRg2F0Lssc5wLEy6O2SKXPRbM7XpTmapAMgC7uyA
After second save, Image location is changed to internal mailbox URI, but query part is not part1.2.
> mailbox:///C:/Documents%20and%20Settings/wada/Application%20Data/Thunderbird/Profiles/wkeci8t7.ZZZ/Mail/pop.ops.dti.ne.jp/Drafts?number=75544&q=tbn:ANd9GcQed_VflTa0OvSRg2F0Lssc5wLEy6O2SKXPRbM7XpTmapAMgC7uyA
and Image Preview shows nothing.
This url is kept for this mail composing.
HTML source and message header of saved draft is normal, except Content-Type: text/html for embed image part.
However, data in the part is broken, because Tb considered it TEXT/HTML.
Following is data of the part shown by; multipart/related -> multipart/mixed, Content-Type: text/plain, Rebuild-Index, view draft mail.
> <html>
> <head>
> <title>1</title>
> <link rel="important stylesheet" href="chrome://messagebody/skin/messageBody.css">
> </head>
> <body>
> <table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part1"><tr><td><div class="headerdisplayname" style="display:inline;">Subject: </div>1</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">From: </div>FirstName LastName &lt;[e-mail]&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Date: </div>2014/03/30 08:20</td></tr></table><table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part2"><tr><td><div class="headerdisplayname" style="display:inline;">To: </div>&quot;@Z.Z.Z z&quot;, &quot;@zzz.zzz.zzz&gt;&quot;</td></tr></table><br>
> <div class="moz-text-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 13px;" lang="x-western"><pre wrap>
> </pre></div></body>
> </html>
> <br><fieldset class="mimeAttachmentHeader"><legend class="mimeAttachmentHeaderName">Attachments:</legend></fieldset><div class="mimeAttachmentWrap"><table class="mimeAttachmentTable"><tr><td class="mimeAttachmentFile">Part 1.2</td><td class="mimeAttachmentSize">17179869184 GB</td></tr></table></div>

Comment 9

[WADA:World Anti-bad-Duping Agency]

For following part in bug summary.
> pasting images into TB composition does not use <img src="data: URI"> (inconsistent with drag & drop)
It's simple: different code is used in (group-A) "Copy at Firefox + Paste at composer", "Insert Image with requesting URI of image", and (group-B) "Drag&Drop from Fx to Tb".
If group-A, this bug occurs.
If group-B, bug 871873 occurs.
Problem is not "inconsistency between group-A and group-B".
Problem is "wrong interpretation of URI" in both cases.
  This bug : if URI for image data contais hash/query part, Tb wrongly interprets it.
  That bug : Tb fails to choose file URI from Dropped data, then Tb uses data: URI,
             thus image/bmp is used for .jpg data.

If local file is shown at SeaMonkey, and if the image is passed Tb's compose window via group-A : "Copy Image at SeaMonkey + Paste at composer", following uri is used by SeaMonnkey,
  file:///C:/wada/@@@/Data/JpegFile.jpg
and following is used as "Image Location" by composer.
  file:///C:/wada/@@@/Data/JpegFile.jpg
SeaMonkey shows the local image file correctly, even when query part is intentionally added to file url. query part is ignored correctly by SeaMonkey because of "file url" upon image file display. 
  file:///C:/wada/@@@/Data/JpegFile.jpg?xyz
If this image is copied by "Copy Image" and is pasted to Tb's composer window, following URI is used as "Image Location",
  file:///C:/wada/@@@/Data/JpegFile.jpg?xyz
and followin URI is generated by Tb after draft save,
  mailbox:///C:/ ... /Mail/pop.ops.dti.ne.jp/Drafts?number=3025969&xyz
and this bug is reproduced.

If http: or https: uri, hash part, query part, has meaning, and it should be kept upon HTTP request, because server application such as PHP code can freely use hash part, query part, for returning image data to HTTP client.
- when file URI, Tb should ignore hash part, query part, upon URL interpretation and manipulation.
- when http/https URI, Tb should interpret "URI with hash part, query part" correctly in
  interpretation of URI, and Tb should remove hash/query part, upon mailbox:/imap: URI generation,
  or Tb should correctly remove hash/query part from mailbox:/imap: URI upon URI interpretation.
This bug is also a chaos which was generated by supremely sophisticated "use URI in any place for any purpose", which is seen in many bugs. Escaping is mandatory because URI has many limitations in special character use and has very special his own rules => escaping problems. Once URI is escaped, it's impossible to know whether the URI is escaped or not => %/%25 problems. Due to URI, contention occurs on special character between "URI rule" and "IMAP rule" => many problems on Mbox name character, ..., ..., ...

Comment 10

[WADA:World Anti-bad-Duping Agency]

Test with "file URL with intentional hash/query part in URL".

0. View a local image file by SeaMonkey, with excess hash/query part in file URL.
     file:///C:/wada/@@@/Data/JpegFile.jpg#abc?xyz
   This is to force "url with hash/query for image data".
1. Copy Image at SeaMonkey, Paste at Tb's HTML compose window.
   Image Location : file:///C:/wada/@@@/Data/JpegFile.jpg#abc?xyz
   Image is shown at compose widow.
   Save as draft #1 => part = imae/jpeg, data is correct => image is shown by view draft mail 
   Image Location is not changed by draft save #1, and image is shown after draft save #1
2. Save as draft #2 => part = imae/jpeg, data is correct => image is shown by view draft mail
   However, after save as raft #2, image is broken at compose window,
   and Image Location is changed to
     mailbox:///C:/　 ... /Mail/pop.ops.dti.ne.jp/Drafts?number=373912&xyz
3. Save as draft #3 => part = text/html, part data is broken  => image is broken by view draft mail
   after it, following cotinuesafter each save, or Send Later, or Send.
     image is broken at compose window after save.
     image part = text/html in saved draft, sent mail,
     datt of image part is broken(html data is base64 encoded),
     Image Location is always mailbox:///C:/　... /Mail/pop.ops.dti.ne.jp/Drafts?number=NNNNNN&xyz
　　　　(NNNNNN=messageOffset is changed uon each saved as draft)

"text/html part for embed image" and "base64 encoded data i te text/html part" is generated by "Image Location change to "mailbox:/// ... / Drafts?number=NNNNNN&xyz.
Cause is "excess &xyz part in mailbox: URL which comes from Query part in original http/https/file URL for image data".
String after "?number" is used for "&part=1.2", "&filename=xxx" etc. for attached file, embed image, attached mail etc.

If "query part of original http/https URL for image" = "?filename=xxx" or "?part=1.2" like one, what will occur? :-)
"hash part in URL for image data" is removed correctly from internal mailbox: URL generated by Tb.
Why hashed part is remved but query par is not removed?

Comment 11

[WADA:World Anti-bad-Duping Agency]

For following part in bug summary.
> pasting images into TB composition does not use <img src="data: URI"> (inconsistent with drag & drop)

For consistecy among Drag&Drop, Copy&Paste, Insert Image by URL, and for "snap shot upon insert/attach operation", "conversion to data: URI from event.dataTransfer["files"][0](==absolute path of local file)", which is currently used in Drag&Drop, may be better portd as "conversion to data: URI from any URL/file name" to all Drag&Drop, Copy&Paste, Insert, Attach operations.

Comment 12

[WADA:World Anti-bad-Duping Agency]

As known by duplication test with file:///C:/ .../JpegFile.jpg#abc?xyz, file: URL or http(s): URL is irrelevant to problem. Problem occurs when query part exists in URL. And it looks that hash part won't produce problem.

Comment 13

[WADA:World Anti-bad-Duping Agency]

Possible solution of this bug.
(a) Remove query part from mailbox:/imap: URL for embed image data in draft, as done on hash part.
(b) Convert URL for image to "data: URI" upon Insert Image operation
    as done in Drag&Drop of local image file(conversion from absolute file path -> data: URL),
    and keep in JavaScript Object while mail composing,
    and put it as <img src="data:..."> in draft mail,
    then, finally convert to embed image part with Content-Id: and change <img> to cid: URL.
    Because there is no need of query part in data: URL, query part is automatically ignored by Tb.
    Proble in it: If same large image is used by many <img> tags, huge draft mail is generated.