132099 - can't type in link text

Status: VERIFIED FIXED

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

Description

[sujay]

using 3/18 trunk build of netscape

1) launch netscape
2) launch composer
3) enter some text
4) hilight it 
5) click on Link icon
6) enter link URL
7) click OK on link props panel

now in composer click inside the link somewhere and
start typing...nothing happens...no text is added to link text.

regression

Comment 1

[kinmoz]

Looks like a selection enumerator used during the text insertion is returning a
Failure when calling CurrentItem().

Comment 2

[kinmoz]

So this regressed due to aaronl's checkin to nsEventStateManager.cpp rev 1.329:


1.329 <[e-mail]> 09 Mar 2002 22:21
Fixes bug 66597, bug 103284, bug 114440, bug 120023, bug 128741, bug 19259.
Cleans up browse with caret, makes it work with XML content docs, creates
keyboard toggle for it (Accel+shift+K), synchronizes focus and document
selection so that users can tab navigate relative to their last find or click in
text, or vice versa, makes tabbing move relative to named anchor that has been
jumped to. r=bryner, sr=alecf, a=asa


Apparently when you click in the link text, code in
nsEventStateManager::MoveCaretToFocus() clears the selection and does not reset
it when currentFocusNode is null, as in this case. Why are we resetting the
selection if it has already been placed by the selection code?

When the user types the editor tries to get the current selection to see where
it should insert the character, and since there is no selection it just throws
an error.

Here's the stack trace to where it's clearing the selection:


nsTypedSelection::Clear(nsIPresContext * 0x05b87d48) line 4681
nsTypedSelection::RemoveAllRanges(nsTypedSelection * const 0x05ccba80) line 5691
+ 17 bytes
nsEventStateManager::MoveCaretToFocus(nsEventStateManager * const 0x05c066d0)
line 4433
nsEventStateManager::ChangeFocus(nsIContent * 0x05f3b140) line 2642
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x05c066d0,
nsIPresContext * 0x05b87d48, nsEvent * 0x0012f994, nsIFrame * 0x05c1c02c,
nsEventStatus * 0x0012f7a0, nsIView * 0x05c28f60) line 1643
PresShell::HandleEventInternal(nsEvent * 0x0012f994, nsIView * 0x05c28f60,
unsigned int 1, nsEventStatus * 0x0012f7a0) line 6074 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x05bcc3c4, nsIView * 0x05c28f60,
nsGUIEvent * 0x0012f994, nsEventStatus * 0x0012f7a0, int 0, int & 1) line 5977 +
25 bytes
nsViewManager::HandleEvent(nsView * 0x05c28c80, nsGUIEvent * 0x0012f994, int 0)
line 2064
nsView::HandleEvent(nsViewManager * 0x05bccb50, nsGUIEvent * 0x0012f994, int 0)
line 306
nsViewManager::DispatchEvent(nsViewManager * const 0x05bccb50, nsGUIEvent *
0x0012f994, nsEventStatus * 0x0012f890) line 1870 + 23 bytes
HandleEvent(nsGUIEvent * 0x0012f994) line 83
nsWindow::DispatchEvent(nsWindow * const 0x05c28d4c, nsGUIEvent * 0x0012f994,
nsEventStatus & nsEventStatus_eIgnore) line 865 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f994) line 886
nsWindow::DispatchMouseEvent(unsigned int 302, unsigned int 1, nsPoint *
0x00000000) line 4711 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 302, unsigned int 1, nsPoint *
0x00000000) line 4963
nsWindow::ProcessMessage(unsigned int 513, unsigned int 1, long 1179741, long *
0x0012fda8) line 3591 + 28 bytes
nsWindow::WindowProc(HWND__ * 0x165d0622, unsigned int 513, unsigned int 1, long
1179741) line 1130 + 27 bytes
USER32! 77e71820()

Comment 3

[Kevin McCluskey (gone)]

nsbeta1+, EDITORBASE+. This bug causes some editing operations to fail.

Comment 4

[Aaron Leventhal]

I cannot duplicate this bug on my Win2k machine, but I can see from the stack
trace what must be causing it. I'll have to get someone else to test whatever
patch I come up with.

Comment 5

[Aaron Leventhal]

This can be fixed by the same fix for bug 131139 that Pete Zha is working on.

That will ensure that MoveCaretToFocus() is not called when the focus is gained
via the mouse.

Comment 6

[sujay]

can we get a fix for this ASAP? this impacts usability of Composer and Mail
compose.

Comment 7

[Aaron Leventhal]

I'm waiting for Pete Zha to finish his patch in bug 131139, which is essentially
a dup of this.

Comment 8

[sairuh (rarely reading bugmail)]

strangely, i cannot repro this bug with 3/27 trunk bits on win2k, or 3/26 trunk
bits on linux rh7.2 and mac 10.1.3.

fwiw, this also works when using a win2k test build from aaronl.

Comment 9

[Charles Manske]

I still see the problem in my Win2k debug build from today.

Comment 10

[kinmoz]

I still see the problem in my debug win32 bug from today too.

Comment 11

[Aaron Leventhal]

We have the fix in bug 131139, just need an sr= for it.

Comment 12

[Pete Zha]

kin, can you try attachment 76511 [details] [diff] [review](patch) of bug 131139 to verify whether this
patch can fix this bug?
I can't do it because I can't reproduce this bug with trunk build.
Thanks a lot.

Comment 13

[Aaron Leventhal]

fix checked in with fix to bug 131139

Comment 14

[michael wendell]

Verified on Win XP using the 04-01 trunk build.