Closed
Bug 211800
Opened 22 years ago
Closed 20 years ago
meta charset sniffing doesn't work when content-type spec'd in HTML mail
Categories
(MailNews Core :: Internationalization, defect)
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: doron, Assigned: smontagu)
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Incoming mail item, with "Content-Type: text/html" and
"Content-Transfer-Encoding: quoted-printable".
The HTML includes a meta-tag:
META HTTP-EQUIV="Content-Type" content="text/html; charset=windows-1255"
When opening this mail, the rendering defaults to Cyrillic, rather
than detecting the correct charset (Hebrew).
Reproducible: Always
Steps to Reproduce:
1. Open an e-mail as described above
2.
3.
Actual Results:
Encoding set to Cyrillic (Win 1251)
Expected Results:
Encoding should be set to Hebrew (Win 1255)
| Reporter | ||
Comment 1•22 years ago
|
||
Comment 2•22 years ago
|
||
*** This bug has been marked as a duplicate of 103960 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
| Reporter | ||
Comment 3•22 years ago
|
||
Not sure I can see how it is a dupe - looks like
a different req to me, but I guess you know what
you're doing.
| Assignee | ||
Comment 4•22 years ago
|
||
No, from the detailed description I don't think this is a dupe of 103960, though
the summary makes it seem like it is. OTOH, it looks familiar, and may be a dupe
of something else. Reopening for now and tweaking summary.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: Encoding auto-detection doesn't work when content-type spec'd in HTML mail → meta charset sniffing doesn't work when content-type spec'd in HTML mail
Doron, i opened your attachment and it defaults to win-1255, hebrew with
Auto-detect set to off or to universal (using the same build)
| Reporter | ||
Comment 6•22 years ago
|
||
Marina,
I get different behaviour. When auto-detect set to "universal"
(the default setting), it persistently defaults to win-1251
(Cyrillic). When I set auto-detect to "off", it detects Hebrew
but ISO-8859-I - which makes it readable, but it still is not
the encoding specified in the HTML.
Assuming this is the same build as yours, this is weird.
Comment 7•22 years ago
|
||
This is the expected behavior with the default Mozilla settings and current
auto-detect mechanism:
1. Mozilla doesn't auto-detect Hebrew encoding. See Bug 86999.
2. When no encoding is specified (and since Auto-Detect is Off), Mozilla
defaults to what is configured under Edit/Preferences/Mail&News/Message
Display/Character Coding. Change that to Hebrew/ISO-8859-8-I or to
Hebrew/windows-1255 and you won't see this limitation anymore.
I believe that this bug should be marked INVALID, as it works as expected under
the default settings and current limitations. Simon?
Prog.
| Reporter | ||
Comment 8•22 years ago
|
||
Prog,
Does this really have to do with auto-detection?
Note that the mail I'm refering to has explicit
charset specified, only it's in an HTML meta tag.
Would this count as auto-detection?
Doron
Comment 9•22 years ago
|
||
> Does this really have to do with auto-detection?
I believe that for parts that don't have explicit charset, it does.
> Note that the mail I'm refering to has explicit
> charset specified, only it's in an HTML meta tag.
And Mozilla does follow that, as evident in the the attached screenshot.
It is true, however, that for some reason the very first line uses the default
encoding (see blue rectangle in the screenshot). I'd be happy for someone more
knowledgeable than myself to check it. This could turn out to be a bug, though
a very minor one.
Prog.
| Reporter | ||
Comment 10•22 years ago
|
||
>> Note that the mail I'm refering to has explicit
>> charset specified, only it's in an HTML meta tag.
> And Mozilla does follow that, as evident in the the attached screenshot.
Right. It did not for me though. See original bug description.
Updated•21 years ago
|
Product: MailNews → Core
Comment 11•20 years ago
|
||
This is an automated message, with ID "auto-resolve01".
This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.
While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.
If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.
The latest beta releases can be obtained from:
Firefox: http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey: http://www.mozilla.org/projects/seamonkey/
Comment 12•20 years ago
|
||
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 20 years ago
Resolution: --- → EXPIRED
Updated•17 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•