Tab can't move focus back to webcontent after focus is in browser chrome

VERIFIED FIXED

Status

()

P2
normal
VERIFIED FIXED
11 years ago
11 years ago

People

(Reporter: awuest, Assigned: enndeakin)

Tracking

({regression})

unspecified
PowerPC
Mac OS X
regression
Points:
---
Bug Flags:
blocking-firefox3 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [has patch][has reviews])

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko/2008030917 Minefield/3.0b5pre

Once focus is in browser chrome (e.g. location bar or search box), hitting tab moves focus only between location bar and search box, but not back to webcontent.

Reproducible: Always

Steps to Reproduce:
1. Click on webpage and tab until tab is in browser location bar
2. Tab forward to search bar
3. Tab again
Actual Results:  
Focus moves back to location bar.

Expected Results:  
Focus moves to webcontent.
(Reporter)

Comment 1

11 years ago
Setting accessibility.tabfocus_applies_to_xul to |false| fixes this. Not sure though why |true| should be the default value, especially since this pref is inaccessible to regular users.
Verified in Firefox and Thunderbird.

Same problem (and workaround) applies to Thunderbird. Even worse in Tbird though because the TO/CC/BCC fields and the Subject bar are part of the chrome and after typing the subject you can't TAB to the Message Body so you end up overwriting your TO field if you're not very careful... as I've learned at least three times this morning. :)
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko/2008030922 Firefox/3.0b5pre

Thunderbird version 3.0a1pre (2008030922)
(Assignee)

Comment 4

11 years ago
That sounds correct.(In reply to comment #1)
> Setting accessibility.tabfocus_applies_to_xul to |false| fixes this. Not sure
> though why |true| should be the default value, especially since this pref is
> inaccessible to regular users.
> 

That's correct. By default on Mac, only textboxes and lists are part of the taborder. Presumably, the page (you didn't specify a url) doesn't have any.

Or, you can change the setting in the Keyboard System Preferences panel.
Here is a URL to test: https://bugzilla.mozilla.org/show_bug.cgi?id=421810 ... that is this page right here. Additional Comments should be in the taborder; yet with recent builds, you can't tab down here any longer from the chrome areas unless you set XUL tabfocus to |false|. If this is supposed to be a default, then it just changed and didn't work like this previously and is going to confuse a lot of people... and in Thunderbird it is plain unusable behavior.

This should be a Core bug, BTW, not just Firefox.
Neil, looks like you landed patches for Bug 415704 on 3/7/08 at 08:33 PST. I take it that is where these problems cropped up. Is this working as planned? Really seems like a drastic change in user experience (especially for Tbird)... but guess a new release is the time to do that. :)
(Assignee)

Comment 7

11 years ago
Likely a regression from bug 415704. Will look into a fix for this.
Assignee: nobody → enndeakin
Flags: blocking-firefox3?
(Assignee)

Comment 8

11 years ago
Created attachment 308623 [details] [diff] [review]
seems that the tabfocusmodel should only be checked for controls

Otherwise, <browser> can't receive the focus.

Let's get this fix in and I'll see if I can create a test for this.
Attachment #308623 - Flags: superreview?(neil)
Attachment #308623 - Flags: review?(Olli.Pettay)
(Assignee)

Updated

11 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: regression
Comment on attachment 308623 [details] [diff] [review]
seems that the tabfocusmodel should only be checked for controls

This is OSX only, right?
Could you add a comment why this applies to controls only. And mochitest would be great. There are some tabbing tests already.
Attachment #308623 - Flags: review?(Olli.Pettay) → review+
(Assignee)

Comment 10

11 years ago
(In reply to comment #9)
> And mochitest would be great. There are some tabbing tests already.

There isn't a way of retrieving the 'Full Keyboard Access' setting from JS, so I don't think it's possible currently to write a test for this.

Updated

11 years ago
Attachment #308623 - Flags: superreview?(neil) → superreview+
(Assignee)

Updated

11 years ago
Attachment #308623 - Flags: approval1.9?
+'ing w/ P2.  Removing the approval flag request, so, go ahead and check in.
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P2

Updated

11 years ago
Attachment #308623 - Flags: approval1.9?

Updated

11 years ago
Whiteboard: [has patch][has reviews]
(Assignee)

Updated

11 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Updated

11 years ago
Depends on: 424482
(In reply to comment #11)
> +'ing w/ P2.  Removing the approval flag request, so, go ahead and check in.
> 

Patch was checked in 2008-03-13 07:07

Verified fixed with the steps to reproduce from comment #0 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040920 Firefox/3.0pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.