More on FLUID-3590

[Antranig Basman]

This morning's look at 3590 I think has brought me closer to 
understanding the problem... unfortunately the best understanding now is 
that I can no longer think of a way of resolving it.

The key change in the "new" browsers appears to be the computation of 
default tabindex order, as I suggested last night... however, the 
crucial change appears to be in the treatment of elements whose tabindex 
is explicitly set to -1. As you may recall, this is the strategy used in 
the Reorderer to explicitly remove the reordered elements from tabindex 
sequence.
It appears (at least in Firefox 3.6) that if focus is programmatically 
set onto an element with tabindex -1, the browser considers that the 
"focus location" is now in fact at the head of the document. This causes 
the next tabbed element to become the first default tabbable control in 
the window, leading to the environment-dependent "focus trapping" 
behaviour reported in the JIRA. Setting a tabindex of 0 removes this 
behaviour, but then of course causes each of the elements to be tabbable.

No "moral" way out of this problem is apparent. We could start to 
consider "immoral" ones such as embedding a hidden tabbable element 
after the reorderer for the purpose of explicitly throwing focus onto 
when we are trying to navigate out. From experience, efforts like these 
usually end up confusing screenreaders further. Likewise, "live" 
tabindex manipulations have been ruled out.

The only idea that comes to mind is to, on receiving "tab" whilst 
focused on an element, to programmatically throw focus back to the 
container and then try to synthesize a tab event directed at it. Given 
this problem only occurs on "modern" browsers, and that these are the 
ones that have proven slightly more amenable to "realistic event 
simulation" this has at least some chance of success...