128368 - when I read certain (non-ASCII) emails, a little window pops up

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[(not reading, please use [e-mail] instead)]

when I read certain (non-ASCII) emails, a little window pops up

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: sample message

Comment 2

[Scott MacGregor]

does the window pop up and then go away real fast? I've been seeing that in the
browser for several days. Not sure if it's related.

Comment 3

[nhottanscp]

The atached message seem be in all ASCII characters.

Comment 4

[(not reading, please use [e-mail] instead)]

mscott, yes, that is what I'm seeing.

Comment 5

[Frank Tang]

the small window could be the font download window, it pop up because it think
you need a chinese font, it disappear because the javascript figure out it is on
win2k or winxp which the font package cannot be used. 
reassign to ftang

Comment 6

[(not reading, please use [e-mail] instead)]

I've been seeing this in browser windows, too.

Comment 7

[Frank Tang]

assign

Comment 8

[Scott MacGregor]

I just realized this bug wasn't nominated for nsbeta1. This is definetly an
nsbeta1 stopper. 

Here's an easy testing scenrio I use to see this that involves non-ascii
messages all the time (I do see the popup with ascii messages too, just not as
often).

My win2k machine has japanese and chinese fonts installed on it. 

I startup the app and click on a message out of the I18N smoketest mail folder
that contains japanese characters. I always see the popup come up then go away.
Subsequent messages don't show the popup during that session. But if I quit and
come back, I see it again. 

Comment 9

[Katsuhiko Momoi]

> Here's an easy testing scenrio I use to see this that involves non-ascii
> messages all the time (I do see the popup with ascii messages too, just not as
> often).

The font downloading msg is based on MIME-charset rather than
on whether or not specific lang characters are needed. So you will
see the font download pop up even if the message contained only
ASCII characters. The test msg posted by sspitzer has the charset
value equal to iso-2022-jp.

I had thought that our spec calls for using the ASCII charset name 
if it contained only ASCII characters only even if the chosen 
encoding is one of CJK.
But apparently this is not the case at present. 

Comment 10

[Jon Granrose]

is there a different bug filed on the fact that if you click on the link
provided in that window to download the font it comes up as "not found"?  I get
about 5 of these a day and since I'm on win98 they don't disappear automatically
and it's incredibly annoying.

Comment 11

[esther]

reassigning qa to ji since this mostly involves non-ascii emails

Comment 12

[Frank Tang]

mscott: how important you think to fix this bug. Basically, when we hit a
situration that we try to display chinese/japanese/korean but we don't have a
font in the system, we try to show a dialog box to ask for download a font for
it. This currently only work under window and the download package only work for
Win9x and WinNT. Therefore, we close the dialogbox immediately if we detect it
is a winXP or win2K so we won't confuse the user. Do you think it is acceptable,
that we leave the dialog box open for a while and show something like "The html
you try to view contains foreign languages, you need to install a font for that
language to see it" and close 3-5 second later ?

This could be a server side fix.

Comment 13

[David :Bienvenu]

I know you're not asking me, but I think it's very important that this bug gets
fixed - it happens to me 5 or 10 times a day and is very annoying, and I think
scary for people who don't know what's going on. Forgive my ignorance, but can't
we check the OS before putting up the dialog?

Comment 14

[Scott MacGregor]

Frank, to answer your question, I think this is pretty important for beta.
What's strange is that we see this for messages which don't appear to have any
I18N characters in them either. Although most of the time it is with I18n
characters. The dialog popups up then gets torn down. 

I don't think filling the popup with text saying "you don't have this font" is
the way we really want to go. Any way you can check the OS for the platform
before you bring up the popup and only show the popup if it's going to do something?


On a side note:

Do we want to show a font download window when the user clicks on a message
containing character sets you don't have? This may be a browser only feature we
want. It seems weird to have a popup about fonts come up just by clicking on a
message. I wonder if we should talk to the UI group about the expected behavior
in mail for this scenario on platforms where the popup 

Comment 15

[Katsuhiko Momoi]

I think we should fix one of the causes for this porblem, i.e.
Mozila sends out messages marked as ISO-20222-JP, GB2312, EUC-JR, etc.
even when the message contains n characters outside of ASCII
range.
Our original spec called for such msgs to be labeled as US-ASCII or
ASCII. People use their defautl encoding setting whether they write
in Chinese, Japanese, Korean or ASCII(English). This could alleviate 
the current problem as (if I am not mistaken) we are depending on
MIME charset to pop up this dialog.

Comment 16

[Frank Tang]

*** Bug 139248 has been marked as a duplicate of this bug. ***

Comment 17

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 18

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 19

[nhottanscp]

This is fixed in 1.0.1 by bug 161159.