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)
Tracking
(thunderbird8-, thunderbird9- fixed)
VERIFIED
FIXED
Thunderbird 10.0
People
(Reporter: mscott, Assigned: Bienvenu)
References
Details
Attachments
(2 files, 1 obsolete file)
795 bytes,
text/plain
|
Details | |
501 bytes,
patch
|
neil
:
review+
standard8
:
approval-comm-aurora+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•21 years ago
|
||
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
Reporter | ||
Comment 2•21 years ago
|
||
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.
Comment 3•20 years ago
|
||
*** Bug 208074 has been marked as a duplicate of this bug. ***
Comment 4•20 years ago
|
||
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.
*** Bug 247817 has been marked as a duplicate of this bug. ***
Comment 6•20 years ago
|
||
Comment 7•20 years ago
|
||
*** Bug 261620 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: MailNews → Core
Comment 8•19 years ago
|
||
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.
Comment 9•19 years ago
|
||
*** Bug 321203 has been marked as a duplicate of this bug. ***
Comment 10•18 years ago
|
||
Bug 307023 and bug 351109 are about some very similar problems.
Comment 11•18 years ago
|
||
*** Bug 350783 has been marked as a duplicate of this bug. ***
Comment 12•16 years ago
|
||
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.
Comment 13•16 years ago
|
||
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?
Comment 14•16 years ago
|
||
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?
Comment 15•16 years ago
|
||
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
Updated•16 years ago
|
Product: Core → MailNews Core
Assignee | ||
Comment 18•13 years ago
|
||
taking for investigation
Assignee: nobody → dbienvenu
Flags: wanted-thunderbird3?
Target Milestone: mozilla1.6beta → ---
Assignee | ||
Comment 19•13 years ago
|
||
this fixes the case described in the bug, and is highly unlikely to cause any regressions...
Attachment #563081 -
Flags: review?(neil)
Assignee | ||
Comment 20•13 years ago
|
||
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 21•13 years ago
|
||
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+
Assignee | ||
Comment 22•13 years ago
|
||
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)
Assignee | ||
Comment 23•13 years ago
|
||
http://hg.mozilla.org/comm-central/rev/d55249b452bd
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 10.0
Comment 24•13 years ago
|
||
Tested with Mozilla/5.0 (Windows NT 5.0; rv:10.0a1) Gecko/20110930 Thunderbird/10.0a1 ID:20110930055354 Thanks David
Status: RESOLVED → VERIFIED
Comment 25•13 years ago
|
||
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.
tracking-thunderbird8:
--- → ?
tracking-thunderbird9:
--- → ?
Assignee | ||
Comment 26•13 years ago
|
||
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?
Comment 27•13 years ago
|
||
Not tracking: the fix is already here.
Comment 28•13 years ago
|
||
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+
Assignee | ||
Comment 29•13 years ago
|
||
transplanted to aurora http://hg.mozilla.org/releases/comm-aurora/rev/d68a4963ff1a
status-thunderbird9:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•