WM suport for grab key scrolling

[Eben Eliason]

> > Absolutely.  Ideal behaviors:
> >
> > 1) The scrolling region directly visible beneath the mouse gets grab focus.
> > 2) If two scrolling regions overlap, the top one should take the grab focus.
> > 3) If a scrolling region is embedded in another (such as an iframe in
> > a web page), then the innermost region should get grab focus, unless
> > it reaches its min or max scroll and can no longer move, at which
> > point the next region in the hierarchy gets it.
> >
>
> Hmm I'm not convinced about this. Usually keyboard actions apply either
> globally (to the system or to the active window) or to the focused
> element. I feel pretty strange, interaction wise, to have a keyboard
> button depend on the position of the mouse.

The grab key isn't so much a keyboard action as it is a modifier key
for the trackpad/mouse.  This is very much like the behavior of a
scroll-wheel mouse (or Apple's two-finger scrolling), which always
scrolls the view beneath the cursor.

Requiring focus in the region won't work that well for several
reasons.  First, it could require a click to set focus.  Additionally,
it might be the case that every portion of the scrollable region is
clickable (eg. a long list where each row is clickable/selectable), in
which case the click intended to focus the region would actually have
an immediate unintended action.

> Also doesn't this introduce accessibility issues?

I don't believe so. It may mean that there's no way to use grab
scrolling solely from the keyboard, but that doesn't eliminate the use
of focus, arrow keys, spacebar, and page up/down from working as per
usual.  This is just an enhancement.

If it's important, we could set it up so that the tab key tabs through
the scroll regions when the grab key is activated (toggled on or being
pressed).  That way, even those who can't use the mouse can switch the
grab focus from it's default region (under cursor) to any they choose.

- Eben