Closed Bug 224733 Opened 21 years ago Closed 13 years ago

escape issues with mailbox urls in the compose window

Categories

(MailNews Core :: Composition, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(thunderbird8-, thunderbird9- fixed)

VERIFIED FIXED
Thunderbird 10.0
Tracking Status
thunderbird8 - ---
thunderbird9 - fixed

People

(Reporter: mscott, Assigned: Bienvenu)

References

Details

Attachments

(2 files, 1 obsolete file)

From the forums:

Copy and paste from the clipboard is a great feature and much appreciated.
But how about copy and paste within the compose windows, this has not been
possible for a long time. The image source links get lost.
Simple copy/paste:
Insert an image in an HTML compose message
Select the image |edit copy
Edit |paste results in a place holder only in the message
If you double click on the lost image you will see:
mailbox:///C%7C/WINDOWS/APPLICATION%20DATA/Thunderbird/Profiles...etc..etc
If you edit the location as follows the image is found
mailbox:///c|/WINDOWS/APPLICATIONS...ETC...ETC
"%7C" SHOULD BE "|"
Image sources lost in "insert HTML" edit window (It could be many)
Lets say you have a number of images inserted into a message, and you want to
edit the
HTML directly and not with an individual element selection.
No problem just edit | select all | insert HTML (this calls up the edit window
with the whole
message displayed) This is what we see here:
src="mailbox:///C%7C/WINDOWS/APPLICATION..etc...etc...net/Inbox?number=76365765(escaped
reference)part=1.2(escaped reference)filename=moz-screenshot-7.jpg"
This should be:
src="mailbox:///c|/windows/application................................................................765(ampersand
char)part=1.2(ampersand char)filename=etc
in addition to the "%7c" any instance of '&' is replaced with the escaped amp
it almost looks like we are over-escaping the mailbox url. i.e. it is escaped
and we escape it again. 

This came from JoeS on the forums:
http://forums.mozillazine.org/viewtopic.php?p=248510#248510
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.6beta
I think this happens because of the way drag and drop works in editor. Editor
ends up storing the URL as an HTML Attribute and I think all HTML Attributes
have to be escaped so it escapes our already escaped mailbox url. Then it tries
to create a new URI for the img src attribute, so it gets the attribute string,
converts it to a nsIURI and trys to load it. Somewhere along the way we need to
recongize that the source string is escaped and to unescape it. 

Blocks: 240183
*** Bug 208074 has been marked as a duplicate of this bug. ***
To clarify the original report: the image that gets selected and copied is not 
in the *compose* window at select/copy time, but in a message window opened on a 
Sent or Draft or received message.  Copying the image directly from the compose 
window leaves its 'src' attribute pointing to the original source.
Blocks: 247817
No longer blocks: 247817
*** Bug 247817 has been marked as a duplicate of this bug. ***
*** Bug 261620 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
What about copy-and-paste of an image that's in an IMAP folder? Its URL looks
like
imap://<username>@<host>:<port>/fetch%3EUID%3E/Trash%3E2076?part=1.2&type=image/jpeg&filename=DSC00025.jpg

I can't see anything incorrectly escaped.

Also, the image is visible in the compose window, it's just when the email is
sent that the image disappears.
*** Bug 321203 has been marked as a duplicate of this bug. ***
Bug 307023 and bug 351109 are about some very similar problems.
Blocks: 307023, 351109
*** Bug 350783 has been marked as a duplicate of this bug. ***
In the meantime the bug is fixed, you can find a workaround in my extension QuoteAndComposeManager, here: https://nic-nac-project.org/~kaosmos/realborders-en.html
See also https://bugzilla.mozilla.org/show_bug.cgi?id=380372 for another bug related to inline images paths.
This condition exist in current trunk
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008032702 Thunderbird/3.0a1pre ID:2008032702
Flags: wanted-thunderbird3.0a1?
Moving from wanted‑thunderbird3.0a1? flag to wanted‑thunderbird3.0a2? flag since code for Thunderbird 3 Alpha 1 has been frozen.
Flags: wanted-thunderbird3.0a1? → wanted-thunderbird3.0a2?
I don't think this will make it to a2 given the absence of a patch at this stage.  
Assignee: mscott → nobody
Status: ASSIGNED → NEW
Flags: wanted-thunderbird3?
Flags: wanted-thunderbird3.0a2?
Flags: wanted-thunderbird3.0a2-
QA Contact: esther → composition
Product: Core → MailNews Core
taking for investigation
Assignee: nobody → dbienvenu
Flags: wanted-thunderbird3?
Target Milestone: mozilla1.6beta → ---
Attached patch proposed fix (obsolete) — Splinter Review
this fixes the case described in the bug, and is highly unlikely to cause any regressions...
Attachment #563081 - Flags: review?(neil)
Attached patch alternative fixSplinter Review
per wikipedia, the | is obsolete for file urls on windows. http://en.wikipedia.org/wiki/File_URI_scheme#Windows_2

Not that that's definitive, but it's encouraging.
Attachment #563251 - Flags: review?(neil)
Comment on attachment 563251 [details] [diff] [review]
alternative fix

The | doesn't serialise correctly in other cases either, so I prefer this too.

In fact I'll file a bug on dropping support for | altogether.
Attachment #563251 - Flags: review?(neil) → review+
Comment on attachment 563081 [details] [diff] [review]
proposed fix

obsoleting in favor of other approach/patch.
Attachment #563081 - Attachment is obsolete: true
Attachment #563081 - Flags: review?(neil)
http://hg.mozilla.org/comm-central/rev/d55249b452bd
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 10.0
Tested with Mozilla/5.0 (Windows NT 5.0; rv:10.0a1) Gecko/20110930 Thunderbird/10.0a1 ID:20110930055354
Thanks David
Status: RESOLVED → VERIFIED
Verifying that this also fixes dup bug 647825 and bug 647827 and probably others.
It would be nice to at least get it into aurora.
Comment on attachment 563251 [details] [diff] [review]
alternative fix

Joe, thx very much for testing this. I agree that it would be good to get this into Aurora.
Attachment #563251 - Flags: approval-comm-aurora?
Not tracking: the fix is already here.
Comment on attachment 563251 [details] [diff] [review]
alternative fix

I think pushing this forward to aurora is fine. Not to beta as I want to allow time to ensure there's no subtle side-effects of this change.
Attachment #563251 - Flags: approval-comm-aurora? → approval-comm-aurora+
You need to log in before you can comment on or make changes to this bug.