Closed Bug 66285 Opened 24 years ago Closed 22 years ago

Spec for keyboard navigation (tabbing) within form fields, images, links etc

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 140612
Milestone:
mozilla1.2beta

People

(Reporter: orders, Assigned: akkzilla)

References

Details

(Keywords: helpwanted, topembed, Whiteboard: [SPECBUG] [KEYBASE+]) 

When using the tab field to change focus, there should be a way to only target
text fields rather than any hot-spot. When trying to tab between fields in a
form, having to tab through every link as well is rather tedious on some pages.
My appologies if there's already a way around this but none of the modifier keys
I tried seem to work.
Summary: Using Tabs to Change Focus Should Be Able To Only Target Text → Using tabs to change focus should be able to only target text
Reporter please read, http://www.mozilla.org/quality/bug-writing-guidelines.html
and comment with some more information about the bug, including what Mozilla
build your using, and a testcase or example page where this happens. Thanks in
advance.

Whoops my bad about the last comment. Going ahe and marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Using tabs to change focus should be able to only target text → [RFE] Using tabs to change focus should be able to only target text
-> xpapps
Assignee: asa → ben
Component: Browser-General → XP Apps: GUI Features
OS: Mac System 9.x → All
QA Contact: doronr → sairuh
Hardware: Macintosh → All
->keyboard nav...
Assignee: ben → alecf
Component: XP Apps: GUI Features → Keyboard Navigation
Summary: [RFE] Using tabs to change focus should be able to only target text → [RFE] Using tab to change focus should be able to only target form fields
mpt, what do you think? Shift-tab goes backwards, how about ctrl-tab? I don't know.
I'm sure no one wants this, but how about ctrl->, ctrl-<. I'm almost certain 
this isn't l10n friendly, but it is logical for us-EN.

Tab and f6 already have enough overbindings please avoid them.
How about ctrl-<four arrow keys> for navigating between links (I'm not quite 
sure how you'd go about making it possible to go up/down between links via 
keyboard but it would be really nice!), tab for changing form fields. Tab is 
commonly used for data entry, arrows are commonly used for navigation.

I should have explained why the arrow keys aren't available. ctrl+left => word 
left, ctrl+right => word right.
cc'ing akkana and brade to see if they have any opinions here...
I would love to make tab only target form fields, like it did in past versions
and most other apps.  I understand the need to make links keyboard accessible --
that accessibility is very important -- but it's a shame if it has to come at
the price of reduced usability for ordinary users who don't need the special
accessibility features, as it currently stands.  If we could have some other key
for navigating among links, and use tab for what it always used to mean (tabbing
between form fields) that would be a big win.

How about alt-arrow keys?  Those don't seem to do anything now, at least on linux.
On a Mac, both <command><arrow> and <command><bracket> move backward and forward
in history. Is it really necessary to have two commands for a single function?
Perhaps one of those could become keyboard nav.

Also, <option><arrow>, which is word left/right on a Mac, (<control><arrow> on a
PC?) is only valid while the focus is in a text field. I realize it may be a
somewhat confusing design, but allowing <option><arrow> to have a different
effect when the focus is NOT in a text field might not be so terrible. Of
course, then you'd need a way to focus OUT of a text field from the keyboard.
There is currently no way to get out of a multi-line/scrolling text field from
the keyboard..
futuring until we have a decision one way or the other
Since we have no specified behavior yet, this isn't really even a bug, and
should probably discuss this on the newsgroups.
Priority: -- → P3
Target Milestone: --- → Future
sorry alecf. Giving this to asa to puzzle over.

A new bug should be filed once we settle on a specification.

the cmd-{ and cmd-left issue is due to macos reserving cmd-left [for os 
level language switching].
Assignee: alecf → asa
Summary: [RFE] Using tab to change focus should be able to only target form fields → Need Specification for keyboard navigation to change focus within form fields
Whiteboard: [SPECBUG]
Target Milestone: Future → ---
Here are some related things we need (at least for accessibility) that may
affect this RFE:
- We need directional navigation, where the user can navigate to the next item
above, below, to the left or the right of the current item. Perhaps Alt-shift
arrow key or something like that.
- There needs to be a way to navigate to images that have no links, so that
keyboard only users can find the conext menu.

Therfore, the directional navigation, and logical order (Tab/Shift-Tab)
navigation would normally be used to navigate only to form elements, but
sometimes also to links, and occasionaly to any image as well.

What would people think about a 3-way toggle for keyboard navigation - 1) form
elements only, 2) form elements and links, 3) form elements, links and images.

We can change the default behavior to #1, but this might confuse a lot of users
accustomed to the old scheme.

Aaron
mpt complained when i suggested a toggle between chrome and html bindings. 
[what should ctrl-q do? normally quit, but w3 asked that webpages be able to 
have access keys and stuff so if we support w3 ctrl-q might only sometimes 
quit.]

I can't imagine him being supportive of a mode that enables the stuff you're 
asking for. However I am in favor of what you're describing.

Personally I don't mind ctrl+key; ctrl+shift+key is reserved for selection 
navigation. Alt+Shift+key would be a real pain if i only had one finger, even 
with sticky keys.
I'm not averse to having persistent prefs (as opposed to Timeless's proposed
vi-like chrome/content ACCESSKEY toggle) for accessibility reasons -- I filed bug 
58997 for an option to allow images and other objects to get keyboard focus, for 
the very reasons Aaron described in this bug.

However, I think `directional navigation' is a non-starter, because we don't 
really have any keys to spare. (Shift+)Alt+Tab is for previous/next window. 
(Shift+)Ctrl+Tab is for previous/next of {content, address field, sidebar} (bug 
30864). Ctrl+Left and Ctrl+Right are for previous/next word. Alt+Left and
Alt+Right are for previous/next page. Alt+Up and Alt+Down are for opening/closing 
the autocomplete menu (bug 63320 and bug 60861). And if any combination of more 
than two keys was chosen (e.g. Alt+Shift+Left and Alt+Shift+Right), the 
difficulty of activating it would make its implementation as an accessibility 
feature somewhat ... ironic.

Meanwhile ... Internet Explorer 5 for Mac OS has an option to toggle between 
allowing all links and form controls to have focus, or just text fields
<http://www.chasms3.com/macie5/mie5pref1.htm>. This is because in native Mac GUIs 
(and in 4.x for Mac OS), you can only focus text fields and list controls, not 
any other kind of control. This results in better usability for people in general 
(since it encourages mousing, which is faster than keyboarding), but it makes 
life very difficult for disabled people (those who can't use a mouse, that is) in 
particular.

Perhaps a similar option could be implemented in Mozilla. Mac-OS-specific note: 
Whichever option you choose in Internet Explorer, you can use Option+Tab to do 
the other thing (this couldn't be done in Mozilla's XP implementation since
Alt+Tab etc is already taken). But IMO Option+Tab provides a greater usability 
win as a shortcut for switching windows than for overriding a pref, since Mac OS 
is rather poor at switching windows itself (bug 53505) and switching windows is a 
much more common action. However, on Mac OS only, this option (if implemented) 
should apply to chrome as well as to content (for the same accessibility 
reasons).

The main concern I have with Aaron's proposal is how users would tell which mode
they're in.  We could have something in the chrome that changes to indicate
state, but making one that was easy to understand might be hard (and it wouldn't
help blind people).  There should be a clear state indication somewhere; I
forsee users hitting the key combination by accident, and "I don't know what I
did, but now tab doesn't work right and I have no idea how to fix it!"
> The main concern I have with Aaron's proposal is how users would tell which
> mode they're in. 
We could have an indicator in the commandbar/statusbar. Windows w/ MSAA or 
screenreader announces state changes, and when a window activates will describe 
its state (which could include this attribute 'arrows navigate 
elements'|'arrows navigate form','commmands handled by &branding;'|'commands 
handled by web site %site%')
> We could have something in the chrome that changes to indicate state,
> but making one that was easy to understand might be hard
> (and it wouldn't help blind people). 
As long as it's easy to toggle and it can announce toggle changes (distinc 
audible tones/notes/sounds) that should work.
> There should be a clear state indication somewhere;
> I forsee users hitting the key combination by accident,
> and "I don't know what I did,
> but now tab doesn't work right and I have no idea how to fix it!"
Yes we'll probably need to have help windows that appear once and make sure 
users understand what the states are, how to use them, and how to change back 
to normal [of course there would be an option to never show again].
I have to disagree with mpt's point about directional navigation not being
viable because the keystrokes being too difficult for disabled users. There is
not one kind of disabled user. Not all disabled users are physically disabled.
Blind users would benefit by being able to skip through many of the links. In
addition, Alt-Shift combinations are done quite easily by physically disabled
users with sticky-keys, where a user can type alt, then shift and then the arrow
key all with one finger or a mouth stick. It's still far fewer keystrokes than
tabbing through all the links on the leftmost navbar to get where they need to
be. So it's actually much easier data entry, not harder. The idea of directional
navigation comes from discussions with actual disabled users, it's not a random
idea.
Yeah, ok, that makes sense, but directional navigation should really be in a 
different bug.

I've been doing some drawing ...

| Category:             Accessibility :::::::::::::::::::::::::::::: |
| +-------------------+                                              |
| |=General===========| Use Tab and Shift+Tab to navigate between:   |
| |=Display===========| [/] _text fields and list boxes              |
| |  Languages        | [/] other control_s                          |
| |::Accessibility::::| [/] _links                                   |
| |  Fonts            | [ ] ima_ges and plugins                      |
| |  Colors & Effects |                                              |
| |  Multimedia       | [ ] Show _caret for keyboard selection       |
| |  Filters          |                                              |
| |  Scripts          | Style sheet _folder: ...styles/ (Choose ...) |
| |  Privacy&Security | Defa_ult style sheet: [Aquamarine        :^] |
| |                   | [/] Allow documents to use _other styles     |
| |                   |                                              |
| +-------------------+ :::::::::::::::::::::::::::::::::::::::::::: |

no, this is the right bug.

I shouldn't need to go into prefs ~5 items deep to get bindings so i can 
navigate just forms or just links.  I need to do both rather frequently.  It is 
true that I am likely to read a page first and then play w/ forms but i don't 
think that helps anyone.
mpt: in general I like you're drawing (p.s. offtopic did you see the ascii cam
article on slashdot?)
I might have am conflict of interest here - this might be one of those times
where the needs of disabled users conflicts with the regular user.
I think disabled users will want to switch back and forth between tabbing just
betweeen form fields vs form fields + links quite often. I don't want to get
into a situation where people feel like we're making design decisions that are
good for disabled users but not everyone else. On the other hand, some kind of
hot key or quick popup menu for accessibility settings would be really helpful.
I'm not going to push one solution, as long as there is some way to conveniently
get to the mode you want, I think that's a big plus.

I'm afraid this general issue will come up again, where the disabled users will
want some quick key combination to change an accessibility setting on the fly,
rather than go into prefs. Any ideas? Perhaps a hotkey to bring up accessibility
prefs only, and when enter is pressed they're back in the content? Just
brainstorming here - love to hear other people's thoughts.
I'm not sure about PC's since they don't really have an <option> key. But on the
Mac, I'd like to see:

Either <option><command><left/right/up/down> or <command><arrow> for link navigation
<tab> for form navigation
<control><tab> for forward direction link navigation
<option><command><tab> for element navigation. As in, changing focus between
search/url bar and frame elements/window sections.

I think that <option><command><arrow> for link navigation is okay becaus of the
usage pattern. For the most part you navigate or you type - you don't usually
navigate a link, then type, then navigate..etc. So, turning on <option><command>
with sticky keys or equivalent is not that big a deal.

Additionally, having some way of getting out of multi-line text fields is
important (and addressed by <option><command><tab> here.

Another potential problem - when a text field/box is active, you can not use the
page-up/down or arrow keys to scroll the window. This means that if you are
trying to fill out a form, you have to get out of the text field to read the
text below it if your window isn't large enough.

Not being able to pgup/pgdn when a single-line textbox has focus is bug 27771.  
There's also some discussion about multi-line textboxes (textareas) there.
Summary: Need Specification for keyboard navigation to change focus within form fields → Need Specification for keyboard navigation to change focus within form fields (was: [RFE] Using tab to change focus should be able to only target form fields)
Summary: Need Specification for keyboard navigation to change focus within form fields (was: [RFE] Using tab to change focus should be able to only target form fields) → Need Specification for keyboard navigation within form fields
Summary: Need Specification for keyboard navigation within form fields → Need spec for keyboard navigation (tabbing) within form fields within form fields and among document elements including images and links
Blocks: 2083
Blocks: 47282
1) IE tabs into and out of multiline text fields with the tab key. It does not
insert tabs.
2) We need to make the browser keyboard accessible. Tabbing is the way all other
form controls work.

I say we make it work like IE, tab and shift-tab go in and out of text areas. I
don't see tabbing in text areas as a major loss and it solves our accessiblity
requirement with a standard approach. If someone feels the need to make it a
pref, go nuts.

This is one case where I'm comfortable loosing 4.x behavior for something more
standard.
Saari, that's not this bug, that's bug 2083. And people should not `go nuts' 
making prefs for this, unless it is needed for accessibility reasons (e.g. 
tabbing to images and plugins) or platform parity reasons (e.g. not tabbing to 
all controls by default on Mac OS).

mpt THIS BUG is for talking about navigation. I blocked that bug because it's 
an implementation bug.

ctrl+T doesn't seem to be bound in navigator or composer. Could we make ctrl+T 
insert a tab and then have tab be purely navigational?
.
Assignee: asa → alecf
I could live with ctrl-T inserting a tab because that indents the current line
in vi.  In fact, I would like it if all the applications I use had a vi
interface.
Agree with saari's approach - tabs should not insert tabs in form fields as a
default. This is a 10% vs 90% case in terms of usage. Also since most form fill
applications and browsers ouitside N6/Mozilla like databases are using tabs to
navigate, we should do the same. Aarons idea on changing navigation shortcuts on
the fly via a key is also a great idea.
BTW I am working on updating the keyboard navigation spec for Seamonkey. will be
published shortly. I'll incorporate the feedback on the newsgroups and this bug.

Directional Navigation is not a non-starter -- it's critical.  It may well be
that the default keybindings in Windows grab all the obvious combinations - but
not everyone uses a keyboard, and even some of those that do need directional
navigation - some _cannot_ use a mouse or other fine-motor-control pointing
device, or do not have one.

It's also very important to have the functionality available (whether Windows
maps it to keys by default) for other uses of Mozilla and/or Gecko.  (i.e.
settops, like Nokia's recent announcement).

All possible ways of using Mozilla don't have to be bound at the same time.

BTW, traditionally TAB is ctrl-I.  Also, traditionally tab in a multi-line
textfield inserted a tab (at least in ns4.75/linux).  This is actually important
for some people I imagine - in particular people who use webmail services.

I don't think you can make a totally stateless solution that will be pleasing to
all people (or even close).  Which means there has to be some form of
configuration and/or mode switches/keys.

Nominating for Mozilla 0.9
Keywords: mozilla0.9
My apologies - I overwrote the previous comment (my form entry was missing on
Back).  I saved the comment and am re-adding it here:

------- Additional Comments From german@netscape.com 2001-02-01 11:35 -------

Agree with saari's approach - tabs should not insert tabs in form fields as a
default. This is a 10% vs 90% case in terms of usage. Also since most form fill
applications and browsers ouitside N6/Mozilla like databases are using tabs to
navigate, we should do the same. Aarons idea on changing navigation shortcuts on
the fly via a key is also a great idea.
BTW I am working on updating the keyboard navigation spec for Seamonkey. will be
published shortly. I'll incorporate the feedback on the newsgroups and this bug.

Even more apologies - Bugzilla lied and told me it would overwrite the comment,
and I didn't check.  Mea Culpa.
*sigh* ... This bug is *not* about pressing Tab in a textarea, that's bug 2083. 
If you're going to make some anal distinction between `spec bugs' and 
`implementation bugs', this is *not* a `spec bug' for pressing Tab in a textarea, 
that's bug 29086. And this bug is *not* about directional navigation, that is a 
different issue which should be filed separately.

Like the description says, this bug is about choosing between links and/or 
controls and/or images/plugins when tabbing through a page.
No longer blocks: 2083
Summary: Need spec for keyboard navigation (tabbing) within form fields within form fields and among document elements including images and links → Spec for keyboard navigation (tabbing) within form fields, images, links etc
Blocks: 2083
bug 67684 has been opened to split off directional navigation issues into their
own bug.
How about if we had 2 sets of two keyboard shortcuts, for example:
<-Shift-TAB and ->TAB vs. <-Alt-Shift-Tab and ->Alt-Tab. Then a pref can be set 
which lets users decide what the easier one (w/o Alt qualifier key) is being 
applied to: 'Navigate all controls' vs 'Just navigate text fields'(needs better 
wording). The other one automatically gets the other set of shortucts. The UI 
for this in the Navigator prefs would be a simple set of two radio buttons.

This design would make the added acessibility functionality available to those 
who want it without penalizing those who don't. In addition these prefs 
defaults could be set differently on a per platform basis.

German: have you ever used windows? you should know better than to suggest 
alt-tab. That's app switch, alt-shift-tab is also app switch [opposite 
direction].
used windows? Never. (just kidding)
but obviously using it at 6am my brain was not up to speed yet. of course alt-
tab is used win-wide, sorry for that. some other shortcut combo might be 
possible though, like ctrl in conjunction with TAB and shift-TAB.
Uh, German, like I said on 2001-01-25, Ctrl+Tab is already taken too.

You know, the Opera web browser has a nifty way of resolving this - it has a
seperation between form fields and actual links that can be toggled. When you're
in "form field focus mode", so to speak, tab and shift-tab move from form
element to form element. Hit F9 to get out of "form field focus mode", and then
you're in "web page focus mode", where there's a TON of commands based just off
of single letter keypresses. ("z" and "x" do "previous page in history" and
"next page in history", "q" and "a" focus previous and next links in a document
kind of the same way the up and down arrows work in lynx, etc.).

Opera itself lacks a way to go *back* to form fields, but there's no reason why
Moz couldn't if it adopted this strategy. (maybe have F9 (or whatever key is
available) be a toggle rather than one-way, perhaps)

Just a suggestion...
mpt/timeless: instead of just poking hole in anything german says, why don't you
offer a suggestion?
Yes the opera thing is pretty interesting, although I wonder how much effort 
they put into localizing this. For users to be able to memorize the keys 
like "q" and "a" they are picked based on the position on the keyboard and a 
somewhat loose mapping to terms like back and forward or up and down. That 
position may be different on a keyboard in another locale.
On the other hand the quick switch (f9 in opera) might be something worth 
learning from this goes in the direction aaron mentioned. It could be applied 
to toggling between jumping just fields vs jumping every control. I wonder 
though whether this is used as something that gets switchhed frequently or 
infrequently and therefore better expressed as a pref or a hotkey.( In terms of 
users with special needs, a simple hotkey definitely seems more accessible than 
a pref)

"suggestion" tab in a edit field behaves like a tab. to get access to the 
document the user presses <esc>ape.  the edit field loses :cursor and gains 
:outline. the user can then use tab/shift-tab to navigate forward/backward.  
up/down/right/left navigate elements [:block?].  <esc>ape again sets :outline 
to the frame that contains the object that used to be :outline. If this is the 
_content, then <tab> navigates between _content, toolbars [menubar, location 
bar, personal toolbar, navigation bar], and sidebar[s].  If 
it's a frame, then arrows navigate frames directionally and tab/shift-tab 
navigates the frame internally [selecting the first and last internal elements 
respectively].

it appears that shift-esc = decrease font in netscape4.76. I never new that.

I'd suggest that we allow shift escape to do something else.

Picture

<window type=browser>
<toolbox>
<toolbar id=menubar/>
<toolbar id=navigationbar>
<button id=back/><button id=forward/><input id=location/>
</toolbar></toolbox>
<sidebarbox>
<sidebar/>
</sidebarbox>
<iframe id=_content>
<html>
<frameset>
<frame id=title>
This is a test, you can <a href=about:>learn about your browser</a> or practice 
with <a href=javascript:>javascript</a>.
</frame>
<frameset>
<frame id=outline>
<base target=content>
<ol><li><a href=#top>Index</a><ol><li><a href=#1.1>Curious</a></li></ol><li>
</frame>
<frame id=content>
<form>
<input/>
<edit lines=5/>
<listbox lines=5 
oncreate="for(i=1;i<10;i++)this.addItem(math.random(2*i*(10-i)))"></listbox>
<input type=submit><input type=reset>
</form>
</frame>
</frameset></frameset>
</iframe>
<toolbar id=statusbar/>
</window>

suppose you're in the <edit/> you type a message, including tabs.
if you press shift-tab, the cursor goes to the -lineinput-, if you press tab 
there, focus returns to the -multiline-editbox-.  pressing up/down in the box 
moves focus w/in the box, and might scroll that content.
press escape, and the box is :outline'd, pressing up/down would scroll the 
frame. pressing tab moves focus to the listbox.
alecf: I already did. See my 2001-01-25 and 2001-01-26 comments. I have been 
thinking about this problem since last October, and what I suggested above was 
the most usable solution I've come up with in that time. Of course I'd love to 
see a better idea, but I haven't yet.

german: Oops. Didn't think of l10n issues...

Perhaps have a different shortcut layout for every standard keyboard layout (us, uk, de, etc.); tell Mozilla what your layout is or grab it from the OS if possible? (of course, that would probably get a litle tedious to code in every single one, and since I don't know C from Perl anymore I couldn't help...)

Or possibly have all keyboard shortcuts customizable with preset config files for each layout. (of course, that'd be kind of a big change... something post-1.0, maybe)

Or, for something totally different, perhaps have a preferences option for "Lynx-style link navigation", and when that's requested have form and link elements focused by default, focusing the topmost displayed element when you page down (one of the things I don't like 'bout tabbing right now is that it Always starts at the top of the document rather than the topmost visible element), using shift-up and shift-down for scrolling the document (is shift-arrowkeys taken? From what I could tell it wasn't...)
Eef! Thought it would insert the newlines... Bad opera. No biscut.


Reposting so things are actually readable:
----
german: Oops. Didn't think of l10n issues...

Perhaps have a different shortcut layout for every standard keyboard layout (us,
uk, de, etc.); tell Mozilla what your layout is or grab it from the OS if
possible? (of course, that would probably get a litle tedious to code in every
single one, and since I don't know C from Perl anymore I couldn't help...)

Or possibly have all keyboard shortcuts customizable with preset config files
for each layout. (of course, that'd be kind of a big change... something
post-1.0, maybe)

Or, for something totally different, perhaps have a preferences option for
"Lynx-style link navigation", and when that's requested have form and link
elements focused by default, focusing the topmost displayed element when you
page down (one of the things I don't like 'bout tabbing right now is that it
Always starts at the top of the document rather than the topmost visible
element), using shift-up and shift-down for scrolling the document (is
shift-arrowkeys taken? From what I could tell it wasn't...)
No longer blocks: 2083
Blocks: 58712
reassign to german to get some tabbing specs
Assignee: alecf → german
Target Milestone: --- → Future
A lot of this has been discussed in the last few accessibility meetings. In lieu
of a spec aaronl is putting a overview page together based on his excellent
access-mozilla.sourceforge.net site that reflects the current state of thinking.
It can be found under http://mozilla.org/projects/ui/accessibility/
removing mozilla0.9 keyword
Keywords: mozilla0.9
*** Bug 95941 has been marked as a duplicate of this bug. ***
All right, an awful lot has been said about this bug. Let me synthesize a few of
the ideas that have been proposed.

* Tab/****+Tab switches elements on the page as it does now on all platforms.

* Pressing a hotkey (F9?) toggles to only switch form elements on all platforms.
Having a two-way toggle would obviate the need for a graphical representation of
which mode you're in -- you can just press the Tab key. You'll be in one or the
other.

* Pressing Opt+Tab/****+Opt+Tab overrides the current F9 state on a
keypress-by-keypress basis on the Mac.

If a key combo is freed up in the future or another solution is devised that
would give Windows users more granular control over tab movements, great. But as
it stands, IE for Win doesn't have this (I think??), so people won't be
expecting it. And we'll actually be ahead of IE with the F9 (or whatever) toggle.

This would give most of the people most of what they want and some of the people
all of what they want. :-) I happen to be biased, being a Mac user, but if
Windows is out of Tab modifier keys (as mpt explained on 2001/01/25), then
another way of doing this needs to be devised.

I don't think Mac users should be penalized just because Windows has run out of
keys. This is especially true because the dominant browser on the Mac these days
is IE. If we're going to win uses from them, we need to be on par for most
things and ahead on others. We're ahead on a lot of things, but it's little bits
of polish like this which people use all the time that really sell the browser.
I know of at least one person who refuses to use Mozilla because it lacks this
feature and bug 103521, and one other ueser (yours truly) who uses Mozilla
anyway, but dearly misses the creature comforts of IE.

Oh, and according to bug 53505, switching between windows on Mac is not an issue.

What do you think?
reassigning.
Assignee: german → aaronl
Priority: P3 → --
Target Milestone: Future → ---
-> Akkana
Assignee: aaronl → akkana
Whiteboard: [SPECBUG] → [SPECBUG] [KEYBASE+]
This is going to be an important issue for chimera, where there are system-wide
preferences for tab behaviour that we should follow.
...and other embedded apps as well. so, i'm going to add this as a blocker to
bug 150046 (mac embedding meta bug), since the decision here might affect how
keyboard navigation behaves in such apps. (i don't know about the other platform
embedding meta bugs, but feel free to add as needed.)
Blocks: 150046
No longer blocks: 150046
I filed bug 160434 specifically on the issue of implementing a way to control
which elements can take focus in web content (i.e. tabbing to just form
controls, or form controls and links). Spec or no spec, we need to have that
implemented.
Target Milestone: --- → mozilla1.2beta
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
I have long been confused about the difference between this bug and bug 140612
(which I own and in which I have a patch).  After discussion with Aaron, I'm
duping this bug to that one (and I'll transfer the keywords).

If anyone following this bug thinks that it covers something not covered by bug
140612, please speak up.

We'll be filing a new bug on exposing a pref UI for the tabbing pref.

*** This bug has been marked as a duplicate of 140612 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
fine with me :)
No longer blocks: 127253
Status: RESOLVED → VERIFIED
Blocks: grouper
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.