User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:25.0) Gecko/20130713 Firefox/25.0 (Nightly/Aurora) Build ID: 20130713030205 Steps to reproduce: I tried to hit "ctrl+w" in the URL bar to delete back to the lash slash. It's also broken in all other input boxes. This happened on the OS X version of nightly and broke with the latest auto update I got installed a few minutes ago. Actual results: Nothing happened, text stays unchanged. Expected results: It should have deleted back to the last slash or deleted the last word.

Using mozregression: Last good nightly: 2013-07-11 First bad nightly: 2013-07-12 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dde4dcd6fa46&tochange=b44898282f21

I wonder if the commits for #282097 broke it.

Just confirmed that the UX nightly from 2013-07-13 still works.

Confirming per comment #1. J. Ryans, is this possibly a regression from bug 282097?

Yes, this behavior change was introduced as part of bug #282097. While working on that bug, I made an assumption that it would be good to clean up the Mac key bindings (https://hg.mozilla.org/mozilla-central/rev/4bb8320acc0c). In most cases, the key bindings removed in that patch are still available because they are defined in the OS X standard bindings that are available to any Cocoa application, and thus they are picked up by the new code from bug #282097 which now listens to the system and user key bindings. However, there were also a few non-standard bindings that Gecko previously defined, and at the moment those are now gone: * Ctrl+u: cmd_deleteToBeginningOfLine * Ctrl+w: cmd_deleteWordBackward Unlike many of the other Emacs-style bindings removed in the above patch (such as Ctrl+a & Ctrl+e), these bindings are not defined in the OS X system default set of bindings, and are not available to other Cocoa applications. Neil, do you think it is better to strive for compliance with other Cocoa applications by default, or should I revive the two bindings above? For users that are aware of the OS X DefaultKeyBinding.dict user binding configuration file, they can use that to revive these two bindings if they would like to.

In case someone else runs into this, this is how it can be fixed: Create a file in ~/Library/KeyBindings named DefaultKeyBinding.dict with the following content: { "^w" = "deleteWordBackward:"; "^u" = "deleteToBeginningOfLine:"; }

Personally, I think that user should customize the KeyBindings in OS level because if we implement such shortcut keys, it may conflict with system-wide user settings.

May I propose putting an explanation for that into the update notes on OS X? There are quite a few apps that emulate emacs style input commands.

I'm more than happy for this bug to be closed as the old behavior can be restored.

I'm not sure if which is preferred that the XBL key bindings and native key command. If XBL key bindings is preferred (I guess so), we should hack widgeth::NativeKeyBindings::KeyPress() even if we'll restore some shortcut keys.

(In reply to J. Ryan Stinnett from comment #5) > Neil, do you think it is better to strive for compliance with other Cocoa > applications by default, or should I revive the two bindings above? For > users that are aware of the OS X DefaultKeyBinding.dict user binding > configuration file, they can use that to revive these two bindings if they > would like to. Sorry, that's not really my area, but I wouldn't object to restoring those bindings, assuming that's what the Mac UX guys want.

Thanks Neil. Masayuki, in comment #7 it sounds like you are suggesting we leave it as-is, but then in comment #10 it sounds like you think we should change something? I am not sure what you mean by "we should hack widget::NativeKeyBindings::KeyPress()". If some key binding triggers the selectors deleteWordBackward: or deleteToBeginningOfLine:, NativeKeyBindings::KeyPress already handles that.

I don't like to restore the behavior because it's not standard behavior of MacOS X. However, I don't strongly object to restore the behavior because I guess a lot of user will complain about this bug. I believe that even if we'll restore the behavior, the restored behavior shouldn't block the user defined action in OS level. So, if DefaultKeyBinding.dict setting is ignored by XBL key bindings, we shouldn't define the Emacs like shortcut keys in the XBL file. Then, we should restore the behavior with hard coding in widget::NativeKey::KeyPress(). If Ctrl+[wuae] doesn't cause any action, KeyPress() can return the Emacs like behavior. If so, I'd like to add a new pref for completely disabling the hard corded shortcut keys. E.g., "ui.emacs_like_shortcut_keys.enabled"

I am not currently convinced that supporting the old (non-standard for a OS X app) behavior is needed in this case, especially because there is a workaround available, as mentioned in comment #6.

I agree marked as WONTFIX. Steven, do you have any objection?

> Steven, do you have any objection? No, I don't.

Thank you. -> v.