405744 - Re-implement Command-back/forward handling

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Stuart Morgan]

Due to changes in the way Cocoa widgets propagate key events on trunk, the current implementation of Command-back/forward is not going to work, which is now considered expected behavior.

Instead, the current thinking is that we need to implement this as performKeyEquivalent: handler that checks whether a text field is focused, and treats it as a history command if not.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Will this be able to check for text fields in plug-ins, or just HTML?  Maybe cmd-arrows aren't common there, but delete probably is.

Comment 2

[Stuart Morgan]

The delete code actually already checks for both plugins in general and text fields, due to bugs where deletes that were being handled were still bleeding through to us, so we can do the same here.

Comment 3

[Stuart Morgan]

Attachment: fix

This is a little more fragile than the old way, but I've covered all the cases I know of where the content might map this to an editing command, and I think it's the best we can do under the new world order of key handling.

Comment 4

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 312540 [details] [diff] [review]
fix

sr=pink

Comment 5

[Stuart Morgan]

Landed on trunk.

Comment 6

[Eiichi]

I tested with my own build, attachment 312540 [details] [diff] [review] causes two problems.

1) Even if command key isn't pressed, only arrow keys enable back/forward handling. 
2) Previous/Next Tab shortcuts [Option-Command-Arrows] can't work.

Comment 7

[Stuart Morgan]

Stupid order of binary operations. Fix checked in.

Sorry, I must have changed the conditional format and not fully re-tested, since I know it was right at some point. Thanks for the early warning.

Comment 8

[Eiichi]

Thannl you for your quick fix, Stuart.
I confirmed that the problems have been solved.