Closed Bug 685462 Opened 10 years ago Closed 10 years ago

blanks at the end of email-address in Settings prevents displaying of inline images

Categories

(Thunderbird :: General, defect)

6 Branch
x86
All
defect
Not set
major

Tracking

(thunderbird8-)

VERIFIED FIXED
Thunderbird 9.0
Tracking Status
thunderbird8 - ---

People

(Reporter: intendentedelleacque, Assigned: Bienvenu)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.2.21) Gecko/20110830 Firefox/3.6.21
Build ID: 20110830092825

Steps to reproduce:

- in Account settings, put a email-address with a blank at the end
- try to use a signature with images or insert an inline images


Actual results:

- the images are not displayed


Expected results:

- the images should be displayed

This bug is caused by a wrong "cid" in the images.

In the body of message the "cid" reports the final blank as "%20" or doesn't report it (I got both behaviour in different PC) while the attachment mantains the final blank in the Content-Id.
In both cases the images will not be displayed.

Probably the best way to fix it, is to strip all spaces in generating the "Content-Id".
Severity: normal → major
OS: Windows XP → All
Version: unspecified → 6
Tested with Mozilla/5.0 (Windows NT 5.0; rv:9.0a1) Gecko/20110906 Thunderbird/9.0a1 ID:20110906030027
The worst aspect of this is that it fails silently, appears to send properly, but no viewable image in the message.
Status: UNCONFIRMED → NEW
Ever confirmed: true
In my opinion, user shouldn't be allowed to create or modify an account, setting an email address with blanks at the end, but this is a different issue.
Should I open a new bug for that?
Well, preventing the trailing blank would solve the problem here, before it could manifest itself. I could see that happening with an errant copy/paste that picked up a trailing space.
Let's get Mark's opinion.
(In reply to Joe Sabash from comment #3)
> Well, preventing the trailing blank would solve the problem here

Just partially, because this will not fix this bug for users that have email-addresses with blanks at the end already and don't realize ti.
Yeah, I know where this code is...
Attached patch proposed fixSplinter Review
Assignee: nobody → dbienvenu
Attachment #560068 - Flags: review?(neil)
Can we be sure that the email won't contain other "confusing" characters?
(In reply to neil@parkwaycc.co.uk from comment #7)
> Can we be sure that the email won't contain other "confusing" characters?

Other potentially escapable chars are already in e-mail addresses and don't seem to cause a problem, e.g., @ and '.', so I don't know of other chars that would cause a problem.
Comment on attachment 560068 [details] [diff] [review]
proposed fix

I see now, only the domain is used, which shouldn't be a problem.

>+      email.Trim("\b\t\r\n ");
Any reason not to use StripWhitespace*? r=me with that fixed.

*Not including the bug that the external string API appears to have whereby StripWhitespace doesn't strip \b. I guess I ought to file it in Bugzilla.
Attachment #560068 - Flags: review?(neil) → review+
Please consider this for Aurora and Beta as well.
(although it's not a regression, seems like it could go as a tag-along for other requests I see for Beta approval)
Too late for TB Beta 3
But if there is uncertainty about using StripWhitespace (bug 686775) why not just use the originally proposed Trim and be done with this bug.
fixed on trunk - http://hg.mozilla.org/comm-central/rev/fbb0e1b6ad17
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
I used StripWhitespace per Neil - I believe that's the real world problem.
It looks like the blank on the end of the email address has no actual effect on sending. So I don't think an additional bug will be necessary.
Thanks David, for the fix. And thanks to Paolo Kaosmos for filing the bug and providing some great Tb extensions.
https://nic-nac-project.org/~kaosmos/index-en.html
To be honest, if were not for your EditHtml extension, I might have been gone from this arena years ago.
Verified fixed:
Mozilla/5.0 (Windows NT 5.0; rv:9.0a1) Gecko/20110920 Thunderbird/9.0a1 ID:20110920030153
Status: RESOLVED → VERIFIED
Target Milestone: --- → Thunderbird 9.0
Not tracking going forward. This isn't a frequent scenario as far as we know and has an easy work around.
You need to log in before you can comment on or make changes to this bug.