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

VERIFIED FIXED in M14

Status

()

P3
normal
VERIFIED FIXED
19 years ago
8 years ago

People

(Reporter: teruko, Assigned: mozeditor)

Tracking

({inputmethod})

Trunk
x86
Windows NT
inputmethod
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M13

Comment 1

19 years ago
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.
(Reporter)

Comment 2

19 years ago
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.

Updated

19 years ago
Target Milestone: M13 → M14

Comment 3

19 years ago
Move to M14

Comment 4

19 years ago
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
(Assignee)

Comment 5

19 years ago
ok, but i may need help if this doesnt happen on the mac.
Status: NEW → ASSIGNED
(Reporter)

Updated

19 years ago
Keywords: beta1

Comment 6

19 years ago
We need more into on why specifically this is a beta 1 blocker please.
(Reporter)

Comment 7

19 years ago
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.

Comment 8

19 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
(Assignee)

Comment 9

19 years ago
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
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 10

19 years ago
This does not happen in Mac.  I never mention this happen in Mac.  
This is Windows specific problem.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Comment 11

19 years ago
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

Comment 12

19 years ago
Reassigned to Frank but he is in class this afternoon.
He will look at it tomorrow.

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 13

19 years ago
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....
(Assignee)

Comment 14

19 years ago
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...)

Comment 15

19 years ago
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
(Assignee)

Comment 16

19 years ago
Thanks Frank!  This is great info.  Hopefully I can figure it out from this.
Status: NEW → ASSIGNED
(Assignee)

Comment 17

19 years ago
I've investigated with much assistance from Frank, and I beleive I have a handle 
on what's going on.  Stay tuned...
(Assignee)

Comment 18

19 years ago
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.
(Assignee)

Comment 19

19 years ago
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
(Assignee)

Comment 20

19 years ago
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
(Assignee)

Comment 21

19 years ago
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
(Assignee)

Comment 22

19 years ago
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

Comment 23

19 years ago
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+]
(Assignee)

Comment 24

19 years ago
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
(Assignee)

Comment 25

19 years ago
updating status whiteboard
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] fix in hand, reviewed by mjudge
(Assignee)

Comment 26

19 years ago
fix checked in; r=mjudge, ftang; a=rickg
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
(Reporter)

Comment 27

19 years ago
I verified this in 2000022909 Win32 build.
Status: RESOLVED → VERIFIED
Keywords: inputmethod
You need to log in before you can comment on or make changes to this bug.