key navigation and visible area of the page

[bj at altern.org]

> 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 focused, not the 
third one as expected.

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.

regards
Jean-Baptiste
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tab_move.diff
Type: text/x-diff
Size: 510 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20040710/2ab5ce04/attachment.diff>