334551 - unable to move text insertion point via keyboard

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Josh Aas]

Often I am unable to move the text insertion point in a text field (URL bar, HTML form text field) via the keyboard. The left and right arrow keys do nothing.

This seems to be a regression from bug 287813, new caret drawing path.

Comment 1

[Josh Aas]

I can see this problem in Cocoa Firefox but not Camino.

I can work around this bug but moving to another app (Finder) and back to Firefox, then clicking in the text field again. Everything seems to work then.

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

I reproduced this bug on stuart's machine, but even after a local backout, I was seeing the same symptoms, even though the caret didn't blink at all. I think this is a bug in cocoa widgets event handling, not in the caret, or the new implementation.

Comment 3

[Mark Mentovai]

I see this in a cocoafox build with 0328 source, but it's intermittent.  It gives trouble consistently if you start the app, tab to a text field (the URL or search bar show the bug), enter some text if there isn't any, and try using the arrows.

Comment 4

[Josh Aas]

Attachment: fix v1.0

Comment 5

[Mark Mentovai]

Comment on attachment 219346 [details] [diff] [review]
fix v1.0

+  status = nsEventStatus_eIgnore;

You don't need this either time you do it.

Deactivate before lostfocus?

Comment 6

[Josh Aas]

Attachment: fix v1.1

this is what I'm checking in

Comment 7

[Josh Aas]

removing regression keyword since this had nothing to do with mrbkap's caret patch

Comment 8

[Josh Aas]

Attachment: fix v2.0, checked in

Something didn't seem right to me about this so I did some event profiling and found the real fix for this problem. The checkin comment:

In bug 334551, we added NS_ACTIVATE/NS_DEACTIVATE messages to windows in order to fix a focus problem. However, we were already sending NS_ACTIVATE following NS_GOTFOCUS somewhere else and the real problem was that immediately afterwords we sent another NS_GOTFOCUS. Adding another NS_ACTIVATE seemed to fix the problem because instead of sending NS_GOTFOCUS/NS_ACTIVATE/NS_GOTFOCUS, we sent NS_GOTFOCUS/NS_ACTIVATE/NS_GOTFOCUS/NS_ACTIVATE which meant that each focus message had an activate paired with it. The real fix here however is to not send the second NS_GOTFOCUS message. b=334551