#10272 closed defect (fixed)
editor: can not shift tab out of editor toolbar when text is selected in editor in IE
Reported by: | Becky Gibson | Owned by: | bill |
---|---|---|---|
Priority: | high | Milestone: | 1.4 |
Component: | Dijit | Version: | 1.4.0b |
Keywords: | Cc: | Jared Jurkiewicz | |
Blocked By: | Blocking: |
Description
Load http://archive.dojotoolkit.org/dojo-2009-11-05/dojotoolkit/dijit/tests/editor/test_Editor.html in IE 6, 7 or 8. Go to the first editor example that has a toolbar. Select some text within the editor via the keyboard or mouse. Press shift-tab to move focus to the toolbar, press shift-tab again and focus should move the to the input before the editor - in IE 6 and IE 77 focus does not move. This works correctly in FF 3.5 and Safari 4.
Not sure if this is an issue with the editor component itself or the dojo editor.
Change History (8)
comment:1 Changed 11 years ago by
Cc: | Jared Jurkiewicz added; jared removed |
---|
comment:2 Changed 11 years ago by
Milestone: | tbd → 1.4 |
---|---|
Owner: | set to bill |
Status: | new → assigned |
comment:3 Changed 11 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
(In [20769]) Fixes for tabbing in and out of a Toolbar:
- set tabIndex=0 before focusing on a button to avoid IE bug where it jumps to the wrong node when tabbing away from the button (I'm not sure if tabIndex needs to be set before focus, or just before tabbing away.)
- don't merely set tabIndex=-1 directly on DOM nodes because the setting will get overwritten when Editor's onNormalizedDisplayChange() calls button.attr("disabled", bool). That's because _FormWidget._setDisabledAttr() sets the focusNode.tabIndex.
- code simplifications
Fixes #10272 !strict although it needs more testing.
comment:4 Changed 11 years ago by
Correction to above comment:
I don't think it's an IE bug, it's just that tabbing away from a node with tabIndex=-1 has undefined results. Browsers determine the next element in the tabbing order based on the current node's position and tabIndex. For example, if the current node has tabIndex=2 then the browser looks for the next node with tabIndex=2, and if no such nodes exist then moves on to tabIndex=3, etc.
With that in mind I'll check in a better fix.
comment:5 Changed 11 years ago by
(In [20776]) More changes for tabbing in and out of toolbar:
- Make ComboButton handle left/right arrow keys for switching between left and right half of ComboButton?. Previously was handled by _KeyNavContainer. Removed unneeded focusFocalNode(), hasNextFocalNode(), focusNext(), hasPrevFocalNode(), focusPrev(), and getFocusNodes() methods. ComboButton?.focus(str) takes optional string parameter to control focusing on left ("start") or right "end" part of button.
- Set currently focused button's tabIndex to container's tabIndex, so tabbing off of the button works correctly even when container has a non-0 tabIndex
- Set the button's tabIndex when it is focused by mouse, not just when focused by keyboard
Refs #10272 !strict
comment:6 Changed 11 years ago by
comment:7 Changed 10 years ago by
(In [24102]) Fix problem on Toolbar buttons where IE doesn't display focus border (after tabbing into the toolbar, or using the arrow keys to navigate).
IE doesn't display focus border if you focus() a node with tabIndex=-1. Thus, fixing problem by setting the button's tabIndex to 0 before focusing the node.
This problem didn't occur in 1.5 because after focusing the node, _KeyNavContainer set the node's tabindex to 0 and then bumped the node by setting node.className in _CssStateMixin._setStateClass() But, after [23228] _KeyNavContainer's _onFocus advice runs after _CssStateMixin's _setStateClass() call (triggered by the watch() on "focused".
I'm working on a fix for this. The problem seems to be because when Toolbar gets focus, it moves focus to a child button with tabIndex=-1, and then tabbing away from that button confuses IE.