--Boundary-00=_ve07Auwmq4rJs5u
Content-Type: text/plain;
  charset="iso-8859-15";
  boundary=""
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


> 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

--Boundary-00=_ve07Auwmq4rJs5u
Content-Type: text/x-diff;
  charset="iso-8859-15";
  name="tab_move.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="tab_move.diff"

Index: khtmlview.cpp
===================================================================
RCS file: /home/kde/kdelibs/khtml/khtmlview.cpp,v
retrieving revision 1.640
diff -u -3 -r1.640 khtmlview.cpp
--- khtmlview.cpp	30 Jun 2004 16:20:34 -0000	1.640
+++ khtmlview.cpp	9 Jul 2004 23:17:57 -0000
@@ -1739,7 +1749,7 @@
     }
 #endif
 
-    if (d->focusJustEnteredView)
+    if (d->focusJustEnteredView && (!oldFocusNode))
     {
 	ensureVisible(contentsX(), next?0:contentsHeight());
 	d->scrollBarMoved = false;

--Boundary-00=_ve07Auwmq4rJs5u--