402766 - use keyDown: instead of pKE: for back/forward key commands

Status: VERIFIED WONTFIX

(Camino Graveyard :: General, defect)

Description

[Josh Aas]

Attachment: fix v1.0

We should use keyDown: instead of performKeyEquivalent: for back/forward key commands in Camino. That way event propagation matches up with expected behavior - Gecko gets a chance to handle the event before Camino has to decide what to do without depending on Gecko to call interpretKeyEvents in pKE:.

Comment 1

[Josh Aas]

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

oops, forgot to add back the part that requires the command key to be down!

Comment 2

[Josh Aas]

Attachment: fix v1.1

Comment 3

[Stuart Morgan]

Comment on attachment 287583 [details] [diff] [review]
fix v1.1

This doesn't distinguish between "Command-arrow" and "Command-anythingelse-arrow"

Also, why was this moved down into BCV?

Comment 4

[Josh Aas]

Attachment: fix v1.2

Comment 5

[Stuart Morgan]

Comment on attachment 287640 [details] [diff] [review]
fix v1.2

r=me with a high-level comment explaining that this is to map command-arrow to forward/back, and explaining that we are deliberately using keyDown: rather than pKE: to make sure that text field/IME behavior wins (lest some future developer decide to "simplify" this code to pKE: without thinking about the behavioral side effect)

Comment 6

[Josh Aas]

Comment on attachment 287640 [details] [diff] [review]
fix v1.2

Hopefully we'll just kill off this feature, see bug 379199 comment 24.

Comment 7

[Josh Aas]

Sam Sidler pointed out that command-arrow is a feature in Firefox, I'm not sure how they do that. If I had to guess I'd guess that they decide whether or not to invoke back/forward based on whether some form of text input has focus. If that is true, then Camino should intercept the key event before gecko gets it, see if Gecko has text input focused, and if so pass the event on to gecko otherwise invoke back/forward. That would work and does not rely on propagating events that might have been handled. Just a little trickier to code.

Comment 8

[Stuart Morgan]

That's a good point, and it actually wouldn't be too hard to do since we already have code for determining if textfields are focused for some similar issues.

Comment 9

[Stuart Morgan]

This no longer makes sense per our evolving discussion on key event handling, so WONTFIXing in favor of bug 405744, which is the current plan based on comment 7.