Closed Bug 189615 Opened 23 years ago Closed 21 years ago

Emacs/vi keybindings (shortcut keys) conflicting when URL/Search bar/text area has focus (Ctrl+W does not close tab, Ctrl+U does not display page source)

Categories

(Firefox :: Keyboard Navigation, defect, P3)

Product:
Firefox
Component:
Keyboard Navigation
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 257405

People

(Reporter: jdavin, Assigned: aaronlev)

References

Details

(Whiteboard: Please read comment 23)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5 When I create a new tab (with Control-T) and then immediately try to close it with Control-W, nothing happens. My homepage is about:blank. However, I can close the tab by going to the File menu and choosing Close Tab. It's just the keyboard shortcut that doesn't work on empty tabs. This only happens when the new tab has no page loaded. If I load a page and then do Cntl-W, it works. Reproducible: Always Steps to Reproduce: 1. Press Control-T to get a new tab window. 2. Press Control-W to close the new tab. It won't work. (assuming your homepage is about:blank). 3. Actual Results: Tab window didn't close Expected Results: Tab window should have closed. none
Yes and no. When you use Ctrl+T to open a new tab the focus shifts to the location bar (logically, so you can start typing a URL). But when the focus is in the location bar one cannot close tabs or anything else. But if you shift the focus back out of the location bar into your blank tab by clicking in the content area with a mouse and then press Ctrl+W the tab does indeed close. This is therefore invalid (not a bug)
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
verified invalid 2004-01-10
Status: RESOLVED → VERIFIED
*** Bug 223675 has been marked as a duplicate of this bug. ***
Why is this invalid? If I open 2 tabs and only wanted one, so I do CTRL W to close the second one, shouldn't it work? CTRL W doesn't do anything else, so why not close the tab (or window). There are other hotkeys that work and some that don't (See Bug 223675).
Also, if you have focus in the URL bar, and then go to the File Menu, CTRL W is still available. The URL bar still has focus.
(In reply to Bug 223675 comment #8) Jesse Wrote > Maybe the shortcuts Jerome listed in comment 5 don't work on Linux because > they're interpreted as Emacs text-editing commands when the address bar has focus. In Emacs, CTRL W is write to file. What does that have to do with text-editing? Has the URL bar code forked enough to have a separate dependency?
Status: VERIFIED → UNCONFIRMED
Depends on: 72352
Resolution: INVALID → ---
Freaking Emacs/vi bindings again. From bug 223675 comment 5: > In fact, I also found that the following ctl+key do not work when the address > bar has the focus: > - ctrl+B (bookmarks) Ctrl+B is emacs for back up one character > - ctrl+D (bookmark this page) Ctrl+D is emacs for delete character following cursor > - ctrl+E (downloads) Ctrl+E is emacs for go to end of line > - ctrl+F (find) Ctrl+F is emacs for go forward one character > - ctrl+H (history) Ctrl+H is vi for back space > - ctrl+K (search field) Ctrl+K is emacs for delete rest of line after cursor (btw, in Linux Firefox now uses Ctrl+J for focus Search Field) > - ctrl+U (page source) Ctrl+U is vi for delete current line and not to forget: Ctrl+W is vi for delete word immediately before cursor And it's not just the URL bar; it's any text area (including this one) which includes the search field as well. Since most people aren't going to search the Mozilla browser product for what is apparently a Firefox problem, we should reopen this bug to catch dupes. I've also altered the summary to catch queries (feel free to add to it).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Control-W does not close new (empty) tabs → Emacs/vi keybindings conflicting when URL/Search bar / text area has focus (Ctrl+W does not close tab, Ctrl+U does not display page source)
Firefox builds against (and looks like) GTK 2, and GTK 2 does not use Emacs keybindings in its text fields by default. If Firefox is to feel native on a Linux/Gnome desktop, it should not use Emacs keybindings, to match the rest of the desktop. I think these keybindings should simply be removed for now, and maybe later on, as a separate request, Firefox could read the GTK preferences item for default vs. Emacs keybindings. Also, this bug is marked as depends on bug 189615, but I don't think it does. Firefox attempts to match the Linux user's native look and feel, and Mozilla doesn't, so different issues influence the two separate bugs. I think Emacs keybindings in Firefox and in Mozilla are separate, independent issues, and this bug's dependency on bug 189615 should be removed.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040615 Firefox/0.9 I second this "thing" (intended as a feature, but perceived as a bug by more people, I guess). Very bothersome for my browsing experience. I use vi myself, but I still don't like it that my browser behaves this way. Any normal user would not expect it, even if they use vi (or emacs). (Special) Stuff like this should be handled by an extension in my opinion.
Assignee: firefox → aaronleventhal
Component: General → Keyboard Navigation
QA Contact: asa → jruderman
*** Bug 254060 has been marked as a duplicate of this bug. ***
Tweaking summary to catch dupes.
Summary: Emacs/vi keybindings conflicting when URL/Search bar / text area has focus (Ctrl+W does not close tab, Ctrl+U does not display page source) → Emacs/vi keybindings (shortcut keys) conflicting when URL/Search bar/text area has focus (Ctrl+W does not close tab, Ctrl+U does not display page source)
*** Bug 257547 has been marked as a duplicate of this bug. ***
Priority: -- → P3
*** Bug 265753 has been marked as a duplicate of this bug. ***
*** Bug 259810 has been marked as a duplicate of this bug. ***
*** Bug 260188 has been marked as a duplicate of this bug. ***
Since a pretty long time, CTRL+U was been used... and I think that almost everybody that is knowing this shortcut is using them... Same thing for others like CTRL+W. I don't care about the Windows release, but I think that *no program* under linux should define those common shortcuts in order to do something else. In the last version, CTRL+U was not there to show the source and I just reverted my firefox version to the last one. Please, choose free accelerators when you define new shortcuts.
Add my voice to reinstate CTRL-U to mean 'clear line'. It is typical in most shells used on Unix (and I am talking about AIX, HP-UX, Tru64, BSD, Linux, Solaris here) to mean 'clear line'. Very annoying if you switch from Opera to Firefox and expect to use control U to clean the URL bar. I often find myself selecting a URL, have it in the paste buffer, click on the URL bar, press ctrl+u to clear the line and paste the new URL in, of course, I get the source.
This bug, as originally filed, was about how the emacs keybindings prevented the user from using the firefox shortcut keys while a text field was focused. Therefore, the original intent of this was to disable the emacs keybindings in text fields so that the standard firefox commands (new tab, close tab, etc) worked in text fields. Comment 16 and comment 17 seem to be saying that this has now been done. http://tinyurl.com/4j9zw/ suggests that you can configure whether you want the old or the new behaviour. Is this bug fixed?
(In reply to comment #17) > I often find myself selecting a URL, have it in the paste buffer, click on the > URL bar, press ctrl+u to clear the line and paste the new URL in, of course, I > get the source. Umm, why are you wasting your time clearing the URL bar at all? After selecting a URL to the paste buffer you can just middle-click somewhere in the rendering area (but not a text area or link) or on the tab and Firefox will browse to that URL.
Well what is the rational to have ctrl+u open the source accross the board in Firefox. I personally would want to keep it the same and have ctrl+u clear the address bar when focus is on the address bar and open the source else where.
What Gavin said. You're advocating fixing bug 260188 (emacs/readline keybindings are off by default), not this bug (the default configuration (?) uses inconsistent, conflicting shortcuts).
Please throw my vote in the "please bring back the old ^W and ^U (kill word, kill line) behaviour" camp. I've used those for years in all my applications and find their new behaviour extremely counterintuitive. (While trying to file this bug report, I've killed my browser window once and seen the source code four times! Yes, I make many typos.) Until then, I'm hoping I can find the old packages again. Thanks
Marking WORKSFORME per all the previous comments. If someone could track down a checkin that fixed this that would be great. All followup about how this is bad should go in bug 260188.
Status: NEW → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → WORKSFORME
Whiteboard: Please read comment 23
That would be bug 257405, "Use gtk2 native keybindings for input and textarea".
Status: RESOLVED → REOPENED
No longer depends on: 72352
Resolution: WORKSFORME → ---
Sorry for the spam. *** This bug has been marked as a duplicate of 257405 ***
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → DUPLICATE
I hate to add another comment to this bug, but I'm hoping this will help satisfy some people. I personally want the keybindings to be the way they were previously. Having the source window pop up and killing tabs is irritation, but I definately think that the current state is the way it should be. The settings are based on the gtk settings, and therefore, we can change them as we see fit. Firefox should exhibit the same behavior as our other gtk apps. This way, people who know about these keybindings can use them, but people used to the normal gtk behavior won't be surprised. Anyone who has a problem with this should complain to the gtk developers for not using standard unix keybindings (as you may see them), or complain that firefox should not use gtk for whatever reason, although you are not likely to get anywhere with that one. Either way, this discussion is not likely to progress any further. Again, sorry for the extra post.
Put me in the 'don't ever use a keybinding for more than one command in an application' camp. If I have my focus on a html form textfield, I should still be able to open a tab with ctrl-t. If people want their emacs keybindings, perhaps there should be an option that you can set to enable it, but 'new tab' and 'show source' commands are the most apparent and documented uses for these keybindings. It's bad UI design practice to allow keybindings to do more than one thing in the same window. If there was a design decision in the browser to keep keybindings consistent with GTK (Gnome) and CTRL-T (to open a new tab) is stepping its ugly foot all over an existing standard keybinding in GTK, then theres a problem.... But hey, I don't use GTK. I wish there was an option to make all the keybindings to be consistent with KDE, cos I like pressing shift-left/right arrow to change tabs, not alt-#. Hey wait, isn't this bug report closed?
*** Bug 305740 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.