[PATCH ] Re: key navigation and visible area of the page

[Tobias Anton]

On Samstag, 10. Juli 2004 03:34, bj at altern.org wrote:
> > That's why I think we should ignore the tab order in case of
> > d->scrollBarMoved and pick the most upper left completely visible
> > element. If there is no such element, we'd fall back to the old tabbing
> > behaviour, respecting the tab order in that case.
>
> This should be the case ONLY if the currently focused element is not
> visible. Currently, if you focus on the second element of your page, scroll
> down and up again and press tab, the first element on the page will be
The first visible one, that is.

> focused, not the third one as expected.

The condition whether the currently focused element is visible or not cannot 
be the primary condition for selecting the search strategy for the next node.
In case two adjacent focusable elements are more than one page apart, the view 
will be scrolled by at most one page. Only after the second scrolling move 
the next element will be visible, and this is when it's going to be focused.
In between, neither the currently focused nor the next focus node will be 
visible. 

That's why the boolean variable d->scrollBarMoved was introduced.
It remembers whether the user's last action was to scroll the document or to 
hit the tab key. The search strategy depends on that flag and this is correct 
IMHO.

A solution for your problem could be to start searching for the next focusable 
Element from the currently focused one. It would fix your example case, but 
only if the third element is already visible.

Patch attached. Is that okay for you?

> Additionnaly, there is a bug with the current
> KHTMLView::focusNextPrevNode(bool next), which makes it swallow the first
> tab event. Example: Load a page, select a form item, press TAB, nothing
> happens. Press again and it works. This patch fixes this behaviour.

I assume you mean selecting it with the mouse, right?

Thanks for pointing this out. My fix looks slightly different; It is necessary 
to reset d->focusJustEnteredView when we recognize that it contains a wrong 
value. Otherwise, the problem will appear later, i.e. when the first node has 
been focused.

Patch attached - comments welcome.

Cheers
-- Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: temp.diff
Type: text/x-diff
Size: 1517 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20040710/c5c79f39/attachment.diff>