427838 - Tabbing skips elements after <xul:menulist> dropdown

Status: RESOLVED DUPLICATE of bug 399427

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Scott Turner]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_2; en-us) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13
Build Identifier: HEAD

When using the tab key to move focus between controls on a page the focus ring ends when a drop down list control is encountered, even if there are more controls on the page. 

Test case is included to demonstrate the issue.

Reproducible: Always

Steps to Reproduce:
1. Load test case.
2. Click on first text control.
3. Press tab key five times.
Actual Results:  
On fifth press of tab key focus is transfered to the address bar.

Expected Results:  
On fifth press of the tab key focus should transfer from the drop down list control to the next text control below the drop down list control on the test case page.

Comment 1

[Scott Turner]

Attachment: XUL test case that can be used to demonstrate the issue

Comment 2

[Tom Clowers]

Unable to reproduce on Firefox 2.0.0.13. [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13]

Comment 3

[Tom Clowers]

Reproduced in Firefox 3.0 Nightly [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040907 Minefield/3.0pre]

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Can we get a regression range? Is this XUL only?

Comment 5

[Ria Klaassen (not reading all bugmail)]

Dupe of Bug 399427 ?

Comment 6

[Scott Turner]

Ran test case against Firefox 2.0.0.13.

The tab skips over the drop down list, you can't put focus on the drop down list with the tab key.

Comment 7

[Scott Turner]

Turns out I've found a Mac bug in 2.0.0.13, works in Windows 2.0.0.13.

Comment 8

[Tom Clowers]

It looks like this was introduced between Gecko 1.9a7 and 1.9a8. It worked in Alpha 7 and is broken as it is today in Alpha 8.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7) Gecko/2007080210 GranParadiso/3.0a7
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8) Gecko/2007091216 GranParadiso/3.0a8

Comment 9

[Mike Schroepfer]

Given comment 7 and comment 6 I think we should move this off the blocker list

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

WFM on Mac, not on Windows. Taking.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This happens because of nsEventStateManager::GetDocSelectionLocation. The selection is collapsed, the anchor node is the menulist element, and the offset is 0. Because the start content is an element, GetDocSelectionLocation adjusts startContent to be the 'offset'-th child of the anchor node, which in this case is the menupopup, so it returns the menupopup and its frame as the current location of the selection. Then I think we restrict tabbing to the popup, don't find anything there, and start over in the chrome.

Comment 12

[Neil Deakin]

Sounds like it is indeed a duplicate of bug 399427 then.