Closed Bug 23558 Opened 25 years ago Closed 25 years ago

[IME] ESC key will move caret to the beginning of 1st line

Categories

(Core :: Internationalization, defect, P3)

Product:
Core
Component:
Internationalization
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: teruko, Assigned: mozeditor)

References

Details

(Keywords: inputmethod, Whiteboard: [PDT+] fix in hand, reviewed by mjudge) 

You can delete Japanese characters before commit by using ESC key.  In composer,
you can delete them, but the caret will move the beginning of the 1st line.
This is similar bug as 19130.

Steps of reproduce
1. Open Composer
2. Turn on IME
3. Type Japanese characters and commit, them hit enter to go to the next line
4. Type Japanese characters (at this time, do not hit enter to commit
5. Hit ESC key to delete whole characters

Notice that the characters were deleted, but the carret move to at the beginning
of the 1st line.

Tested 2000011008 Win32 under Win95J, Winnt4.0J, and Winnt 4.0US + Japanese IME.
Status: NEW → ASSIGNED
Target Milestone: M13
more info. This only happen when the IME typing position is in the beginning of
a line. If the cursor is origional place not in the beginning of a line, it
won't move it to the beginning of the FIRST line.
I tested this in 2000010516 Win32 build under Winnt 4.0J.
The behavior is that the caret is gone after the step #5(Hit ESC key).  So, I have to use the mouse to place the caret by
myself.

I tried to install 2000010709 and 2000010713 Win32 build, but I could not install them.
Target Milestone: M13 → M14
Move to M14
joe- can you take a look at this ? It seems's related to typing rule. not wure. 
Reassign back to me if you cannot figure out.
Assignee: ftang → jfrancis
Status: ASSIGNED → NEW
ok, but i may need help if this doesnt happen on the mac.
Status: NEW → ASSIGNED
Keywords: beta1
We need more into on why specifically this is a beta 1 blocker please.
This is very common IME use for Japanese users.  Once the user hit ESC key before the Japanese characters are committed,
the caret moves the beginning of 1st line.  It is difficult to use Composer for Japanese users because of this bug.
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
worksforme.  perhaps another of my fixes fixed this?  I only have a mac for ime, 
so maybe this is a windows issue (shouldnt be, though).
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
This does not happen in Mac.  I never mention this happen in Mac.  
This is Windows specific problem.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Frank - I'm handing this off to you since I don't have a windows IME setup.  
Since this is windows only, I suspect that this is actually an event/keybinding 
problem, and not an editor problem.  

Can you look into this enough to make that determination?
Assignee: jfrancis → ftang
Status: REOPENED → NEW
Reassigned to Frank but he is in class this afternoon.
He will look at it tomorrow.
Status: NEW → ASSIGNED
I trun on the KE_DEBUG in mozilla/widget/src/windows/nsWindow.cpp and try both
case (not in the beginning of the line and in the beginning of the line). Here
is the dump
// Not beginning in the line, behave correctly
89 DispatchKE Type: Down charCode 0  keyCode 229 Shift: U Control U Alt: U
[ ][ ][ ] <==   [ ][ ][ ][ space bar ][ ][ ][ ]
90 DispatchKE Type: PRESS charCode 0  keyCode 229 Shift: U Control U Alt: U
[ ][ ][ ] <==   [ ][ ][ ][ space bar ][ ][ ][ ]
nsHTMLEditRules::WillDoAction action = 2001
Candidate window position: x=64, y=46
WM_KEYUP                wp=41   lp=c01e0001
WM_KEYDOWN              wp=  e5 lp=   10001
nsHTMLEditRules::WillDoAction action = 2001
Candidate window position: x=50, y=46
nsHTMLEditRules::WillDoAction action = 2001
Candidate window position: x=50, y=46
WM_KEYUP                wp=1b   lp=c0010001
91 DispatchKE Type: Up charCode 0  keyCode 27 Shift: U Control U Alt: U
[ ][ ][ ] <==   [ ][ ][ ][ space bar ][ ][ ][ ]

// in the beginning of the line, when I hit ESC it jump to the beginning of the page
WM_KEYDOWN              wp=  e5 lp=  1e0001
92 DispatchKE Type: Down charCode 0  keyCode 229 Shift: U Control U Alt: U
[ ][ ][ ] <==   [ ][ ][ ][ space bar ][ ][ ][ ]
93 DispatchKE Type: PRESS charCode 0  keyCode 229 Shift: U Control U Alt: U
[ ][ ][ ] <==   [ ][ ][ ][ space bar ][ ][ ][ ]
nsHTMLEditRules::WillDoAction action = 2001
Candidate window position: x=22, y=65
WM_KEYUP                wp=41   lp=c01e0001
WM_KEYDOWN              wp=  e5 lp=   10001
nsHTMLEditRules::WillDoAction action = 2001
Candidate window position: x=8, y=65
nsHTMLEditRules::WillDoAction action = 2001
Candidate window position: x=8, y=27
WM_KEYUP                wp=1b   lp=c0010001
94 DispatchKE Type: Up charCode 0  keyCode 27 Shift: U Control U Alt: U
[ ][ ][ ] <==   [ ][ ][ ][ space bar ][ ][ ][ ]

I cannot find any difference between them. I will try to do a printf in the
editor command....

perhaps this means that there is indeed no difference to the editor, and the 
selection is getting moved by something outside the editor (just like that alt 
keybinding bug...)

here is my finding. I am sure this is not some additional key event cause this
because I set a break point in nsEditorContro.cpp nsEditorController::DoCommand
but it didn't go there at all.
Then I try to trace the code which call nsRangeList::Collapse . What I did is in
the 2nd line, type a 'a' (Japanese) and then hit 'ESC' . It should simply remove
that uncommitted 'a' but it in additional move the cursor to the beginning of
the document.
I hit 5 nsRangeList::Collapse after I hit the 'ESC'. Here is the stack trace-


The first collapse after hit 'ESC' key
nsDOMSelection::Collapse(nsDOMSelection * const 0x02ce0490, nsIDOMNode *
0x03d53dd0, int 0) line 2934
DeleteRangeTxn::Do(DeleteRangeTxn * const 0x03d53c10) line 160 + 42 bytes
EditAggregateTxn::Do(EditAggregateTxn * const 0x03d52600) line 56 + 23 bytes
nsTransactionItem::Do() line 106 + 18 bytes
nsTransactionManager::BeginTransaction(nsITransaction * 0x03d52600) line 1033 +
11 bytes
nsTransactionManager::Do(nsTransactionManager * const 0x03672c90, nsITransaction
* 0x03d52600) line 121 + 18 bytes
nsEditor::Do(nsEditor * const 0x02d35de0, nsITransaction * 0x03d52600) line 564
+ 30 bytes
nsEditor::DeleteSelectionImpl(nsEditor * const 0x02d35de0, nsIEditor::EDirection
eNone) line 4447 + 16 bytes
nsEditor::InsertTextImpl(nsEditor * const 0x02d35de0, const nsString & {...})
line 1913 + 17 bytes
nsEditor::InsertTextImpl(nsEditor * const 0x02d35de0, const nsString & {...})
line 1999 + 19 bytes
nsTextEditRules::DoTextInsertion(nsIDOMSelection * 0x02ce0490, int * 0x0012f2b0,
const nsString * 0x0012f1ec, TypeInState {...}) line 1568 + 25 bytes
nsHTMLEditRules::WillInsertText(int 2001, nsIDOMSelection * 0x02ce0490, int *
0x0012f420, int * 0x0012f4bc, const nsString * 0x0012f588, nsString *
0x0012f378, TypeInState {...}, int -1) line 424 + 40 bytes
nsHTMLEditRules::WillDoAction(nsHTMLEditRules * const 0x02d2adb0,
nsIDOMSelection * 0x02ce0490, nsRulesInfo * 0x0012f428, int * 0x0012f420, int *
0x0012f4bc) line 260 + 65 bytes
nsHTMLEditor::InsertText(nsHTMLEditor * const 0x02d35e48, const nsString &
{...}) line 1499 + 45 bytes
nsHTMLEditorLog::InsertText(nsHTMLEditorLog * const 0x02d35e48, const nsString &
{...}) line 206 + 13 bytes
nsHTMLEditor::SetCompositionString(nsHTMLEditor * const 0x02d35de4, const
nsString & {...}, nsIPrivateTextRangeList * 0x03d52230, nsTextEventReply *
0x0012fad0) line 4437 + 20 bytes
nsTextEditorTextListener::HandleText(nsIDOMEvent * 0x03d508b4) line 668 + 53 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x02cfff10, nsEvent *
0x0012fa94, nsIDOMEvent * * 0x0012f7f4, unsigned int 2, nsEventStatus *
0x0012f9f8) line 953 + 17 bytes
nsDocument::HandleDOMEvent(nsDocument * const 0x02bf0e00, nsIPresContext *
0x02cfff10, nsEvent * 0x0012fa94, nsIDOMEvent * * 0x0012f7f4, unsigned int 2,
nsEventStatus * 0x0012f9f8) line 2469

The secondcollapse after hit 'ESC' key
nsDOMSelection::Collapse(nsDOMSelection * const 0x02ce0490, nsIDOMNode *
0x0287d050, int 0) line 2934
IMETextTxn::CollapseTextSelection(IMETextTxn * const 0x0375dd60) line 405 + 65 bytes
IMETextTxn::Do(IMETextTxn * const 0x0375dd60) line 104 + 12 bytes
nsTransactionItem::Do() line 106 + 18 bytes
nsTransactionManager::BeginTransaction(nsITransaction * 0x0375dd60) line 1033 +
11 bytes
nsTransactionManager::Do(nsTransactionManager * const 0x03672c90, nsITransaction
* 0x0375dd60) line 121 + 18 bytes
nsEditor::Do(nsEditor * const 0x02d35de0, nsITransaction * 0x0375dd60) line 564
+ 30 bytes
nsEditor::InsertTextImpl(nsEditor * const 0x02d35de0, const nsString & {...})
line 1958 + 16 bytes
nsEditor::InsertTextImpl(nsEditor * const 0x02d35de0, const nsString & {...})
line 1999 + 19 bytes
nsTextEditRules::DoTextInsertion(nsIDOMSelection * 0x02ce0490, int * 0x0012f2b0,
const nsString * 0x0012f1ec, TypeInState {...}) line 1568 + 25 bytes
nsHTMLEditRules::WillInsertText(int 2001, nsIDOMSelection * 0x02ce0490, int *
0x0012f420, int * 0x0012f4bc, const nsString * 0x0012f588, nsString *
0x0012f378, TypeInState {...}, int -1) line 424 + 40 bytes
nsHTMLEditRules::WillDoAction(nsHTMLEditRules * const 0x02d2adb0,
nsIDOMSelection * 0x02ce0490, nsRulesInfo * 0x0012f428, int * 0x0012f420, int *
0x0012f4bc) line 260 + 65 bytes
nsHTMLEditor::InsertText(nsHTMLEditor * const 0x02d35e48, const nsString &
{...}) line 1499 + 45 bytes
nsHTMLEditorLog::InsertText(nsHTMLEditorLog * const 0x02d35e48, const nsString &
{...}) line 206 + 13 bytes
nsHTMLEditor::SetCompositionString(nsHTMLEditor * const 0x02d35de4, const
nsString & {...}, nsIPrivateTextRangeList * 0x02c6c670, nsTextEventReply *
0x0012fad0) line 4437 + 20 bytes
nsTextEditorTextListener::HandleText(nsIDOMEvent * 0x02c6c984) line 668 + 53 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x02cfff10, nsEvent *
0x0012fa94, nsIDOMEvent * * 0x0012f7f4, unsigned int 2, nsEventStatus *
0x0012f9f8) line 953 + 17 bytes
nsDocument::HandleDOMEvent(nsDocument * const 0x02bf0e00, nsIPresContext *
0x02cfff10, nsEvent * 0x0012fa94, nsIDOMEvent * * 0x0012f7f4, unsigned int 2,
nsEventStatus * 0x0012f9f8) line 2469

The third collapse after hit 'ESC' key
nsDOMSelection::Collapse(nsDOMSelection * const 0x02ce0490, nsIDOMNode *
0x02ce3fb0, int 0) line 2934
nsHTMLEditRules::ConfirmSelectionInBody() line 3689
nsHTMLEditRules::AfterEdit(nsHTMLEditRules * const 0x02d2adb0, int 12,
nsIEditor::EDirection eNext, int 0) line 162
nsHTMLEditor::EndOperation(nsHTMLEditor * const 0x02d35de0, int 12,
nsIEditor::EDirection eNext, int 0) line 4522 + 48 bytes
nsAutoRules::~nsAutoRules() line 99 + 55 bytes
nsHTMLEditor::InsertText(nsHTMLEditor * const 0x02d35e48, const nsString &
{...}) line 1510 + 43 bytes
nsHTMLEditorLog::InsertText(nsHTMLEditorLog * const 0x02d35e48, const nsString &
{...}) line 206 + 13 bytes
nsHTMLEditor::SetCompositionString(nsHTMLEditor * const 0x02d35de4, const
nsString & {...}, nsIPrivateTextRangeList * 0x03d472b0, nsTextEventReply *
0x0012fad0) line 4437 + 20 bytes
nsTextEditorTextListener::HandleText(nsIDOMEvent * 0x03d46144) line 668 + 53 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x02cfff10, nsEvent *
0x0012fa94, nsIDOMEvent * * 0x0012f7f4, unsigned int 2, nsEventStatus *
0x0012f9f8) line 953 + 17 bytes
nsDocument::HandleDOMEvent(nsDocument * const 0x02bf0e00, nsIPresContext *
0x02cfff10, nsEvent * 0x0012fa94, nsIDOMEvent * * 0x0012f7f4, unsigned int 2,
nsEventStatus * 0x0012f9f8) line 2469
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x02cfff10, nsEvent *
0x0012fa94, nsIDOMEvent * * 0x0012f7f4, unsigned int 1, nsEventStatus *
0x0012f9f8) line 1027 + 39 bytes


The fourth collapse after hit 'ESC' key
nsDOMSelection::Collapse(nsDOMSelection * const 0x02ce0490, nsIDOMNode *
0x02ce3fb0, int 0) line 2934
nsAutoSelectionReset::~nsAutoSelectionReset() line 62
nsHTMLEditRules::AdjustWhitespace(nsIDOMSelection * 0x02ce0490) line 3178 + 33 bytes
nsHTMLEditRules::AfterEdit(nsHTMLEditRules * const 0x02d2adb0, int 12,
nsIEditor::EDirection eNext, int 0) line 194 + 17 bytes
nsHTMLEditor::EndOperation(nsHTMLEditor * const 0x02d35de0, int 12,
nsIEditor::EDirection eNext, int 0) line 4522 + 48 bytes
nsAutoRules::~nsAutoRules() line 99 + 55 bytes
nsHTMLEditor::InsertText(nsHTMLEditor * const 0x02d35e48, const nsString &
{...}) line 1510 + 43 bytes
nsHTMLEditorLog::InsertText(nsHTMLEditorLog * const 0x02d35e48, const nsString &
{...}) line 206 + 13 bytes
nsHTMLEditor::SetCompositionString(nsHTMLEditor * const 0x02d35de4, const
nsString & {...}, nsIPrivateTextRangeList * 0x03d4a110, nsTextEventReply *
0x0012fad0) line 4437 + 20 bytes
nsTextEditorTextListener::HandleText(nsIDOMEvent * 0x03d4a154) line 668 + 53 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x02cfff10, nsEvent *
0x0012fa94, nsIDOMEvent * * 0x0012f7f4, unsigned int 2, nsEventStatus *
0x0012f9f8) line 953 + 17 bytes
nsDocument::HandleDOMEvent(nsDocument * const 0x02bf0e00, nsIPresContext *
0x02cfff10, nsEvent * 0x0012fa94, nsIDOMEvent * * 0x0012f7f4, unsigned int 2,
nsEventStatus * 0x0012f9f8) line 2469


The fifthcollapse after hit 'ESC' key
nsDOMSelection::Collapse(nsDOMSelection * const 0x02ce0490, nsIDOMNode *
0x036f33b0, int 0) line 2934
nsHTMLEditRules::AdjustSelection(nsIDOMSelection * 0x02ce0490,
nsIEditor::EDirection eNext) line 3319 + 25 bytes
nsHTMLEditRules::AfterEdit(nsHTMLEditRules * const 0x02d2adb0, int 12,
nsIEditor::EDirection eNext, int 0) line 210 + 21 bytes
nsHTMLEditor::EndOperation(nsHTMLEditor * const 0x02d35de0, int 12,
nsIEditor::EDirection eNext, int 0) line 4522 + 48 bytes
nsAutoRules::~nsAutoRules() line 99 + 55 bytes
nsHTMLEditor::InsertText(nsHTMLEditor * const 0x02d35e48, const nsString &
{...}) line 1510 + 43 bytes
nsHTMLEditorLog::InsertText(nsHTMLEditorLog * const 0x02d35e48, const nsString &
{...}) line 206 + 13 bytes
nsHTMLEditor::SetCompositionString(nsHTMLEditor * const 0x02d35de4, const
nsString & {...}, nsIPrivateTextRangeList * 0x02d1ae60, nsTextEventReply *
0x0012fad0) line 4437 + 20 bytes
nsTextEditorTextListener::HandleText(nsIDOMEvent * 0x02d1aef4) line 668 + 53 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x02cfff10, nsEvent *
0x0012fa94, nsIDOMEvent * * 0x0012f7f4, unsigned int 2, nsEventStatus *
0x0012f9f8) line 953 + 17 bytes
nsDocument::HandleDOMEvent(nsDocument * const 0x02bf0e00, nsIPresContext *
0x02cfff10, nsEvent * 0x0012fa94, nsIDOMEvent * * 0x0012f7f4, unsigned int 2,
nsEventStatus * 0x0012f9f8) line 2469

reassign this back to jfrancis. I really think this is a edit rule issue. Maybe
jae can find the problem from the stack trace.

joe, let me know anything that I can help
Assignee: ftang → jfrancis
Status: ASSIGNED → NEW
Thanks Frank!  This is great info.  Hopefully I can figure it out from this.
Status: NEW → ASSIGNED
I've investigated with much assistance from Frank, and I beleive I have a handle 
on what's going on.  Stay tuned...

Ok, I have half a clue.  There is code in the editor to post-process editor 
commands and do various cleanup.  One thing done there is the removal of empty 
nodes.  Typing escape in ime causes the current ime text node to become empty, so 
the editor removes it in this postprocessing step.  

If I disable the removal, the selection is fine.  It remains in the empty text 
node.  But if I allow the node to be removed, the selection ends up at the 
beginning fo the document in certain cases on windows machines.  This makes no 
sense to me at all.  To the best of my knowledge, none of the editor code or 
selection code involved should behave differently on windows than on other 
platforms.

I'm setting up an NT box with VC 6 and IME software.  Then I'll be able to nail 
this down.  estimating 2/19/00
Whiteboard: [PDT+] → [PDT+] est: 2/19/00
Ok, I have a "fix" for the IME escape bug.  This is a very weird bug.  I suspect 
that there is either something wrong with my dom range gravity code, or something 
wrong with the selection/frame code.  

In IME a textnode can go away when you type escape, since that cancels the ime 
commit and gets rid of what you typed so far.  That leaves an empty text node, 
which I then delete in post processing.  However, the selection is inside that 
empty text node.  This *should* be no problem.  Dom range gravity will 
automagically promote any ranges that have endpoints in that removed node, 
including those ranges that make up selection.  And in fact, on the mac, that's 
exactly what happens.

For some reason on windows it gets confused and puts the selection at the 
beginning of the document.  To make matters even more interesting, this only 
happens if the textnode that is going away is right after a break.  This last 
twist makes me suspect the selection code, since I know it does special things 
when placing selection just after a break.

My workaround is to take my code that removes empty nodes, and add a precheck to 
it that sees if the selection is in an empty text node.  If it is, I manually set 
the selection to be above the textnode.

If I do this all is well.  go figure.

I think once m15 opens I may reopen this bug and assign it to Mike - what I think 
is going on is that selection may not be happy in certain instances when the 
range gravity changes it's selection ranges out from under it.  But I can't debug 
this problem easily on windows, and I think Mike is the better man for this job 
anyway.
Whiteboard: [PDT+] est: 2/19/00 → [PDT+] have fix in hand; getting review+approval
ignore my spewing.  Due to my windows dev environment inexperience, i did not 
have the bits i thought i had when proofing this "fix".  And in fact this fix 
does not work.  I'm back to investigation, though at least me work indicating 
that the textNode removal causes the problem is correct.  

This may take some time since source level debugging does not seem possible here: 
VC6 interferes with the statefullness of the Windows IME system if you set 
breakpoints in a program that is using IME.  stay tuned...
Whiteboard: [PDT+] have fix in hand; getting review+approval → [PDT+] 2/19/00
after much ado, i dont have a workaround for this.  The editor is doing the right 
thing with selection, it seems.  I'm going to have to get mjudge's help to figure 
out what is going on with selection.
Whiteboard: [PDT+] 2/19/00 → [PDT+] 2/22/00
reassign to mjudge; remove date from status whiteboard so mjudge can provide a
new date
Assignee: jfrancis → mjudge
Status: ASSIGNED → NEW
Whiteboard: [PDT+] 2/22/00 → [PDT+]
reassigning back to me.  mjudge helped me out on this, and between us we have it 
figured out, and have a hack to workaround the underlying problem.

The real problem is that on windows we get every single IME event _twice_.  The 
way IME works in the editor, this is almost never a problem.  The scenario 
described in this bug is the only time we know of that it si a problem.

I have a hack that is about 5 lines of code, that will enable the editor to 
detect the problem scenario and avoid it.  I recommned that we put this in place 
for beta1/m14, and file a new bug against windows ime event handling (which I 
guess would go to Frank Tang) to fix the underlying problem after m14.
Assignee: mjudge → jfrancis
updating status whiteboard
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] fix in hand, reviewed by mjudge
fix checked in; r=mjudge, ftang; a=rickg
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
I verified this in 2000022909 Win32 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.