Masaki Katakai Reporter
	Description • 25 years ago

I found a problem that nsTextEditRules::WillInsertText() does not
handle the case text=null for kInsertTextIME action. The action is expected
to clear a composition string of IME when text is null.

Due to this problem, in Text edit mode, there is a problem that a
composition character can not be cleared, erased by Del key on Windows.
When two characters are being composed, the first Del key can erase a character,
but the next Del key can't erase and clear the remaining character.
I'm seeing this problem on M13 release on Windows.

For HTML edit mode, nsHTMLEditRules::WillInsertText() handles properly,

  nsHTMLEditRules::WillInsertText()
    if(aAction == kInsertTextIME)
    {
       // special case for IME. We need this to :
       // a) handle null strings, which are meaningful for IME
       // b) prevent the string from being broken into substrings,
       //    which can happen in non-IME processing below.
       // I should probably convert runs of spaces and tabs here as well
       res = DoTextInsertion(aSelection, &bCancel, &theString, typeInState);
    }

The same codes are needed in nsTextEditRules::WillInsertText() for
IME support.

*** nsTextEditRules.h	Fri Jan 28 18:24:36 2000
--- nsTextEditRules.h.new	Fri Jan 28 17:51:12 2000
***************
*** 87,93 ****
  protected:
  
    // nsTextEditRules implementation methods
!   nsresult WillInsertText(nsIDOMSelection  *aSelection, 
                              PRBool         *aCancel,
                              PRBool         *aHandled,
                              const nsString *inString,
--- 87,94 ----
  protected:
  
    // nsTextEditRules implementation methods
!   nsresult WillInsertText(PRInt32          aAction,
! 			    nsIDOMSelection  *aSelection, 
                              PRBool         *aCancel,
                              PRBool         *aHandled,
                              const nsString *inString,
*** nsTextEditRules.cpp	Fri Jan 28 17:33:32 2000
--- nsTextEditRules.cpp.new	Fri Jan 28 18:15:14 2000
***************
*** 203,209 ****
        return WillInsertBreak(aSelection, aCancel, aHandled);
      case kInsertText:
      case kInsertTextIME:
!       return WillInsertText(aSelection, 
                              aCancel,
                              aHandled, 
                              info->inString,
--- 203,210 ----
        return WillInsertBreak(aSelection, aCancel, aHandled);
      case kInsertText:
      case kInsertTextIME:
!       return WillInsertText(info->action,
! 			    aSelection, 
                              aCancel,
                              aHandled, 
                              info->inString,
***************
*** 496,502 ****
  }
  
  nsresult
! nsTextEditRules::WillInsertText(nsIDOMSelection *aSelection, 
                                  PRBool          *aCancel, 
                                  PRBool          *aHandled,
                                  const nsString  *aInString,
--- 497,504 ----
  }
  
  nsresult
! nsTextEditRules::WillInsertText(PRInt32          aAction,
! 				nsIDOMSelection *aSelection, 
                                  PRBool          *aCancel, 
                                  PRBool          *aHandled,
                                  const nsString  *aInString,
***************
*** 504,513 ****
                                  TypeInState      aTypeInState,
                                  PRInt32          aMaxLength)
  {
!   if (!aSelection || !aCancel || !aHandled || !aInString || !aOutString) 
      {return NS_ERROR_NULL_POINTER;}
    CANCEL_OPERATION_IF_READONLY_OR_DISABLED
  
    nsresult res;
  
    // initialize out params
--- 506,523 ----
                                  TypeInState      aTypeInState,
                                  PRInt32          aMaxLength)
  {
!   if (!aSelection || !aCancel || !aHandled)
      {return NS_ERROR_NULL_POINTER;}
    CANCEL_OPERATION_IF_READONLY_OR_DISABLED
  
+   // from nsHTMLTextEditRules
+   if (aInString->IsEmpty() && (aAction != kInsertTextIME))
+   {
+     *aCancel = PR_TRUE;
+     *aHandled = PR_FALSE;
+     return NS_OK;
+   }
+ 
    nsresult res;
  
    // initialize out params
***************
*** 558,563 ****
--- 568,581 ----
    char newlineChar[] = {'\n',0};
    nsString theString(*aOutString);  // copy instring for now
  
+   // kInsertTextIME needs to support null text insersion
+   // it clears the compositon string
+   if (aAction == kInsertTextIME && theString.Length() == 0)
+   {
+       res = DoTextInsertion(aSelection, &bCancel, &theString, aTypeInState);
+       return res;
+   }
+ 
    while (theString.Length())
    {
      nsString partialString;

	Katsuhiko Momoi
	Comment 1 • 25 years ago

Changing QA contact to teruko. Also CC'ing ji and myself as the
problem is reported for plain text edit.

	Frank Tang
	Comment 2 • 25 years ago

reassign to jfrancis-
joe this is your code. Feel the power of the Mozilla Japanese hacker group :) 
Is this a good fix ? Please communicate with katakai-san directly. I am not 
familar with this part of code.

	rubydoo123
	Comment 3 • 25 years ago

Joe, setting this to m14

	Joe Francis Assignee
	Comment 4 • 25 years ago

Thanks Katakai!   accepting bug...

	rubydoo123
	Comment 5 • 25 years ago

m15

	Joe Francis Assignee
	Comment 6 • 25 years ago

fixed.  Big thanks to Katakai for finding, investigating, and fixing this.  
Apologies for the delay in checkin.

QA: to verify, check to see if hitting escape in a plaintext compose window 
actually clears the ime string.

	Katsuhiko Momoi
	Comment 7 • 25 years ago

Joe, I have a question about this. 
I thought the original problem reported is that when you 
have more than 2 Japanese characters under innput mode in Plain
Text Edit, e.g.

XY

and the cursor at the point after Y, the 1st Backspace key action 
erases Y but the 2nd Backspace action does not earse X. Actually 
you can erase it by doing another Backspace. This problem always
occurs for the 1st character entered. For exmple, if you have 4
characters under input mode,

WXYZ

you can delete Z, Y, X by one Backspace key action but the last 
character requires two. This problem is not observed in HTML
composer.

It is also true that the escape key does not clear the strings
under input mode in Plain Text editor.

Are these two problems solved by your fix?

	Joe Francis Assignee
	Comment 8 • 25 years ago

i was only thinking about the problem with esc.  That is fixed.  I don't think 
the checkin should have affected the other problem, but when I try it, it is also 
fixed.  Perhaps this was fixed by an earlier effort.

	Katsuhiko Momoi
	Comment 9 • 25 years ago

Joe, the Backspace problem I mentioned above occurs with
the 2/6/2000 Win32 build but not with the 2/7/2000 Win32 build.
Perhaps Katakai-san diffs are meant to fix both of
these problems.

	Teruko Kobayashi
	Comment 10 • 25 years ago

I verified this in 2000030109 Win32 build.