Following on from my previous posting reporting on focus handling issues provoked by our recent jQuery
upgrade that I reported on at
http://fluid.2324889.n4.nabble.com/Breaking-changes-in-recent-versions-of-jQuery-focus-handling-td8867.html
I have what is hopefully a final round of reports and also in this case queries.
After the merge of both https://github.com/fluid-project/infusion/pull/448 and
https://github.com/fluid-project/infusion/pull/437 for http://issues.fluidproject.org/browse/FLUID-5241 and
http://issues.fluidproject.org/browse/FLUID-5204 http://issues.fluidproject.org/browse/FLUID-5185 we have a
framework image which is basically up to date and working, but the combination of the two pull requests have
precipitated a failure in our test cases for keyboard-a11y-tests.js on all versions of IE.
In some sense the failures are "benign" in that the real implementation is working on this platform, but
they raise a few philosophical and practical issues that we would need to talk through. This is following on
from an end-of-day conversation archived at https://botbot.me/freenode/fluid-work/2014-02-06/?tz=America/Denver
The root cause is a familiar one, just better understood - the recent version of jQuery now only relays
"faithful" focus messages resulting from the browser rather than "fake" ones as it has for many years, which
used to synchronously relay attempts to trigger focus events into listeners for them.
This creates particular problems for our keyboard accessibility tests, since these rely on focus triggering
not only in the test cases, but also in the implementation. To recap, the "selectable" widget, when
receiving focus on a "container" node, responds my immediately throwing focus onto the first of a set of
managed container elements - this shortcut saves one interaction cycle for those using the keyboard or other
equivalent.
Part of the work for FLUID-5185 involved progressively rewriting our tests in the new "asynchronous style"
for which there seems now little alternative for keyboard-a11y. Our alternatives for the other tests might
have involved the use of jQuery.triggerHandler which was jQuery's recommendation for restoring the old
framework behaviour - and is the approach used, for example, in the jquery.simulate plugin:
https://github.com/jquery/jquery-simulate/blob/master/jquery.simulate.js - however, it would seem
inappropriate to import this whole plugin as part of the implementation strategy of another widget, and it
even seems inappropriate (to me) to try to restore the old "event fakery" by calling $.triggerHandler() as
part of the implementation of keyboard-a11y - if for no other reason that this will restore odd pathologies
such as being notified of focus events twice (once for the fake handler trigger, and once for the real focus
event). However, I'm open to, say, improving our existing jqUnit.simulateFocus method (currently in
jqUnit-browser.js, as part of the FLUID-5185 work) to being a first-class core framework method which would
restore the old jQuery behaviour and allow us to retain our old tests.
The other option is to accept the variability of focus relay across browsers as "part of the environment"
and rewrite all the tests in keyboard-a11y-tests.js to use the IoC testing framework which was designed
precisely to abstract over asynchrony issues of this kind. This will further reduce the viability of these
tests from the point of non-Infusion users but I believe this counts for very little at this point (see below).
So either A) upgrade jqUnit.simulateFocus to a standard core utility which we use everywhere, OR B) fall
back on standard $.focus() everywhere and rewrite the keyboard-a11y tests to use IoC testing.
The philosophical issue relates to what we believe our tests assure... and how "portable" we expect their
effects to be. I think there are good grounds for wanting tests of our browser widgets to be "as faithful as
possible" wrt their browser environment, given part of their purpose is to reduce the burden of acceptance
testing. However, tests which have environmental dependencies are philosophically dubious, and it might be
worth starting to think more clearly about the roles of our different tests and perhaps separating out those
tests into a different area which are expected to execute differently (whilst still passing) on different
browser platforms.
The other issue relates to our keyboard-a11y plugin itself. I think it's fair to say that if we were to
write this today, we would not write it in the way we did in 2008. I think it's become clear to us that the
"instance-free, model-free" idiom for jQuery UI plugins doesn't meet our goals as a community, and one sense
in which this became apparent just now was the way in which our plugin doesn't expose the events and model
state that we now expect from a Fluid component makes it harder to write credible and reliable tests for it.
I propose that for Infusion 2.0 we eliminate both the "special status" of jquery.keyboard-11y.js itself
(since it's perfectly clear after 5 years that it remains of no interest to anyone in the wider jQuery
community) and its implementation in favour of producing a standard model-based and framework-aware version
of it. I think this will become even more important as with the merging of the FLUID-3674 branch and
subsequent work we will be working in a more and more "model-driven" idiom.
Cheers,
A.
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
