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.
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
