39122 - [IME] Committing Japanese character will lose it's style in Composer

Status: RESOLVED WORKSFORME

(Core :: DOM: Editor, defect, P2)

Description

[Teruko Kobayashi]

When you change the style, like Bold, Underline, or Italic, and typing Japanese 
characters, the style of the character will lose at committing the characters.

Steps of reproduce
1. Open Composer
2. Select menu Format|Text style->Italic
3. Turn on IME to start typing Japanese characters
   Before you hit the enter to commit, the Japanese characters are displayed as 
Italic.
4. Hit Enter to commit

Notice that the Japanese characters are not Italic.   

The same thing happens if you change the style to Underline and Bold.
This does not happen on Windows and Mac.  

Tested 2000-05-12-08 Linux build.

Comment 1

[Hidetoshi Tajima]

Can we italize japanese text on X?

Comment 2

[Frank Tang]

teruko said "Before you hit the enter to commit, the Japanese characters are 
displayed as Italic." . Is this Italic handle by the over-the-spot IME, or 
handle by the layout. If we have an HTML page which have <I> Japanaese text 
</I>, will it display correctly on Linux ? If not, then it is an GFX issue. 

erik- can you take a look at this first. Thanks.

Comment 3

[Erik van der Poel]

*** This bug has been marked as a duplicate of 15611 ***

Comment 4

[Teruko Kobayashi]

I do not think this is dup of 15611.  15611 is about that it is hard to see Bold 
or Italic on Linux.   This problem is that after I commit the JA characters, 
style will loose even the style is underline. 

I realized the Bold and Italic Japanese is displayed fine in Redhat 6.2 
Japanese.  However, in Redhad 6.2 US + Japanese locale, it is hard to see.-bug 
15611.

In both, redhat 6.2 Japanese and Redhad 6.2 US + Japanese locale,
before committing the JA characters, the style is displayed fine.  However, 
after you commit the Ja characters, the style will lose.

Steps of reproduce
1. Open Composer
2. Select menu Format|Text style->Underline
3. Turn on IME to start typing Japanese characters
   Before you hit the enter to commit, the Japanese characters are displayed as 
Underlined.
4. Hit Enter to commit
Notice that the Japanese characters are not underline.   

If you change the style after you commit, the style of the Ja characters are 
displayed correctly.

Steps of reproduce
1. Open Composer
2. Turn on IME to start typing Japanese characters and hit enter to commit
3. Select the characters you typed in step #2
4. Select menu Format|Text style ->Underline
Notice that the Japanese characters are underlined.   
This works fine.

Comment 5

[Erik van der Poel]

Teruko, thanks for explaining the underline problem. This sounds like a problem
with IME and style after committing. Frank, please assign to whoever is doing
IME these days. Thanks.

Comment 6

[Hidetoshi Tajima]

Underline attribute for composed text(before commit) is explicitly set by
XIM. For committed text, XIM does not set any attribute(bold,italic,underline).
It could cause the problem, but I wonder if it's only with XIM.

Comment 7

[Frank Tang]

This is strange. If the problem is in the IME XP code, then win/mac should have 
the same problem. The problem is AFTER the ime commit so it probably are not 
problem w/ over-the-spot. Mark M17

Comment 8

[Hidetoshi Tajima]

cced to m_kato san. Kato-san, are you seeing this on windows?

Comment 9

[Hidetoshi Tajima]

See also, 18601. Similar problem was there on Windows, but has been fixed
recently.

Comment 10

[Frank Tang]

shanjian, can you take a look at this ?

Comment 11

[Teruko Kobayashi]

Per 8/1 I18n bug review meeting, QA needs to retest this.

Comment 12

[Shanjian Li]

The same problem on windows has been fixed. This is not a
cross platform issue. Reassign to tajima.
Tajima San, I could not work on Linux problem at least within 2 wks.
Please take a look at the problem. If you believe my involvement is
necessary, let me know and I will see what I can do.

Comment 13

[Teruko Kobayashi]

I tested this in 2000-08-14-12 Linux build.  This still happens.

It is difficult to see the bug if you use Bold, Italic, and Underline.
It is easy to see this problem if you use Strikethrough, Superscript, and 
Subscript. 

Steps of reproduce
1. Open Composer
2. Select menu Format|Text style->Strikethrough
3. Turn on IME to start typing Japanese characters
   Before you hit the enter to commit, the Japanese characters are displayed 
with Strikethrough.
4. Hit Enter to commit

Notice that the Japanese characters are not Strikethrough.   

The same thing happens if you change the style to Superscript, and 
Subscript.

Comment 14

[Frank Tang]

nsbeta3+ per i18n bug meeting.

Comment 15

[Masaki Katakai]

Shanjian, could you explain how you fixed on Windows?

I don't have Windows build environment so I can not debug on
Windows, but I believe this problem happens on *all* platform.
Please try the following operation on Windows,
  1) start composer
  2) turn conversion on
  3) click [U] to set underline style
  4) type japanese (do not commit)
  5) type ESC key
     ESC will work for deleting all composing characters.
     And you can see [U] becomes inactive, which is the
     same problem with Linux.

In 5), NS_TEXT_EVENT with theText = null is sent to HTML editor and
it will reset the style, I think. That's problem and you now understand this
problem happens on *all* platform.

So I'd like to ask Editor folks to evaluate first,
problem is,

   HTMLEditor should not reset the style when
   NS_TEXT_EVENT with theText = null

Comment 16

[Shanjian Li]

katakai, your test case is different from the original one in this 
bug report. The problem in your test case does exist on windows, but 
it might be a different problem. The fix of the original problem on 
windows is in bug 31334. I am not the one wrote the fix. In my understanding,
the author is associate font style info store in logfont with font weight.
There might be a (better) cross platform fix. I hope I can spend some time 
next week if my environment is ready. 

Comment 17

[Frank Tang]

jfrancis- could you respond to  Masaki Katakai 2000-08-18 02:14 comemnt?

Comment 18

[Frank Tang]

mark it as P2.

Comment 19

[Frank Tang]

I can reproduce the same thing on Mac by the procedure masaki describe. 
The fix must be put into the editor instead in the widget code. However, 
jfrancis is on vacation now. so it will be hard...

Comment 20

[Frank Tang]

reassign to shanjian to work on. 
I believe what happen is when we send the null text event, the typing rule code 
treat it as deleting the last character and therefore remove the node. 

Comment 21

[Shanjian Li]

Some progress:

In nsHTMLEditor.cpp, there is a member called mTypeInState. When user set the style, it will be remembered there. 
When a new text node is created, all style information is stored there. mTypeInState will be reset. If a text 
node is deleted later because all its content has been removed, and mTypeInState has been reset as well, 
thus the style information can not be found anywhere.

A possible solution is to reestablish mTypeInState when a text node with style information has been deleted.

Comment 22

[Frank Tang]

shanjian- I think the reason it behave like that is because jfrancis want to 
remove the style info if user do the following;
1. click <B>
2. type 'a'
3. hit [delect]
4. type 'a' again

in 2, it should show in bold. In 4, I think it is design to show in normal. 
However, I am not sure that is even the desire behavior for English user.
kin- what is your opinion ?

Comment 23

[kinmoz]

Frank is correct, this is intended behavior.

Comment 24

[Frank Tang]

I am thinking of cutting this one to nsbeta3-
User can still work around by select the text and choose style again. 
tajima, shanjian, ji, teruko what are your opinion ?

Comment 25

[Teruko Kobayashi]

As long as the user can select character and change it's style after character 
is committed, I think this is ok to nsbeta3-.  I tested this in 9-07 Linux 
build.
I can select character and change it's style.  However, my concern is that this 
function is not consistant in all platforms.

Comment 26

[Shanjian Li]

I have no objection to cut this one to nsbeta3-. 

Comment 27

[Frank Tang]

Let's cut this.

Comment 28

[Joe Francis]

I'm back from my vacation. Frank and Kin are correct about the intent of the 
editor behavior.  

I haven't looked back at this code yet, but I beleive we can reinstate the type-
in-state when we receive an ime event that has no text.  Conceptually it's easy.  
The code may make it harder; but it shouldn't be too bad.

I do agree that this case is nsbeta3-.  In fact, the user should see from the 
toolbar feedback that they have lost their style - they can even select it again 
then before they start typing.

reassigning to me.

Comment 29

[Joe Francis]

accepting bug

Comment 30

[kinmoz]

Setting to Future as per [e-mail].

Comment 31

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 32

[rubydoo123]

removing myself from the cc list

Comment 33

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I cannot reproduce this bug with Thunderbird's composer.

I guess that this was a bug of handling StyleCache in CompositionTransaction or EditorBase::InsertTextIntoTextNodeImpl(). So, moving the component to Editor.