Last Comment Bug 370396 - Control+Tab to an empty tab panel in a tabbox causes focus to leave the tabbox
: Control+Tab to an empty tab panel in a tabbox causes focus to leave the tabbox
Status: RESOLVED FIXED
: access
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86 Windows XP
: -- normal (vote)
: mozilla10
Assigned To: Neil Deakin
:
Mentors:
Depends on:
Blocks: focusnav focuseventa11y
  Show dependency treegraph
 
Reported: 2007-02-14 08:56 PST by Tom Brunet
Modified: 2011-10-03 16:54 PDT (History)
5 users (show)
enndeakin: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
focusbug.xul - Original test case (1.24 KB, application/vnd.mozilla.xul+xml)
2007-02-14 08:58 PST, Tom Brunet
no flags Details
focusbug2.xul - Two tabbox's to demonstrate additional oddities (2.15 KB, application/vnd.mozilla.xul+xml)
2007-02-14 08:59 PST, Tom Brunet
no flags Details
Fix to focus the tab if an element in a different tabpanel is focused (4.92 KB, patch)
2011-09-21 14:34 PDT, Neil Deakin
no flags Details | Diff | Review
Simpler patch (4.76 KB, patch)
2011-09-22 10:01 PDT, Neil Deakin
no flags Details | Diff | Review
Possible patch (1.29 KB, patch)
2011-09-22 12:45 PDT, neil@parkwaycc.co.uk
no flags Details | Diff | Review
Patch as suggested. Also added a test for an element outside a tabpanel and fixed the title. (5.59 KB, patch)
2011-09-23 09:26 PDT, Neil Deakin
neil: review+
Details | Diff | Review
a11y mochitest (4.21 KB, patch)
2011-09-29 23:03 PDT, alexander :surkov
mzehe: review+
Details | Diff | Review

Description Tom Brunet 2007-02-14 08:56:59 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 (CK-IBM) Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070213 Minefield/3.0a3pre

Focus behavior is inconsistent when there are empty panels in a tabbox.

Reproducible: Always

Steps to Reproduce:
1. Open the .xul file attached (focusbug.xul).  This file has a tabbox with three tabpanels.  The first tabpanel has a series of checkboxes.  The other tabpanels only have a description element (nothing focusable).
2. Use tab or click to put focus onto any of the checkboxes (e.g. Monday)
3. Press Ctrl+Tab or Shift+Ctrl+Tab
Actual Results:  
After Ctrl+Tab of Shift+Ctrl+Tab is pressed, focus jumps to the address bar.

Expected Results:  
Expected to see focus appear on the tab of the second panel "Tab2".  This ensures that subsequent Ctrl+Tab and Shift+Control Tab presses make sense.
Comment 1 Tom Brunet 2007-02-14 08:58:11 PST
Created attachment 255112 [details]
focusbug.xul - Original test case
Comment 2 Tom Brunet 2007-02-14 08:59:59 PST
Created attachment 255113 [details]
focusbug2.xul - Two tabbox's to demonstrate additional oddities
Comment 3 Tom Brunet 2007-02-14 09:10:26 PST
Some additional notes:

If the search box is open, focus will jump there instead of the address bar.  To fully characterize where focus is jumping, I have attached a second .xul file, focusbug2.xul.  Here are some scenarios:

1) Focus Monday in the first set of checkboxes.  Press control+Tab three times to return to "Tab1".  (Note that focus has not immediately left the tabbox).  Press tab.  Focus jumps to Monday of the second set of checkboxes rather than to Monday of the first set of checkboxes.
2) Open "Tab2" of the second tabbox and repeat case 1.  Focus now jumps past the second tabbox - to the find box or address bar.
3) Perform case 1 on the second tabbox.  Focus now behaves like the original defect report (focus immediately jumps away rather than waiting for tab key to be pressed).

Note in cases 1&2 that it is not jumping to the next item in the tab order because that would be the tab of the tabbox, and not its contents.
Comment 4 Aaron Leventhal 2007-02-15 20:36:59 PST
I remember that a similar issue used to bite us in the page info dialog -- there was one panel with nothing focusable, but that changed and this issue still remains.
Comment 5 Wayne DeAngelo 2007-02-21 08:09:50 PST
Confirmed bug on latest minefield.
Comment 6 alexander :surkov 2011-02-17 03:13:12 PST
Can you please check against Firefox 4?
Comment 7 alexander :surkov 2011-09-16 01:09:58 PDT
On trunk there's no DOM focus or blur events when switching to tab that doesn't have focusable content within tabpanel. I'd expect that tab should take a focus if tabpanel content can't accept it.

Enn, can you please take a look?
Comment 8 Neil Deakin 2011-09-21 14:34:19 PDT
Created attachment 561573 [details] [diff] [review]
Fix to focus the tab if an element in a different tabpanel is focused
Comment 9 neil@parkwaycc.co.uk 2011-09-21 16:14:39 PDT
Comment on attachment 561573 [details] [diff] [review]
Fix to focus the tab if an element in a different tabpanel is focused

Am I overlooking something or can you not just test for the focus being contained within the panel as distinct from the tabbox?
Comment 10 Neil Deakin 2011-09-22 10:01:35 PDT
Created attachment 561782 [details] [diff] [review]
Simpler patch
Comment 11 neil@parkwaycc.co.uk 2011-09-22 12:45:34 PDT
Created attachment 561841 [details] [diff] [review]
Possible patch

This is what I was thinking of... (-w diff)
Comment 12 neil@parkwaycc.co.uk 2011-09-22 13:48:50 PDT
Comment on attachment 561782 [details] [diff] [review]
Simpler patch

>                 let el = document.commandDispatcher.focusedElement;
>-                while (el && el != this.tabbox)
>+                while (el && el != this.tabbox && el != this.tabbox.tabpanels) {
>+                  if (el == selectedPanel)
>+                    return;
>                   el = el.parentNode;
>+                }
>                 if (el != this.tabbox)
>                   aNewTab.focus();
So, you confused me by introducing a new code path for the selectedPanel which had the same effect as the old code path for the tabbox, but for the tabpanels you simply reused the existing code path for a parent outside of the tabbox.

Probably the simplest code would result from early returning when either the tabbox or selectedPanel is reached, and exiting the loop when either the panels is reached or you run out of parents, and always focusing the new tab in that case.

The other alternative I would accept is to add the selected panel to both the loop condition and the focus condition instead of the early return.
Comment 13 Neil Deakin 2011-09-23 09:26:44 PDT
Created attachment 562062 [details] [diff] [review]
Patch as suggested. Also added a test for an element outside a tabpanel and fixed the title.
Comment 14 neil@parkwaycc.co.uk 2011-09-23 11:54:50 PDT
Comment on attachment 562062 [details] [diff] [review]
Patch as suggested. Also added a test for an element outside a tabpanel and fixed the title.

Your tests still seems to pass with my patch for some reason.
Comment 15 Matt Brubeck (:mbrubeck) 2011-09-29 20:43:44 PDT
https://hg.mozilla.org/mozilla-central/rev/8d2df2739eaf
Comment 16 alexander :surkov 2011-09-29 23:03:42 PDT
Created attachment 563663 [details] [diff] [review]
a11y mochitest
Comment 17 Marco Zehe (:MarcoZ) 2011-09-29 23:56:18 PDT
Comment on attachment 563663 [details] [diff] [review]
a11y mochitest

r=me, thanks!
Comment 18 alexander :surkov 2011-10-03 07:28:02 PDT
inbound land of a11y test https://hg.mozilla.org/integration/mozilla-inbound/rev/11d110b351c5
Comment 19 Matt Brubeck (:mbrubeck) 2011-10-03 16:54:51 PDT
https://hg.mozilla.org/mozilla-central/rev/11d110b351c5

Note You need to log in before you can comment on or make changes to this bug.