596759 - Selecting a tab should focus its content

Status: RESOLVED FIXED

(Toolkit :: UI Widgets, defect)

Description

[Benedikt Pfeifer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100914 Firefox/4.0b7pre

commandDispatcher.advanceFocusIntoSubtree() seems to be malfunctioning in some cases. 

(See STR before going on here ->)

Going through the code brought me to 

http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/tabbox.xml#480

Checking the focused element before and after the call of advanceFocusIntoSubtree revealed that by following the STR the focused element is unchanged, while it normally updates.

--
I first noticed this bug on Instantbird, but was able to reproduce it on Firefox 3.6.9, a recent Minefile build and Thunderbird 3.1.3.

Reproducible: Always

Steps to Reproduce:
A:
  1. Go to Firefox Options->Advanced
  2. Select Encryption tab
  3. Cycle backwards through the tabs, either by mouse or keyboard
  4. Notice: how there is no focused UI element in the now selected tab.

  Using SPACE will toggle checkboxes or press buttons on a background tab in such a case.

B: 
  1. Go to Firefox Options->Advanced
  2. Notice: that no UI element is focused
Actual Results:  
See STR:Notice

Expected Results:  
Opening a tab should focus properly.
Going backwards through the tabs should also focused the right element (ie the one that would be focused if we went the other direction)

Happens atleast on Windows XP and Windows 7. Can't check on Linux/Mac OS X right now.

Comment 1

[Florian Quèze [:florian]]

I can reproduce on Mac too. I believe this is a problem in the tabbox binding (thus changing the component).

Comment 2

[Florian Quèze [:florian]]

Attachment: Patch

I haven't found any documentation for the advanceFocusIntoSubtree, but the "IntoSubtree" part of its name makes me believe it attempts to focus something in the subtree of the given DOM element. If this assumption is right, it should take the tabpanel as parameter and not the tab. The attached patch does that and gets the expect result.

Comment 3

[Benedikt Pfeifer]

I should have checked the DOM tree first before jumping to conclusions. I'm sorry for the confusion and it's nice to see that Florian seems to have fixed this problem so quickly.

Thanks a lot.

Comment 4

[Neil Deakin]

Comment on attachment 475787 [details] [diff] [review]
Patch

Seems ok.

Comment 5

[(no longer active)]

http://hg.mozilla.org/projects/cedar/rev/f9989ea04d35

Comment 6

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/efd33fb9ded4

Comment 7

[Tyler Breisacher]

I'm trying to verify this as part of Aurora Testday (although I might be a little late). When I follow part A of the STR, I notice that there IS a focused element on the current tab, which would seem to imply this is verified. But when I follow part B, there is still no UI element focused. So I'm not sure.

Mozilla/5.0 (Windows NT 6.1; rv:5.0a2) Gecko/20110506 Firefox/5.0a2