FLUID-3590 investigatoins

[Antranig Basman]

Justin has put together an excellent breakdown of the various subcases 
of our last release blocker, FLUID-3590 which relates to the failure of 
keyboard navigation wrt. the Reorderer. Interestingly this as far as I 
can see appears to be an "emergent" issue - not relating to a regression 
in our codebase but a change in strategy by browsers released after our 
original implementation of the Reorderer. In particular, Firefox 3.6 
(but fascinatingly, *NOT* Firefox 3.5) and Webkit 4 browsers treat the 
case of tab-key navigation sufficiently differently to break our 
implementation.

I haven't spent very long today looking into this issue but enough to be 
able to usefully report some initial findings. My best understanding of 
the issue so far is that it is caused by a change in the default 
navigation order through the browser controls via the tab key. If I were 
to guess, I would say that on the two "newer" browsers, navigation takes 
in elements with higher tabindex earlier than before, but there also 
seems to be some interaction with containment as well. Not fully 
investigated yet, but it seems that all of the "variation" seen in 
Justin's table can be explained by the variation of tabindex values in 
the markup surrounding the demos. For the demos which have a "tabindex = 
1" hidden div containing instructions, this element is the one which 
gets focus immediately trying to tab out of the reorderer. For the demos 
without this, focus simply becomes trapped permanently inside the 
container, since the effect of trying to tab out of the container has 
the effect of immediately focusing the container itself, which returns 
focus to the first element.

I remember that Colin and I debated our strategy for "forward and 
reverse tabbing" through selectable contexts as early as 2008, but it 
looks like the time has come to bite some tougher bullets if we want to 
maintain it. My best guess is that the only feasible strategy for 
maintaining this idiom across newer and older browsers is a "dead Man's 
X" approach as seen currently only in the InlineEdit integrations. A 
draft outline of a strategy:

i) initially detect a "putative focus leave event" by means of setting 
off a "dead Man's blur" timer on receiving a blur event from an 
individual selectable item.

ii) if within the short timeout, focus has not been received on ANY of 
the controlled items (including the container itself, as well as any of 
the other selectables) conclude that focus has truly left the container 
- in this case, "arm" a flag such that if focus is received on the 
container after this period, transfer focus onto the "selected item" as 
per our ancestral algorithm. OTHERWISE

iii) if focus is received on the container itself during this period, 
conclude that navigation is in progress out of the container, and defeat 
the flag mentioned before (currently named 
"selectionContext.focusIsLeavingContainer").

If this algorithm truly works, it might even simplify the keyboard-a11y 
logic slightly since we will now have a common way of detecting this 
condition rather than relying on explicit detection of the Shift-TAB 
case signally backward navigation.

This is all somewhat speculative since these focus-related issues can 
take some time to interpret. But I thought I would leave this summary 
before turning in tonight in case anyone is thinking of working on this 
issue in the meantime, since I believe it is the only one holding up the 
upcoming release.

I've attached a couple of patches to FLUID-3590 which revitalise our old 
"DebugFocus.js" utility which has drifted a bit since the last time it 
was dusted off with respect to its jQuery support. Note that the 
argument to "document.ready" is now provided itself provided with an 
argument by jQuery which confuses our old impl.

http://issues.fluidproject.org/browse/FLUID-3590

Until the Day Dawning,
Antranig.