(short version: If nested DisplayContainers have a mix of tabChildren states, tabbing from a child at the bottom will yield unwanted results)
We’re porting our Print product from as2 to as3. In that process I had implemented tab navigation in a table element. This was a total nightmare – tab worked beautifully in the flash standalone player, but not in a browser. In both IE and Firefox, hitting tab would change focus to the addess bar of the browser.
Why why why? I read the documentation for the FocusManager as I suspected it had something to do with this – focusManager was a tricky beast in AS2. No answers, so I started reading the actual code in focusManager.as (kudos to Adobe for allowing us to view and debug in the mx.* source code). No answers there either, but a lot of interesting code.
Finally I decided that I needed a more controlled environment to check how the flashPlayer handles tabbing. I created a very simple actionScript project with two editable textFields. This revealed that FP will move focus with tab till it’s at what it perceives as the last element. The tabbing will move focus to the address bar. Next tab will move it back to the first tabbable element in the flash.
So far, so good. But this didn’t answer why I lost focus in my app on every tab. After more hair pulling, I suspected that the tabChildren attribute on DisplayContainer could influence tabbing. I created four Sprite instances, nested them and placed an editable textField at the bottom. Setting all Sprites to tabChildren true or false both gave the correct result, i.e. focus went to the next flash object, not to the browser. But (and this is the finale) if there was a mix of tabChildren=true, tabChildren=false and tabChildren=true, tabbing from textField would send focus to the address bar. An order of true, true, false, false would work – it was the mix that gave the bug.
After that it was easy to just ensure that the whole chain of DisplayContainers above my textField had tabChildren set to true.