Traditional Netscape 4.x (Unix) will scroll the browser window up on Delete or Backspace, which provides a handy main-keyboard mirror for spacebar scrolling it down. (I believe this also works, for Backspace, in Internet Explorer). Current Mozilla scrolls down on spacebar, but has no main-keyboard key to scroll up. I have a patch to fix this so that Backspace and Delete scroll back up. I'm not sure if the XUL code I'm using is correct or minimal; I just copied the code that handled spacebar and made the obvious changes. I have tested the code and it works (and Delete and Backspace keep working properly in, eg, the URL bar). Diff will be glued on as an attachment. (Component and cc: was suggested by people in #mozilla on irc.mozilla.org; my apologies if they're inappropriate.)

This is a browser-window issue ... it's really up to Don's group whether we have these bindings or not. But it seems like we shouldn't have to be doing the test for text field/textarea -- the event system should handle the XBL bindings first, before these XUL bindings are even called, no? I don't think checking just for textfield and input is enough (we have a similar problem on middle-click events, and I've had to add several more checks to navigator.xul: currently it's if (!((tagName == "input" && (type == "" || type == "text" || type == "password")) || tagName == "textarea")) and the jury is still out as to whether that's enough. This is all because of another joki bug, 23669, and if that were fixed none of this would be a problem. Since that bug has been sitting around forever, I speculated that if the text control event listener worked right, maybe we could work around the rest, and made a bug for that, 28401, which is now blocked because text controls are being rewritten. Setting up dependency tree.

Akkana, please see bug 22529. I'm not sure whether to make that one depend on this, or mark this as a duplicate. Leaving the decision to you :-)

Linux Build ID 2000051308 Confirming this and making it depend on 22529. IMHO, ideally, the document would have eventhandlers bound to certain events, and receive all events unless they're intercepted by for example form elements, which would have their own eventhandlers for those events. So instead of special casing elements in bindings, the bindings should be specified in the elements. I think that's also kinda what akkana's saying, not sure though.

updating component and owner.

Let's not morph this, it is about a particular behavior in response to a keystroke in the browser only, and that isn't an XPToolkit issue. If there are other problems getting this to work right, easily, efficiently - file other bugs. changing component, reassigning.

For the future ...

*** Bug 42995 has been marked as a duplicate of this bug. ***

Many people, including me, hate the backspace behavior in IE. If you don't properly place the input focus to a text field backspace will cause IE to "go back". Which is annoying as hell. If backspace navigation is ever implemented in Mozilla it should be an option deselectable from preferences. And what is wrong w/ the page up and page down buttons on the keyboard? isn't that what those keys were designed for?

This is a current NS 4.xx feature (at least under Unix), and I think that there are merits in remaining compatable. Delete/Backspace is also a main key in the core keyboard, which implies both easier to reach from a normal typing position and that it will be present on minimalistic keyboards when other keys are only available as multi-key combinations.

I agree with fig\tree. Backspace going back (IE, current Moz) is annoying. Also, the symmetric "forward" shortcut, Shift-Backspace, isn't obvious to users who find Backspace. Having backspace pgup (NS4) and space pgdn (IE, Moz, NS4) is annoying too, but not quite as much. Is there a reason these keys are used for shortcuts? The shortcuts break when an input is focused, and afaik there's no way to "unfocus" a form element and move focus to the page. (One thing that annoys me about emacs is that I can never press a key, even escape, and have it /not/ do anything.) Should this bug be all/all? I haven't noticed any differences between unix behavior described in this bug and Windows behavior.

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

over to german, what should backspace do?

Cc'ing mpt too.

nsbeta1

I'm one of those weird types who think the only thing Backspace should ever do is delete stuff. If Space is used as a synonym for Page Down, Shift+Space would make sense as a synonym for Page Up. (Reaching for it would be quicker than going from the spacebar to the Backspace key, too.)

Me, too. What mpt said.

And I just got back to university and discovered that Shift+Space is 4xp (on Mac OS), too ...

Note, however, that Shift+Space is a two-hand (or two-finger) combo, not a single key. Backspace (or Delete) has the virtue that it is a single key. And it is a Unix Netscape 4 feature. Some of us have those reflexes wired into our brains and our keyboard layouts by now.

See also bug 69981.

I think personally this is Linux specific (where I am not as expert as many folks here), as I have never encountered/used backspace as a scrolling mechanism in either win32 or macos and find it highly unusual. If somebody more versed in Linux keyboard access then me wants to take this bug, be my guest. For now I am forwarding this to aaronl, as he is doing a lot of work on keyboard shortcuts across the board. See http://www.mozilla.org/projects/ui/accessibility for more info on current assignments. I'll take this off the nsbeta1 radar also as I believe this is not as severe.

If this was implemented for the browser window, then people would instinctively try pressing Backspace to scroll up in: * the browser window, when a TEXTAREA containing valuable text had focus but happened to be out of sight (so the user would press Backspace repeatedly, wondering why it wasn't working) * the message pane or the thread pane of the mail/news three-pane window (bye bye, messages!) * the Bookmarks window (you don't really need all those bookmarks, do you?) * the Address Book (pah, that'll teach you for having so many addresses that you need to scroll the address book window) * the Cookie Manager ... This bug is a wontfix if ever I saw one.

If someone really feels strongly about this, we should talk about it at the next keyboard UI meeting (usually Fridays around 3pm California time). Please send me an email to get involved in those meetings. The current keyboard spec we've devised (to try and settle all these keyboard issues finally) is at www.mozilla.org/projects/ui/accessibility/mozkeyintro.html

*** Bug 92246 has been marked as a duplicate of this bug. ***

useless responses to what mpt wrote If this was implemented for the browser window, then people would instinctively try pressing Backspace to scroll up in: * the message pane or the thread pane of the mail/news three-pane window (bye bye, messages!) Wrong, this is a misinterpretation, backspace!=delete, in nc4 backspace here would bring you to the message center, for mozilla w/o a message center it could do thread up navigation (see bookmarks) * the Bookmarks window (you don't really need all those bookmarks, do you?) Wrong, this is a misinterpretation, backspace!=delete, backspace (windows) in a tree, eg Bookmarks, takes you to the object's parent. * the Address Book (pah, that'll teach you for having so many addresses that you need to scroll the address book window) Addressbook would probably behave like mail thread pane. If we ever had a threaded view (mailing lists) this might even be useful.

Reopening I just got shocked when I found out why backspace doesn't scroll backwards. Netscape <= 4.7 uses backspace == scroll up; since I never use IE (almost), I didn't even know that IE had "changed" the default definition. I've been waiting for this to be fixed for a Long Time, and never imagined that it was anything more than an oversight. I actually require this functionality for compatibility with an older in-house browser that followed the UI of netscape <= 4.7. Yes, I can fix it in the source and build a custom Mozilla (I need to anyways), but for most users that's not an option. I'm totally programmed to use backspace to scroll up, both by N (where N is around 6+) years of using Netscape 4.x, and M (where M is around 8+) years of using Emacs plus Gnus to read mail and news, which also uses backspace to scroll backwards. Note that the arguments that http://www.mozilla.org/unix/customizing.html#keys "solves" the problem for anyone who cares are simply wrong. That page provides people who can safely modify XML/XBL/XUL with a way to fix it that only can be done (so far as I can tell) if you have access to a buildable copy of the source. (distributions don't have a res/builtin directory, at least not unless you explode the jar files). Since there will NEVER be total agreement on this issue, I suggest we desperately need a UI/Keymapping editor for prefs with some reasonable easy-to-select defaults (ns 4.x-style, IE-style, etc) (Bug 57805) I believe that mpt's arguments against this are a combination of mistaking backspace and delete, and simply incorrect given that ns <= 4.7 (and a number of other browsers) used backspace == pageup with no complaints that I ever heard about (and ns4.x does it on Windows and Unix at minimum). Right now backspace == NOOP in browser windows. I think we should commit backspace == pageup (which has no real dataloss potential), but NOT commit (or remove) backspace == go back (bug 69981 and bug 108816) which does. I'll probably get slapped down for reopening this, but I think it's important.

> (distributions don't have a res/builtin directory, at least not unless > you explode the jar files) Where are you getting your distributions? Are you installing the RPM packages? I use the stub installer, and I always get a /usr/local/mozilla/res/builtin directory created.

I just checked a machine where I have the RPMs installed (mozilla 0.9.6), and it installs /usr/lib/mozilla/res/builtins.

RPM's are Linux; I develop mostly on FreeBSD. My apologies; I just checked again and the res directory appears to be there on Linux; in the directory I was working with (perhaps because of compile options? Or maybe a build that didn't finish after an update?) there is no dist/bin/res/builtin directory.

You are reopening such a can of worms, you have no idea. I think I've done an okay job as keyboard component owner help to resolve most arguments. This one, however, goes on and on no matter what I try. If you check something in to change this, someone else will just reverse it. So I plead for common sense. I ask that you leave it alone please, not because I don't like it -- we can't keep thrashing this back and forth and have something different every day. It won't kill anyone if backspace does nothing. And, there is a reasonable if not great argument that backspace shouldn't do a thing. I know this doesn't make everyone happy, but we can't exactly have a vote. I'm sorry if you're on the side that doesn't like the decision.

Aaron: I understand to position; there are (at least) two camps with diametrically opposite positions on what backspace should do. Quite honestly, I think the proper solution is to make setting keyboard mappings not require high arcana - i.e. make a pref and/or pref panel. Since the code is trivial either way, and it will cost us almost nothing, I may work on that. This particular behaviour should be pretty easy to put into a pref. We can then argue over whether it should go in as a pref, or if we should wait (until when?) for a full key-mapping UI. Now the fun is to decide what the best way is to control XBL settings via a pref...

v

*** Bug 134584 has been marked as a duplicate of this bug. ***