Closed Bug 36922 Opened 22 years ago Closed 20 years ago

Delete/Backspace to scroll a browser window up


(Core :: DOM: UI Events & Focus Handling, enhancement, P3)






(Reporter: cks+mozilla, Assigned: aaronlev)


(Depends on 1 open bug)



(1 file)

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;
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.
Assignee: joki → asadotzler
Component: Event Handling → Browser-General
Depends on: 23669, 28401
QA Contact: janc → jelwell
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.
Depends on: 22529
Ever confirmed: true
Assignee: asa → trudelle
Component: Browser-General → XP Toolkit/Widgets
QA Contact: jelwell → jrgm
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.
Assignee: trudelle → don
Component: XP Toolkit/Widgets → XPApps
QA Contact: jrgm → sairuh
For the future ...
Target Milestone: --- → Future
*** Bug 42995 has been marked as a duplicate of this bug. ***
Component: XP Apps → Keyboard Navigation
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 

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.
Assignee: don → vishy
over to german, what should backspace do?
Assignee: vishy → german
Cc'ing mpt too.
Keywords: 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 for more
info on current assignments.
I'll take this off the nsbeta1 radar also as I believe this is not as severe.
Assignee: german → aaronl
Keywords: nsbeta1
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
Closed: 21 years ago
Resolution: --- → WONTFIX
*** 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.

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

Note that the arguments that
"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.
Depends on: 57805, 69981, backspace
Resolution: WONTFIX → ---
No longer depends on: backspace
> (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.

Closed: 21 years ago20 years ago
Resolution: --- → WONTFIX
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...
*** Bug 134584 has been marked as a duplicate of this bug. ***
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.