If I set Auto-Detect(Japanese), the font size in a Japanese web page act on x-western setting.

VERIFIED FIXED in M15

Status

()

Core
Internationalization
P3
normal
VERIFIED FIXED
18 years ago
13 years ago

People

(Reporter: Campanella, Assigned: Erik van der Poel)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+], URL)

(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.72 (Macintosh; I; PPC)
BuildID:    2000022414

The font size in a Japanese web page should act on ja setting.  But, when I set 
Auto-Detect(Japanese), the font size in the page at http://www.yahoo.co.jp/ and 
http://www.zdnet.co.jp/macwire/ act on x-western setting.

Reproducible: Always

Steps to Reproduce:
1. View>Character Coding>Auto-Detect(Japanese)
2. Go to a Japanese web page
3. Bring up Preference and click Font tab
4. Select "ja" in the "Fonts for" field
5. For example, select "16" for the Variable Width Font
6. Click OK to close prefs
7. The font size in the page did not change to 16 point
8. Bring up Preference and click Font tab again
9. Select "x-western" in the "Fonts for" field
10. For example, select "16" fot the Variable Width Font
11. Click OK to close prefs
12. The font size in the page changed to 16 point


Actual Results:  The font size in a Japanese web page is acting on x-western 
setting.

Expected Results:  The font size in a Japanese web page is acting on ja setting.

It seems that the same phenomenon occured in a Japanese web page without 
description of charset and with description of charset(x-sjis and Shift_JIS) in 
META tag.
I use MacOS-Japanese system 8.6 and it seems that M13 did not have this bug.

Comment 1

18 years ago
changing component to i18n.
Component: Browser-General → Internationalization

Comment 2

18 years ago
re-assign to i18n owner.
Assignee: cbegle → ftang
QA Contact: asadotzler → teruko

Comment 3

18 years ago
erik- is this also true on win ?
Assignee: ftang → erik
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

18 years ago
I heard about this bug in a message from Japan.
This problem also occurs on Windows - 3/10/2000 Win32 build.
When you turn off the Auto-Detect on Windows, no font
size changes for any Lang categories are relflected on HTML display 
but only in the Navigator location bar which reflects Western size.

Comment 5

18 years ago
per momoi's comment, change the platform form Mac to all
OS: Mac System 8.6 → All
Hardware: Macintosh → All
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M15

Comment 6

18 years ago
** Re-checked with 3/13/2000 Win32 B1 build **

This problem is much worse than initially reported. 
I wrote a follow-up to the original poster but let
me add some more facts.

The central fact seems to be that the monment you manually
set an encoding via the View | Character Coding menu,
you lose control of any font size chanegs for any language
pages with or without a meta tag until you reboot Mozilla.

Try any one of the following things, you will see this problem.

0. First set the font size of Western and Japanese serif to 24
   pxls. Then quit Mozilla and then restart Mozilla. (No
   auto-detection should be set at this point.)

Now any one of the following will reveal this problem.

1. Go to Netscape English Home Page. Confirm that it is in
   24 pxls. Now go to a page which requires you to change an 
   encoding. e.g. http://www.yahoo.co.jp/. Set encoding to
   Japanese (EUC-JP), display the page but this will be 
   not in 24 pxls but in the default size. Now come back to 
   English Home Page. It is not in 24 pxls any more! It is
   in default size. Now open the font pref and try the
   size changes for Western.  You'll see that no size change will 
   be effective.

2. Start Mozilla and go to Netscape Home Page. See that the
   page is in 24 pxls. Now choose Character Coding | Western,
   though this is redundant. The moment you do, the font size
   goes down to the default. Thereafter, no amount of attempt
   to change the font size will be effective until re-start.

I think it will be very easy to get into this condition.
Any manual encoding change seems to disable font size control
until the next session.

I would love to get confirmation that this problem occurs with
other people and it is not just my profile settings. Until then,
I feel obliged to nominate this for Beta 1 because this will
undermine our efforts to show off browser's HTML display.
Keywords: beta1

Comment 7

18 years ago
There are 2 problems reported in this bug:

1. The original poster reported that font size control for
   Japanese is not effective when auto-detection is on.
   Instead Western font control seems effective.

   But this is true only with pages with no meta tags. On pages
   with meta-tags like Netscape Japan Home page, you can
   control the font size with JPN font control settings under
   Japanese Auto-Detection setting.

2. Then while investigating this, I noticed that any time
   an encoding change is manually made (even with auto-detection on),
   thereafter, all font size control for any language seems to
   be disabled.

We could separate these 2 problems, or it could be that these 
problems are all related to some defect in our encoding menu 
or font mechanism. This is the reason why I decided to write about the
2nd problem in this report. If it turns out that these are not
part of the same problem, we can separate the 2. 

Even in that case, I think the problem #2 is still a beta 1 
candidate.

Comment 8

18 years ago
Is this a regression?
Since it was first reported on 3/2, I assume it has nothing to do with the
recent font pref changes which were only in the UI and did not include any
backend changes.

Comment 9

18 years ago
It may have something to do with the recent encoding
menu changes. While looking at this problem, I noticed
that the checkmark behvaior is not always reflective of
where the real encoding is. Also, when no auto-detction is
on, the initial state of encoding when Mozilla first comes
up seems to be a special state where font controls work
as intended. The problem seems to be that when this initial state
is somehow changed/reset by a manual menu action, something
to do with font control changes permanently during that session.

It probaly is not a font UI change-related regression but 
that change could have exposed a lurking problem.

Comment 10

18 years ago
I see that the porblem #2 existed with M14-rtm build also.
So this is not a regression from M14. The encoding change
alwasy seesm to reset the font to the default font size
and no further control of size is possible until the
restart. The lcoation bar, however, will reflect the font
size changes.

Comment 11

18 years ago
I tried steps 0&1 and 0&2 as described in momoi's comment from 2000-03-15 02:44.
I got the same results running a 2000031009 (3/10) build on US win95.

Comment 12

18 years ago
It seems to have some interaction with the character coding menu.
If you just type in the location bar "http://home.netscape.com/ja/",
this works fine and you see the page in 24pt.  or if you then click on a link
in that page.

Comment 13

18 years ago
I reenabled the old character coding menus by uncommenting out from my
  chrome/navigator/content/default/navigatorOverlay.xul

I changed this line:
  <!-- Deprecated BEGIN
to this:
  <!-- Deprecated BEGIN -->

and this line:
  END of Deprecated -->
to this:
  <!-- END of Deprecated -->

And if I use the old menus, steps 0&1 and 0&2 work fine.

Cata,
   Any ideas what the new character coding menu is doing that would cause this?

Comment 14

18 years ago
Momoi-san,
Did you notice if it is only ignoring the size?  Or is it ignoring the family
as well?  The US Netscape home page uses <font face>, so that's not a good test.

Comment 15

18 years ago
Investigating... But I need a clarification: is this problem with the AutoDetect 
menu or the Charset menu? Which menu did you uncomment?

Comment 16

18 years ago
See above comments.
This has nothing to do with autodetect.
I just selected either EUC-JP or Western, depending upon the 2 scenarios that
momoi described on 2000-03-15 02:44: (1) steps 0 & 1, or steps 0 & 2)

I documented in my earlier comment the 2 lines I changed which uncomments out
the entire list of menu entries that we had for the old charset coding menu.

Reassigned to cata for now.
Assignee: erik → cata
Status: ASSIGNED → NEW

Comment 17

18 years ago
Putting on PDT- radar for beta1.
Whiteboard: [PDT-]

Comment 18

18 years ago
Cata, What have you figured out so far?  Erik might be able to point you in
the right direction since he implemented the font pref backend work.

Momoi-san, How bad is this?
It seems to me that if you ever use the charset menu, then whatever
font prefs you have set (at least for size) is ignored until you relaunch.
Is that correct?

PDT team marked this PDT- until we have a better determination of the effect
and ramifications of this bug.  Let's figure this out ASAP.

Comment 19

18 years ago
Bob, that is right. More descriptively, the 2 problems are:

A. Use of a charset menu change of any kind leads to resetting of 
   size to the default (16 pxls) for ALL languages.
   If there is some consolation, it gets reset to the default size
   and this could alleviate the problem. But this is losing control
   of font size and most users will not know why the sudden change
   occurred.

B. The original problem reported by hub-san is also very bad.
   Typical JPN users will have set the Auto-Detection on.
   
   1. They set the font size to what they want, e.g. 12 pxls.
   2. Now they go surfing. They get to a site with a meta tag, font is
      in 12 pxls as desired.
   3. But the moment they go to a site without a meta tag, something gets
      reset and thereafter the size of the fonts becomes that set for 
      Western, not for Japanese!
   4. It gets worse. Now they go back to the site with a meta tag where 
      the JPN font control used to work. But they now see that the size
      has been reset to the default size for Western there also!
   5. Now in this state, the only way to change the font size for
      Japanese is by the Western category, until you restart.

Both the original bug report and my additional one seem to be due to
some sort of resetting of charset. In either case, you suddenly lose
control of font size and average users will never understand what
happened and why.

This is pretty bad user experience where it counts -- appearance and
presentation of web pages. 
Remember that this is not just an international problem, once a cetain
condition is met, the problem affects all language font settings.

Comment 20

18 years ago
It looks we have found the problem and we can fix it by changing a string
comparison to use strcasecmp.  Cata is pulling a branch tree and applying
the change now.  He'll update the bug before the 4pm PDT mtg today (3/16).

Comment 21

18 years ago
This patch fixes the problem for using the charset menu.

S:\mozilla\gfx\src>cvs diff -c *.cpp
Index: nsDeviceContext.cpp
===================================================================
RCS file: /cvsroot/mozilla/gfx/src/nsDeviceContext.cpp,v
retrieving revision 3.52
diff -c -r3.52 nsDeviceContext.cpp
*** nsDeviceContext.cpp 2000/02/05 03:32:53     3.52
--- nsDeviceContext.cpp 2000/03/17 00:35:20
***************
*** 687,693 ****

    LangGroupEntry* p = langGroups;
    while (p->mCharSet) {
!     if (aCharSet == p->mCharSet) {
        if (!p->mAtom) {
          p->mAtom = NS_NewAtom(p->mLangGroup);
          if (p->mAtom) {
--- 687,693 ----

    LangGroupEntry* p = langGroups;
    while (p->mCharSet) {
!     if (aCharSet.EqualsIgnoreCase(p->mCharSet)) {
        if (!p->mAtom) {
          p->mAtom = NS_NewAtom(p->mLangGroup);
          if (p->mAtom) {
Status: NEW → ASSIGNED

Comment 22

18 years ago
Now I am studying the other part of the original report: the AutoDetect case.

Comment 23

18 years ago
Ok. I guess that the problem for the second part of the bug (the autodetect 
case) resides in the fact that the font-sizing code is called before the 
autodetector has an answer for the charset.

But I am not very familiar with that code, I definitely need Erik's help. 
Reassigning.
Assignee: cata → erik
Status: ASSIGNED → NEW

Comment 24

18 years ago
PDT+
Whiteboard: [PDT-] → [PDT+]

Comment 25

18 years ago
This is marked PDT+ for the one line fix for case A as described in the
comment on 2000-03-15 23:30.

Need to determine if case B is a beta1 stopper.  There may be a workaround
that we are exploring.
(Assignee)

Comment 26

18 years ago
Frank, please let me know what you think about the following. Soon after the
creation of a document object, the presentation context's SetShell method is
called, passing the presentation shell as the argument. SetShell gets the
document from the shell, and maps the document's charset to the langgroup.

However, maybe in the auto-detect case, the charset is being changed in the
document *after* SetShell has been called. Perhaps the document's
SetDocumentCharacterSet method is called for that purpose. In that case, we
need some kind of "listener" (perhaps) that would notify the presentation
context (or presentation shell) when the charset is changed in the document.

What would be the preferred way for the document to notify the presentation
context of a charset change? Is a "listener" or "observer" the preferred
approach in Gecko?
Status: NEW → ASSIGNED

Comment 27

18 years ago
This bug really describes 2 bugs as described as case A and case B in the
2000-03-15 23:30 comment.

Although case A was the original bug, this has evolved into a resolution for
case B.  So I created a new bug 32206 for case A and will mark this one fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 28

18 years ago
cata, please make sure this fix goes into the trunk too.

Comment 29

18 years ago
Changed QA contact to amasri@netscape.com.
QA Contact: teruko → amasri

Comment 30

18 years ago
verified fixed with Netscape6 beta1 2000032306
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.