sairuh (rarely reading bugmail) Reporter
	Description • 22 years ago

possible regression due to bug 140612. found using 2002.09.19.08 comm trunk
builds. when the pref "accessibility.tabfocus" is set to 1 (tab only btwn
textfields within a page), password fields are left out of the cycle.

this is most evident on mac and linux, where the default for that pref is 1.

1. open the Preferences window (Edit > Preferences).
2. hit the tab key.

result: nothing happens since focus appears to be in la-la land.

3. click the Navigator category to explicitly set focus to that item, or click
on an item within the Navigator panel to bring it in focus.
4. try to tab around again.

results: still unable to move about using the tab key.

note: this will prolly be evident in other application windows, like the form
manager, mailnews 3pane, addressbook, etc.

	sairuh (rarely reading bugmail) Reporter
	Comment 1 • 22 years ago

making summary more broad to include other application windows.

is there anyway to modify the fix for 140612 so that only web pages are affected?

for example, here are a couple tests for mailnews (test this on linux or mac
--not a problem on win32):

case a
------
1. bring up the mailnews 3pane window (accel-2, Windows > Mail & Newsgroups,
etc.). initially focus will be in the thread pane, which has a darker outline to
indicate focus. do NOT hit any arrow keys, however.
2. hit tab.

actual result: focus moves to quicksearch textfield.
expected result: focus should move from thread to msg pane after hitting tab.

3. try to hit tab again.

actual result: focus doesn't move --stuck in the quicksearch textfield.


case b
------
1. bring up the mailnews 3pane window (accel-2, Windows > Mail & Newsgroups,
etc.). initially focus will be in the thread pane, which has a darker outline to
indicate focus.
2. hit the down arrow key. you'll notice that a msg in the thread pane will
become highlighted.
3. hit tab. focus moves to the msg pane, as expected.
4. hit tab again.

result: focus doesn't move to the folder pane --seems to remain in msg pane.

5. hit tab again.

result: focus moves to the quicksearch textfield.

if you continue to hit tab, you basically are "stuck" going btwn only the msg
pane and the quicksearch textfield (msg pane - msg pane again - quicksearch).

	sairuh (rarely reading bugmail) Reporter
	Comment 2 • 22 years ago

note about the mailnews 3pane tests in comment 1: for simplicity, the message
displayed in the msg pane didn't have textfields in it. (if it did, tabbing
would as expected move the cursor there.)

also affected: mailnews acct setup wizard, mailnews acct settings window.
(again, tabbing will go btwn textfields if there are >1 textfields present in a
pane.)

	David Tenser [:djst]
	Comment 3 • 22 years ago

This is not a major bug. It's not even a normal bug. It's a minor! :)

It still should be fixed though.

	sairuh (rarely reading bugmail) Reporter
	Comment 4 • 22 years ago

it's major accessibility issue, for those who rely more on keyboard usage for
navigation. (sure, for those who don't it might seem minor. :)

	Akkana Peck
	Comment 5 • 22 years ago

Easy workaround:
user_pref("accessibility.tabfocus", 7);
and you get the old windows behavior (tab stops at links and all form elements).

Bryner helped me look at this.  He thought it was probably because I wasn't
checking for nsXULAtoms::textbox.  But it turns out to be more complicated than
that: it turns out that something about the event state manager code gets
confused and doesn't look inside XUL iframes in the tabfocus != 7 cases, and
neither of us is sure why.  (I tried setting disabled=PR_FALSE for
nsXULAtoms::iframe, but that caused an infinite loop and we're not sure why
that's true either.)  Will continue to investigate.

	sairuh (rarely reading bugmail) Reporter
	Comment 6 • 22 years ago

another broken feature: when textfield-only nav is on, shift-tabbing through
page content no longer cycles --ie, focus won't go the the urlbar, and stops at
the document level. oddly, tabbing will cycle through all of the textfields over
and over (unlike shift-tabbing), but never makes it to the urlbar.

sample page: http://bugzilla.mozilla.org/query.cgi?GoAheadAndLogIn=1

	sairuh (rarely reading bugmail) Reporter
	Comment 7 • 22 years ago

as an "interim workaround" on the mac, i've filed bug 173201.

exposing the pref (bug 170871) might "ease" things. but this bug (169767) is
really the root of the problem.

	Aaron Leventhal Assignee
	Comment 8 • 22 years ago

This is definitely major now that we're going to expose this pref. Akkana, do
you have a plan for this?

	Aaron Leventhal Assignee
	Comment 9 • 22 years ago

I have a fix for this bug. The code that ignores tabindex for textfield-only
tabbing was broken. In any case, we should not ignore tabindex no matter what
the tabfocus pref is set to.

The things that are still tabbed to should still get tabbed to in the same
order.

	Aaron Leventhal Assignee
	Comment 10 • 22 years ago

Taking.

	Aaron Leventhal Assignee
	Comment 11 • 22 years ago

Accidentally closed bug. Reopening.

	Aaron Leventhal Assignee
	Comment 12 • 22 years ago

Also fixes bug 187303 -- couldn't tab to URL bar when textfield only tabbing
was set, due GetNextTabbableContent not treating those inputs as textfields.

	Aaron Leventhal Assignee
	Comment 13 • 22 years ago

Have patch.

	Aaron Leventhal Assignee
	Comment 14 • 22 years ago

checked in

	sairuh (rarely reading bugmail) Reporter
	Comment 15 • 22 years ago

bad news: tabbing in XUL windows/dialogs still only goes through textfields on
Mac. (tested in addressbook, prefs and find in page.) so, i'm reopening this bug.

good news: tabbing does cycle through the panes in the mailnews 3pane window.

	Aaron Leventhal Assignee
	Comment 16 • 22 years ago

I thought this bug was to fix the behavior when textfield-only tabbing was set.,
so that XUL dialogs were navigable.

What else was supposed to be done with this bug? What is supposed to be tabbable
that isn't?

	sairuh (rarely reading bugmail) Reporter
	Comment 17 • 22 years ago

bug 187303 fixes comment 6.

i guess i was hoping that fixing this bug would make the tabbing navigation pref
apply only to web content, not XUL as well...

	Simon Fraser [no longer active]
	Comment 18 • 22 years ago

I think it would be good to be able to control tab navigation in XUL, and in
content, independently. XUL tab navigation can definately follow OS prefs on OS
X, but that's not clear for content.

	Aaron Leventhal Assignee
	Comment 19 • 22 years ago

> bad news: tabbing in XUL windows/dialogs still only goes through textfields on
> Mac. (tested in addressbook, prefs and find in page.) so, i'm reopening this 
> bug.
Very strange, it should be going through everything.

> I think it would be good to be able to control tab navigation in XUL, and in
> content, independently. XUL tab navigation can definately follow OS prefs on OS
> X, but that's not clear for content.
Isn't that a bit too many prefs? Why should XUL be different from content? If
someone wants to limit what they tab to, then they're probably a mouse user who
can get to anything they need, whether XUL or content.

	sairuh (rarely reading bugmail) Reporter
	Comment 20 • 22 years ago

> Isn't that a bit too many prefs? Why should XUL be different from content?

yes, it would be too many prefs to control both XUL and web content tabbing
navigation. :)

my own preference would be to leave the control of XUL/chrome tabbing navigation
up to the OS controls --such as the Keyboard system pref in Mac OS X. having
pref UI in mozilla/nscp for tabbing nav in web content would still be good, though.

	sairuh (rarely reading bugmail) Reporter
	Comment 21 • 22 years ago

okay, i did a bit more digging around and found that what i've been seeing on
mac might be expected: i had originally seen comment 15 when using the classic
(aqua) theme on mach-o.

if memory serves me right, tabbing navigation is more or less screwed up in the
classic/aqua theme. i'm now looking at the CMF (commercial) build with the
modern theme, and tabbing (with the mac default pref set to 1) through the XUL
seems to work fine.

i'm going to double-check with modern in mach-o and other platforms, just to be
sure, but for now i'll re-resolve this. my apologies for the noise!

	sairuh (rarely reading bugmail) Reporter
	Comment 22 • 22 years ago

tested on with ("accesibility.tabfocus", 1); on linux rh8.0, win2k and mac
10.2.3. tabbing navigation within XUL (mailnews 3pane, addrbk, find, etc.).

works fine (goes to all widgets) when modern theme is used (either cfm/mach-o
builds for mac are fine). it also works fine in the classic theme on linux and
win2k. it's hosed on mac with the aqua/classic theme (known issue), regardless
of build method.

*zap*

thanks so much for fixing this!