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)
Core
DOM: UI Events & Focus Handling
Tracking
()
VERIFIED
DUPLICATE
of bug 140612
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.
Updated•24 years ago
|
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
Comment 1•24 years ago
|
||
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.
Comment 2•24 years ago
|
||
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
Comment 3•24 years ago
|
||
-> xpapps
Assignee: asa → ben
Component: Browser-General → XP Apps: GUI Features
OS: Mac System 9.x → All
QA Contact: doronr → sairuh
Hardware: Macintosh → All
Comment 4•24 years ago
|
||
->keyboard nav...
Assignee: ben → alecf
Component: XP Apps: GUI Features → Keyboard Navigation
Updated•24 years ago
|
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
Comment 5•24 years ago
|
||
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.
Comment 9•24 years ago
|
||
cc'ing akkana and brade to see if they have any opinions here...
Assignee | ||
Comment 10•24 years ago
|
||
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.
Reporter | ||
Comment 11•24 years ago
|
||
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..
Comment 12•24 years ago
|
||
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
Comment 13•24 years ago
|
||
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 → ---
Comment 14•24 years ago
|
||
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
Comment 15•24 years ago
|
||
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.
Comment 16•24 years ago
|
||
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).
Assignee | ||
Comment 17•24 years ago
|
||
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!"
Comment 18•24 years ago
|
||
> 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].
Comment 19•24 years ago
|
||
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.
Comment 20•24 years ago
|
||
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 | | | | | | +-------------------+ :::::::::::::::::::::::::::::::::::::::::::: |
Comment 21•24 years ago
|
||
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.
Comment 22•24 years ago
|
||
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.
Reporter | ||
Comment 23•24 years ago
|
||
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.
Comment 24•24 years ago
|
||
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.
Updated•24 years ago
|
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
Updated•24 years ago
|
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
Comment 25•24 years ago
|
||
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.
Comment 26•24 years ago
|
||
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).
Comment 27•24 years ago
|
||
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?
Comment 29•24 years ago
|
||
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.
Comment 30•24 years ago
|
||
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.
Comment 31•24 years ago
|
||
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
Comment 32•24 years ago
|
||
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.
Comment 33•24 years ago
|
||
Even more apologies - Bugzilla lied and told me it would overwrite the comment, and I didn't check. Mea Culpa.
Comment 34•24 years ago
|
||
*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
Comment 35•24 years ago
|
||
bug 67684 has been opened to split off directional navigation issues into their own bug.
Comment 36•24 years ago
|
||
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.
Comment 37•24 years ago
|
||
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].
Comment 38•24 years ago
|
||
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.
Comment 39•24 years ago
|
||
Uh, German, like I said on 2001-01-25, Ctrl+Tab is already taken too.
Comment 40•24 years ago
|
||
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...
Comment 41•24 years ago
|
||
mpt/timeless: instead of just poking hole in anything german says, why don't you offer a suggestion?
Comment 42•24 years ago
|
||
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)
Comment 43•24 years ago
|
||
"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.
Comment 44•24 years ago
|
||
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.
Comment 45•24 years ago
|
||
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...)
Comment 46•24 years ago
|
||
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...)
Comment 47•23 years ago
|
||
reassign to german to get some tabbing specs
Assignee: alecf → german
Target Milestone: --- → Future
Updated•23 years ago
|
Keywords: helpwanted
Comment 48•23 years ago
|
||
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/
Updated•23 years ago
|
Keywords: mozilla0.9.1
Comment 50•23 years ago
|
||
*** Bug 95941 has been marked as a duplicate of this bug. ***
Comment 51•23 years ago
|
||
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?
Comment 52•23 years ago
|
||
reassigning.
Assignee: german → aaronl
Priority: P3 → --
Target Milestone: Future → ---
Comment 53•22 years ago
|
||
-> Akkana
Assignee: aaronl → akkana
Whiteboard: [SPECBUG] → [SPECBUG] [KEYBASE+]
Comment 54•22 years ago
|
||
This is going to be an important issue for chimera, where there are system-wide preferences for tab behaviour that we should follow.
Comment 55•22 years ago
|
||
...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
Comment 56•22 years ago
|
||
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.
Assignee | ||
Updated•22 years ago
|
Target Milestone: --- → mozilla1.2beta
Comment 57•22 years ago
|
||
batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
Assignee | ||
Comment 58•22 years ago
|
||
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
Updated•5 years ago
|
Component: Keyboard: Navigation → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•