HTML bugmail doesn't contain character encoding metadata

RESOLVED WORKSFORME

Status

()

Bugzilla
Email Notifications
RESOLVED WORKSFORME
6 years ago
6 years ago

People

(Reporter: Tom Duffy, Unassigned)

Tracking

Details

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20100101 Firefox/7.0
Build ID: 20110922153450

Steps to reproduce:

In BZ 4.2, email generated is now in HTML format, which is great, but there is no html character encoding specification.
For BZ installations that are UTF-8, bugmail should always be UTF-8.
Currently it is unspecified, so depends on the customers email client software to parse and auto-detect the character encoding.


Actual results:

No character encoding specified.


Expected results:

Something like
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
at the top of the message.
Possibly in the <head> tag of the html data.
template/en/default/email/bugmail.html.tmpl

I'm not sure how to get the "UTF-8" flag from the core parameters, otherwise I'd propose a patch straight away.  (Will work on this though).
For non-UTF-8 installations, leaving this unspecified is probably OK.

Comment 1

6 years ago
The HTML bugmails have:

Content-Type: text/html; charset="UTF-8"

This is only set for installations which use UTF8, as you said in your comment. Make sure you have this parameter turned on. Also, do you use JobQueue? If yes, reopen this bug as you may be hit by bug 723944 comment 21. Else something is probably wrong with your installation.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME

Comment 2

6 years ago
To be clear: Content-Type: text/html; charset="UTF-8" is a header, and I don't think <meta> is necessary as your email client is supposed to parse headers to get the character encoding.
(Reporter)

Comment 3

6 years ago
Thanks, the issue is when the email contents are copy/pasted to a browser, at which point the email header is forgotten, and the html has to stand on its own.

Probably not a common use scenario.
You need to log in before you can comment on or make changes to this bug.