351728 - focus progresses non-intuitively when tabbing from chrome to content

Status: NEW

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

Description

[Dietrich Ayala (:dietrich)]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1b2) Gecko/20060907 BonEcho/2.0b2

STR:

1. Load a feed, such as http://developer.mozilla.org/webwatch/?feed=rss
2. Give URL bar focus (or a tab, something outside of content
3. tab into content, note that the first focus-able item gets focus
4. repeat steps 2 & 3

Actual: The 2nd focus-able item in content gets focus. Repeat steps 2 & 3 again, and the 3rd focus-able item gets focus, etc, etc.

Expected: I expected that when tabbing from chrome to content, the first focus-able item would always get focus.

Comment 1

[Jesse Ruderman]

WFM Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060913 Minefield/3.0a1

Comment 2

[Dietrich Ayala (:dietrich)]

(In reply to comment #1)
> WFM Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1)
> Gecko/20060913 Minefield/3.0a1
> 

I can reproduce this with today's trunk nightly using the STR above.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a1) Gecko/20060913 Minefield/3.0a1

Maybe intel vs ppc issue?

Comment 3

[Mark Pilgrim (inactive)]

WFM on FF2 release.  Can you reconfirm on the original test platform?  Might be platform-specific, or might be fixed already.

Comment 4

[Mark Pilgrim (inactive)]

Sorry, I meant to say "WFM on Windows".  Please re-test on Mac.

Comment 5

[Mats Palmgren (inactive)]

Bug occurs in Firefox 2.0 on Linux.
Additionally, when the "Live Bookmarks" <select> is focused,
typing UP/DOWN both select a new value *and* scrolls the page.

Comment 6

[Dietrich Ayala (:dietrich)]

I can still reproduce with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1) Gecko/20061031 BonEcho/2.0

I also tried on Windows XP w/ 2.0 final, and could reproduce without fail.

Obviously my STR are not clear enough :)

Here's another shot:

1. Load http://developer.mozilla.org/webwatch/?feed=rss
2. Click in the URL bar
3. tab (focus goes to search box)
4. tab (focus goes to current tab)
5. tab (focus goes to document)
6. tab (focus goes to first focusable item in content)
7. start again at step 2, follow through step 6

In the first run, step 6 will focus the "subscribe to this feed using:" listbox. However, on the second run, step 6 will focus the "always use" checkbox. On the third run, etc, etc.

However, if you tab into the document further, and then run through steps 2-6 again, notice that the focus starts at the next item *after* whatever the last tabbed-to item was. But if you manually give focus to an item, say halfway down the page, and then run through steps 2-6 again, you'll see that focus is given to the next item *after* whatever the last tabbed-to item was (and *not* to the item after the item that was last manually focused).

Basically, whatever keeps track of the last-tabbed-to-item-in-content is not getting updated when focus leaves content. Maybe this is intentional, but it seems counter-intuitive to me :)

Comment 7

[Aaron Leventhal]

It's actually designed to behave like IE. Basically it remembers your previous focus position in content and tabs relative to there. So, if you do something in the UI and want to get back into content you don't lose your place.

I'm not sure when that was decided, but Gecko has been like that at least since 2001.

BTW this is really a Core bug, if we decide to make a change.

Comment 8

[Dietrich Ayala (:dietrich)]

(In reply to comment #7)
> It's actually designed to behave like IE. Basically it remembers your previous
> focus position in content and tabs relative to there. So, if you do something
> in the UI and want to get back into content you don't lose your place.
> 
> I'm not sure when that was decided, but Gecko has been like that at least since
> 2001.
> 
> BTW this is really a Core bug, if we decide to make a change.
> 

It doesn't make sense to me, but I'm neither a typical accessibility consumer nor a subject-matter-expert. Seeing as the behavior is intentional, feel free to WONTFIX this bug :)