Closed Bug 169767 Opened 19 years ago Closed 19 years ago

focus/tabbing broken in application windows (xul) when textfield-only option is set

Categories

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

defect
Not set
blocker

Tracking

()

VERIFIED FIXED
mozilla1.3beta

People

(Reporter: bugzilla, Assigned: aaronlev)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(2 files)

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.
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).
Keywords: nsbeta1, regression
Summary: focus/tabbing broken in Preferences when textfield-only option is set → focus/tabbing broken inapplication windows when textfield-only option is set
Severity: normal → major
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.)
This is not a major bug. It's not even a normal bug. It's a minor! :)

It still should be fixed though.
Severity: major → minor
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. :)
Severity: minor → major
Summary: focus/tabbing broken inapplication windows when textfield-only option is set → focus/tabbing broken in application windows when textfield-only option is set
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.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2beta
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
Summary: focus/tabbing broken in application windows when textfield-only option is set → focus/tabbing broken in application windows (xul) when textfield-only option is set
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.
Target Milestone: mozilla1.2beta → mozilla1.3beta
This is definitely major now that we're going to expose this pref. Akkana, do
you have a plan for this?
Blocks: focusnav
Attached file Test case
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.
Taking.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Accidentally closed bug. Reopening.
Severity: major → blocker
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Also fixes bug 187303 -- couldn't tab to URL bar when textfield only tabbing
was set, due GetNextTabbableContent not treating those inputs as textfields.
Attachment #110530 - Flags: superreview?(bryner)
Attachment #110530 - Flags: review?(akkana)
Blocks: 173201
Attachment #110530 - Flags: review?(akkana) → review+
Attachment #110530 - Flags: superreview?(bryner) → superreview+
Have patch.
Assignee: akkana → aaronl
Status: REOPENED → NEW
checked in
Status: NEW → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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?
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...
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.
> 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.
> 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.
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!
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
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!
Status: RESOLVED → VERIFIED
No longer blocks: 173201
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.