A MovieClip is supposed to get the focus when clicked by the mouse as long as tabEnabled is true.
I've attached a stage listener for the FocusEvent.MOUSE_FOCUS_CHANGE event, it fires, it indicates the focus is leaving the stage and going to the clicked object, but in the subsequent mouse_down handler that runs immediately afterwards, the stage.focus is still null. The object does not receive focus as expected, as the focus change event indicated it should have, so it does not receive keyboard events, and focus remains on the object (e.g. a textfield) that previous had the focus. Something is wrong.
It works properly in simple display lists, but it's not working properly in deeper/nested ones, so it may be difficult to reproduce.
-------------------
There is also a bug in the way Flash handles tab key focus changes, and this one is extremely easy to reproduce.
1. Create an input TextField, and convert it to a symbol so that it's positioned at 0,0. Name the container "container".
2. Set container.tabEnabled to true.
3. Inside container, at some other coordinate like 100, 100, draw a box, convert it to a symbol, and set it's tabEnabled property to true as well.
4. Press the tab key and notice that the focus will go from the container to the box you drew, but it will skip over the TextField (you can see the focusRect appearing around the box, then around the entire container, but then intstead of going to the textfield, it goes back to the box).
That behavior is incorrect. Proof? It only occurs when the TextField is placed at the origin 0,0, or is the uppermost/leftmost object in the container, effectively giving it the same upperleft visual coordinates as the container. If you shift it at all (e.g. by swapping its position with the box, or simply drawing a graphic that's more to the left or above it), then the TextField will be included in the focus loop. This at first looks like a bug caused by the way Flash's default tab order mechanism involves the coordinates of the TextField. When two tabEnabled objects occur at the same coordinates, it should not skip all but one of them, but that's exactly what the player is doing. I remember reading long ago that the "Flash player uses a formula to calculate the tab order of editable text fields and buttons that is essentially left to right and then top to bottom. The formula is k_x * x + k_y * y." What's strange is that this issue occurs exclusively for the TextField. For example, if you just swap the position of the box and the textfield, you'd expect the box to get skipped like the textfield did, but it doesn't skip the box.TextField
Furthermore, TextField is not respecting the tabEnabled property when it comes to being clicked by the mouse. Whereas other objects with tabEnabled = false will not acquire the focus, TextField takes the focus in spite of tabEnabled being explicitly set to false on dynamic/non-input fields. This behavior is totally inconsistent, and wrecks the potential for handling mouse_focus_change events. For example, one logical way to override mouse focus change, is to check whether the object potentially receiving the focus has tabEnabled = true, and if it does not, then scan for the first parent with tabEnabled = true and assign focus to that. This would of course conflict with the default/inconsistent focus change behavior where TextField would receive the focus when clicked in spite of its tabEnabled being false. And the override would be fine, except that if you do prevent the TextField from receiving the focus, then any HREF "event:" TextEvent.LINK events will not fire. This is ridiculous. The player really needs to be more consistent.