Closed Bug 136915 (Ctrl-Tab) Opened 23 years ago Closed 23 years ago

pressing Ctrl+tab doesn't switch tabs like it does in other tabbed apps

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.2alpha

People

(Reporter: jst, Assigned: jruderman)

References

Details

(Keywords: access)

Attachments

(1 file)

patch
645 bytes, patch
neil
: review+
jag+mozilla
: superreview+
Details | Diff | Splinter Review
Since we're now apparently prefering opening links in new tabs over opening them in new windows (in the context menu, open in new tab is the first option, and open in new window is the second one. IMO that's wrong too, but that's another bug...) we should at least make mozilla on windows (and other platforms too?) work like all other MDI apps work on windows, i.e. Ctrl+Tab switches between open tabs (or "documents"). If we're pushing our tab support as the prefered way, this needs to be a stopship bug, big time!
Severity: normal → critical
Keywords: mozilla1.0, nsbeta1
Keywords: nsCatFood, nsdogfood
This has been discussed before, and people seem to have settled on having ctrl-pgup/ctrl-pgdown switch tabs while ctrl-tab continues switching frames. If nothing else, when a user has only one tab open we should, imo, switch frames on ctrl-tab (then again, I don't use tabs, so... :) ).
This isn't MDI. ->invalid
Status: NEW → RESOLVED
Closed: 23 years ago
Keywords: nsbeta1
Resolution: --- → INVALID
MDI or not, tabbed views in windows have the exact same behavior, and people are used to it. Ctrl+Tab switches between tabs in tab views in windows apps, we should do the same. Reopening.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
As kbd component owner, I'm fine with this -- as long as Ctrl+Tab/Ctrl+Shift+Tab also moves between frames in a frameset. Therefore, Ctrl+Tab will need to move between the superset of tabs and frames.
Yeah, that would seem like the natural way to go here.
I confirm that. When I tried Mozilla with tabs for the first time, I got really frustrated because Ctrl-Tab didn't switch tabs, and there was no other obvious key combination to try. Never knew that Ctrl-Tab switches framesets, BTW.
at some point ctrl-tab needs to be reassigned to tab switching. it's intuitive to the point of obvious, it's also the convention. We should commendeer it from frame switching, which is in very small minority relative to potential tab use. As for frame switching, there's a whole new can of worms which can be opened when looking at how the average consumer processes web pages. Traditionally, web browsers (not web authors) have burdened users by requiring them to grasp the engineering model of a framed web page, when what they're actually need to model is the content. This mismatch in intentions has been caused by the browser, and there are several ways we can undo this. One of those is now done with the redesigned context menus. Frame switching should be achieved seemlessly and transparently through the regular sequence of node focusing. If a page contains 3 frames, a user should be able to tab to each node and frame in sequence irrespective of frameset, thereby transcending the engineering model. This way, frame switching is nolonger compulsory and becomes part of the regular tabbing routine. This behavior would support the large majority of our user expectations, while not totally incapaciting frame dissection for web developers. Anyway, just an idea of how to compensate for the loss of ctrl-tab, and user problem with frames.
*** Bug 147283 has been marked as a duplicate of this bug. ***
I agree here. This has been requested a lot, see bug 108413 and its dupes, there are a few more flying around. I believe this should not be restricted to Windows, I want to have this for Linux, too ---> All/All. Ctrl-PgUp/PgDown could be used to switch between frames.
OS: Windows 2000 → All
Hardware: PC → All
On Linux, Ctrl+PgUp/PgDn is the closest thing to a standard convention. F6 should be used for switching between frames (it already works), but F6 cannot be used on Mac. Therefore Ctrl+Tab cannot be used for tabs either on Linux or Mac. Hence why the bug I filed yesterday (bug 147283) is marked Windows only.
Hixie, from your explanation I still fail to see why Ctrl-Tab cannot be used for tab switching on Linux. I consider Ctrl-Tab the closest to the standard on Linux, maybe someone can come up with some KDE/GNOME style guides. Here is what I found for GNOME, not that it clears the matter up much... http://developer.gnome.org/projects/gup/hig/hig-0.1/userinput.html Ctrl-Tab, Shift-Ctrl-Tab: Moves keyboard focus out of enclosing widget to next/previous control, in those situations where Tab alone has another function (e.g. GtkTextView)
That suggests that on Gnome Ctrl+Tab be used for frame switching, not tab switching. Which is what I said.
There will always be people who fight for both uses of Ctrl+Tab. I have suggested this before -- do people think a good solution would be for Ctrl+Tab to both cycle betweeen frames *and* move to the next tab? Since most pages don't have frames, this would have the effect that most people want - Ctrl+Tab would move between tabs then. If there were frames, Ctrl+Tab would have to finish moving through the frames before going on to the next tab, not very many extra keystrokes in most cases.
There are three frames always present even when the page is frameless -- the sidebar, and the location bar. I personally think it would be a bad idea for Ctrl+Tab to do both frame navigation and changing tabs. It would confuse the heck out of me, anyway. I don't consider changing tabs to be a focus change like changing frames. To summarise, I think the shortcut keys should be: Frame Switching Tab Switching Mac Ctrl+Tab Ctrl+PgDn Windows F6 Ctrl+Tab, Ctrl+PgDn Gnome Ctrl+Tab, F6 Ctrl+PgDn
> That suggests that on Gnome Ctrl+Tab be used for frame switching, not tab > switching. Which is what I said. I beg to differ. Let's have a look at the definition again: Ctrl-Tab, Shift-Ctrl-Tab: Moves keyboard focus out of enclosing widget to next/previous control, in those situations where Tab alone has another function (e.g. GtkTextView) If I am not more wrong than usual, then a widget is any kind of gui control. A button, a scrollbar, a dialog, lots of things. So a frame is hardly a widget, is it? And why on earth do you want to use F6 as a shortcut?
># Ctrl-Tab, Shift-Ctrl-Tab: ># Moves keyboard focus out of enclosing widget to next/previous control, in ># those situations where Tab alone has another function (e.g. GtkTextView) > > If I am not more wrong than usual, then a widget is any kind of gui control. > A button, a scrollbar, a dialog, lots of things. So a frame is hardly a > widget, is it? A frame one of the kinds of widgets. As you say, a widget is "lots of things". It is definitely an "enclosing widget". GtkTextView is a type of frame, in fact, it's one with editable content. A web page can be considered a read only GtkTextView-like widget. Look at the definition again -- it say that Ctrl+Tab is for moving keyboard focus. Changing tabs is not moving focus -- it's, well, switching the tabs. It is definitely not moving the focus _out_ of the enclosing widget, if you consider the tabset the widget. > And why on earth do you want to use F6 as a shortcut? F6 is already a shortcut for changing frames, it also happens to be the shortcut used in many Windows applications for similar purposes. (Ctrl+F6 is used for switching entire windows.)
Just some additional notes. The programs I have tried that uses Ctrl+Tab are: * Outlook Express * CuteFTP * UltraEdit * Grokster * Texturizer In addition, all tab based configuration dialogs in *all* Win32 programs (including IE, Outlook Express, TweakUI, Grokster, Texturizer, UltraEdit, most Control Panel applets, and many more) are using Ctrl+Tab. I'm sure there are more programs that uses Ctrl+Tab, but I have not yet seen any program except Mozilla to use Ctrl+PageUp. Also, Ctrl+Tab is easier to press than Ctrl+PageUp. It's also more natural since Alt+Tab switches windows (which is closely related to switching tabs). My suggestion is to have (Shift+)Ctrl+Tab for Tab switching, and Ctrl+PageUp/Down for frame switching (or F6, I honestly don't care about frame switching).
(...which is what I've been saying. See comment 14.)
Before we do this, we need to solve the problem this will cause: what will happen to users who are used Ctrl+Tab to switch frames? 1. Who cares, tab browsing is more important - we can deal with lots of people filing bugs that say Ctrl+Tab should navigate frames. F6 works, some/most people will find it eventually. 2. Yet another pref/hidden arguments dialog option. This solves most of our problems anyway! 3. Make Ctrl+Tab both navigate the superset of both frames and tabs. It will not navigate to the sidebar or URL bar. 4. Your idea here. Yes, Ctrl+Tab is easier to type. Also true, Ctrl+Tab is a standard shortcut for switching tabs. It's also the standard shortcut for switching frames in a web page, used by IE and Netscape 4.7. Hence the conflict. (Ctrl+PgUp/Ctrl+PgDn are also standard for switching tabs, believe it or not.) The defacto definition of what Ctrl+Tab should do is different for different contexts. In browsers like IE and Netscape it has always navigated by frames, so that is what many users now expect. I'm sorry, but we have to deal with these users. If, by popular demand, we end up supporting Ctrl+Tab for switch tabs, we still need to solve the problem described for people that use it now to switch frames. If you want this feature switched, don't try to convince that Ctrl+Tab is a better shortcut for switching tabs. I agree. Instead, please suggest a way around the confusion for the keyboard users that are used to switch frames with Ctrl+Tab. How do we make sure they have a seemless transition to F6, and that they don't get stuck, thinking there is a bug in our keyboard support?
Solution #1 has one problem. What about users who never use tabs and have the tabbar off all the time. Should these users suddenly lose their frame navigation or have to relearn it because of a new feature they try very hard to ignore the existence of? My point is, do we want to consider ctrl-tab doing different things depending on whether more than one tab is open (or more to the point, depending on whether the tabbar is visible)? Or is this just a bad way to go?
Good, we now have 4 options. What to do about people who are used to navigating frames with Ctrl+Tab? 1. Who cares, tab browsing is more important - we can deal with lots of people filing bugs that say Ctrl+Tab should navigate frames. F6 works, some/most people will find it eventually. 2. Yet another pref/hidden arguments dialog option. This solves most of our problems anyway! 3. Make Ctrl+Tab both navigate the superset of both frames and tabs. It will not navigate to the sidebar or URL bar. 4. Make ctrl-tab do different things depending on whether more than one tab is open (or more to the point, depending on whether the tabbar is visible)
Unfortunately, I don't think there's an easy solution to those who are used to Ctrl+Tab stepping through frames. Personally, I used to tab through each link until I got to the next tab (using IE), so I didn't even know there was a Ctrl+Tab for direct frame switching. Of your proposed ideas, I don't like idea 3 (make Ctrl+Tab step through both frames and tabs). Ctrl+Tab should be for tabs only. I partly agree with idea 1 (tab switching is more popular than frames). A hidden pref for this wouldn't be a good solution I think. My best bet is to use Ctrl+Tab for tab switching only, regardless whether or not the tab bar is visible. This will be most consistent. The only problem is for the users that are used to use this shortcut when switching frames. But how common is that in the real world? First of all, not many sites uses frames anymore. Besides, you can still step through it using tab only, or F6. I know this is completely off topic, but what I'd like to see is completely configurable keyboard shortcuts (for every command/menu item available) through a UI dialog. This would solve all the filing of bugs because of non-standard/strange keyboard shortcuts. Anyway, since tabbed browsing is one of the new "key features", I think it's more important with a good shortcut for this feature, rather than reserving Ctrl+Tab for frames, which few corporate sites uses anyway. To summarize, I don't think there's a smooth way for the (few?) users used to step through the frames using Ctrl+Tab. They will simply have to accept that tabbed browsing is more popular than stepping through frames. (Once we get completely customizable keyboard shortcuts, this will not be an issue! I will file an enhancment request.)
David, thank you for helping the discussion along. I would like to point out, that this would still be an issue even with configurable keyboard shortcuts, because there is still nothing in the UI to alert unsophisticated users that the keystroke does something different now. This confusion is the issue that needs to be solved. There is a significant set of users, however small we do not have numbers, who utilize this keystroke to navigate frames. Some users navigate only with the keyboard, for example blind and some physically disabled users. Sure, Ctrl+Tab is clearly better for navigating our key new tabbed browsing feature. I think your answer how to deal with people who are used to the old key binding is to punt on the issue. You say they will have to accept that the other feature is more popular, but this is assuming they get far enough to understand what's happened and how to get past it.
One solution could be to mention the change in the release notes and the FAQ. _If_ we had configurable shortcuts (see bug 57805), we *could* use Ctrl+Tab for frame switching by default, since this seems to be the old standard. However, something tells me that we are not going to see this implemented very soon. I don't know if this is even allowed, but one very aggressive solution would be to display a message box the first time the user press Ctrl+Tab or Ctrl+Shift+Tab, displaying information such as: "Mozilla uses this shortcut to switch between opened tabs. If your intention was to step through the available frames in this document, use Ctrl+PageUp or Ctrl+PageDown instead. [ ] Don't show me this information again." This will definitely get the user's attention when he/she needs the information. If that solution is too much, I recommend adding info to the FAQ and release notes.
Just to inject a voice of sanity, the "cool new feature" is a UI disaster in many ways, with the result that a number of users never use it. So the changes David proposes would rob those users of the ctrl-tab shortcut completely -- it will simply do nothing. Now I happen to be one of the users in question, and I personally would be OK with the change. But I'm not a heavy keyboard nav user. Perhaps some usability testing on such users is in order for all the options in question....
I agree that we must be concerned about our existing Ctrl+Tab users. This is a big change, both for existing Mozilla users, as well as to many migrating users. IMHO, the questions we have to consider are: 1. Do people associate Ctrl+Tab with tab navigation more strongly than with frame navigtion? I have no idea. Do we have any data on this at all? 2. Are frames prevalent enough on the web today that typical users will be presented with having to switch frames more often than switching tabs? In my experience, frames are now quite rare. However, some users may frequent frame-heavy sites a lot. Those users may be Ctrl+Tab users, too. Again, do we have any data on this? 3. Are tabs going to be popular enough to make them worth using up a valuable shortcut key like Ctrl+Tab? This we do have data on; according to a recent Netscape usability study, tabs were found to be very popular amongst users who discovered the feature. (Or so I am told.) > 2. Yet another pref/hidden arguments dialog option. This solves most > of our problems anyway! I am strongly opposed to this choice. I'd rather we didn't change the default than add *yet* more prefs. > 3. Make Ctrl+Tab both navigate the superset of both frames and tabs. > It will not navigate to the sidebar or URL bar. This sounds like a very confusing idea. > 4. Make ctrl-tab do different things depending on whether more than > one tab is open (or more to the point, depending on whether the > tabbar is visible) Maybe. Sounds confusing. Modal UI sets off alarm bells in my head. > I know this is completely off topic, but what I'd like to see is > completely configurable keyboard shortcuts (for every command/menu > item available) through a UI dialog. This would solve all the filing > of bugs because of non-standard/strange keyboard shortcuts. As Aaron said, this that wouldn't solve our problems at all. We would still have to decide on the default behaviour, as that is the behaviour that will be used by almost all our users.
Alerts are considered very bad UI by some people who are considered experts in UI design. They interrupt the work flow and should only be used as a last resort when the user *must* be interrupted. (We already have a huge number of alerts that come up for first-time users -- spamming the user with even more dialogs will simply mean that the important ones won't get read as the user will dismiss them to get on with their work. This is especially annoying for users who have to create a new profile each time they launch the browser.) I just realised that since the users that need frame switching are likely to be the same users who need to browse with a caret, the two shortcuts should be documented together -- that F7 and F6/Shift+F6 are close to each other on the keyboard will also help associate them together as accessibility access keys. Also, there is no precedent for Ctrl+PgUp/PgDn to move around frames; that shortcut should remain the same as it is now whatever happens to Ctrl+Tab. See comment 14.
Personally I've propably never heard about any man outside of "Mozilla/Netscape developer clan" even knowing that CTRL+Tab can be used for switching between frames ^_- Every bug and debate about this ended with flame-war users vs developers. So the question is not wheather users will accept common shortcut for new feature but more wheather developers will accept that no one ever used their favourite shortcut. PS: Although I've just probably started the new flame-war I probably won't reply, bugzilla sends me mails very sporadically and as of today DNS for my mail is down. Happy flaming ^_^
Just my 2c: I consider myself a rather advanced user (13+years of expierence), been with Netscape since v2.0, and learnt that Ctrl-Tab switches frames only a couple weeks ago. And when I first noticed tabs in Mozilla, my hands immediately did Ctrl-Tab, and I was really frustrated that it didn't work... P.S. For UNIX/Mac, what'd you say about Ctrl-Right/Ctrl-Left for switching tabs?
I'd say that those are often coopted by the windowmanager for moving the mouse pointer....
tabs != mdi. changing summary.
Summary: Can't move between tabs with Ctrl+tab like you can in all other windows MDI apps. → Can't move between tabs with Ctrl+tab like you can in all other tabbed windows
Severity: critical → normal
Target Milestone: --- → mozilla1.2alpha
Summary: Can't move between tabs with Ctrl+tab like you can in all other tabbed windows → pressing Ctrl+tab doesn't switch tabs like it does in other tabbed apps
> what'd you say about Ctrl-Right/Ctrl-Left for switching tabs? Need them for forward/back word in text fields and browse with caret mode.
on BeOS ctrl-tab is either app switching or not app switching. [Gotta love it] I think that's actually not a concern, because when it is task switching alt is the accelerator (unless we don't automatically recognize that setting, which would be a serious bug). Also remember older netscape's and a bunch of other w16 apps (teraterm is actually a much better behaved example, since it correctly supported shift-) used ctrl-tab for app localized window switching. [Some poor soul actually request this behavior, but wisely relented when we pointed out the nightmares of too many things wanting to be the ctrl-tab] while we're discussing long lost features, here are two more we should address <evil grin> ctrl-1 to launch a new navigator ctrl-1 to switch to the next navigator since people appear interested in saving the world, perhaps they can unify that world too :-) the use of ctrl-1 to switch navigators was based on a theory not unlike tabbed browsing. In fact the floating component bar enabled this feature too since you could just keep clicking the navigator button to switch through all of your open navigator windows -- something you can't do for tabbed browser with a mouse without moving your mouse. i think ctrl-<number> is reserved by macos for something else, thankfully on macos we are expected to use <command> instead of <control>. Hixie: are you sure you want us to use ctrl-tab/ctrl-page* instead of command-tab/command-page*? (well command-tab is reserved by the os for app switching, so i guess that's not really an option <grin>). Of course <ctrl>-tab might not be available either on macos since some of the older task switchers used it ;-), this led people to suggest that we accept either ctrl- or command- tab for task switching, but that we not be greedy (so-as to allow the os or an extension to handle task switching on a key) i seem to recall some *-page* keystroke to walk around the windows explorer taskbar but i can't find it today.
Hi, I have recently switched to Mozilla 1.0 after using Netscape 4.7 for about 3 years I think. I just wanted to make a few comments. 1) Many of your new users will come from the netscape user community. At least in Netscape 4.7, Ctrl-tab cycled through all open windows, something that I personally got very used to. In my opinion, you've already shocked some users that see Mozilla as the continuation of Netscape of some sort. 2) I have no data to back my statement, but I think most users (non-developers and engineers) don't think in terms of frames. Tabs, however, appear to be very popular. 3) If you read the netscape.public.mozilla.wishlist news group and other mozilla related NGs, as I do, you will find the following question appear over and over: "How do I switch between tabs using the keyboard?". Ctrl-pageup and ctrl-pagedown are clearly not intuitive. And in my opinion, making a gui intuitive is more important that making it conform to standards, if there is a conflict between the motives. 4) Additionally, in the NGs, Ctrl-tab is suggested as the keybind by those who dont know that one already exists, and as a replacement by those who already know about the Ctrl-pagedown/pageup.
I have been asked to comment on the 4 options provided in comment 21: 1. Who cares, tab browsing is more important - we can deal with lots of people filing bugs that say Ctrl+Tab should navigate frames. F6 works, some/most people will find it eventually. 2. Yet another pref/hidden arguments dialog option. This solves most of our problems anyway! 3. Make Ctrl+Tab both navigate the superset of both frames and tabs. It will not navigate to the sidebar or URL bar. 4. Make ctrl-tab do different things depending on whether more than one tab is open (or more to the point, depending on whether the tabbar is visible) 1. I personally believe this is the best short term option with a goal to implement 2 in the long run. People DO have F6 available to them, and my argument is that users rarely think in terms of frames. That is evident even from the comments here. And for those that do, they will be able to find out that F6 does what they want, since I believe them to be more "advanced" than us normal users. :-) 2. This option is the best solution in the long term, since it provides the user with the choice, which would resolve the dilemma. This could be filed as a separate bug for future development. 3. What is the superset of frames and tabs? As a user, I have no idea what this means. I don't think this is a good solution since no one has asked for this. 4. I am not sure how this would even work. I am assuming that frames within a tab would be cycled first, but at reaching the "last" frame within a tab, cycle to the next tab? Which frame is last? What about the location bar? What tab does the location bar belong to? And when would ctrl-tab cycle to it? I think this is a bad solution. Realize, my comments are from a Windows user. For other platforms, I agree with comment 14 by Ian 'Hixie' Hickson.
I'd vote for option 1 (and option 2 in the future). We need to change this shortcut soon I think. Every week, someone is posting/complaining about the lack of a shortcut to switch tabs. Obviously, they don't know about the (lousy) ctrl+pageup shortcut. Ctrl+Tab should switch tabs *only*, not frames as well! According to some posts on the newsgroups I've read, Ctrl+Tab used to switch between opened windows in Netscape 4 (and maybe older versions too). I'd like to know when ctrl+tab started to switch frames? In comment 21, Aaron Leventhal speaks about the users who are used to switch frames using this shortcut. Who are these users? They can't be Netscape 4 users, can they? If we're only dealing with Mozilla 0.x users (currently developers and experienced users), I don't see the problem of binding the shortcut to tab switching instead. And what about all the former Opera users? I'm sure they're also used to switch tabs using this shortcut (although I honestly don't know if that is the shortcut for tab switching in Opera; I just assume it is!).
> They can't be Netscape 4 users, can they? they can, load addressbook and press (or hold) ctrl-tab. there's a bug where i described how totally broken n4's ctrl-f6/ctrl-tab behavior is. using ctrl-tab eventually gets you stuck in addressbook.
or the more obvious case: mail composer -- I actually use that form. [Addressbook is just the obscure case]
Opera uses Ctrl-Tab for tab switching, even under Linux.
IIRC, I've never done this before. <g> I vote WONTFIX. Here's why: I don't see any parallel between tabs and windows. What I do see is a parallel between the different pages or sheets in a spreadsheet notebook/workbook. In the two shreadsheet apps I use routinely, Lotus 1-2-3 and Quattro Pro for DOS, Ctrl-PgUp/Ctrl-PgDn are the keystrokes for switching between pages in the stack. IIRC, the F6 key was first used as described above in the first versions of Lotus 1-2-3, where it switched between what it called windows, and what the later Quattro Pro knockoff of it called panes, both of which pretty well parallel the web browser concept of frames. These apps still use F6 for pane switching. The PgUp/PgDn concept as applied to tab switching makes good sense because of the parallel to switching between sheets in a stack of pages. If we remember that the tabs we see displayed are functionally the same as the tabs in a paper notebook, with or without tabs (or the electronic equivalent of paper notebooks), rather than a horizontal shift as between frames, which the tabs themselves seem to imply, but don't in reality, then it really is not hard at all to relate the PgUp/PgDn keys to the desired navigation, up/down. Please WONTFIX!
Blocks: 156025
Not all keyboards have PgDn/PgUp keys (i.e. my Macintosh's keyboard), therefore I would really, really appreciate Ctrl-tab to switch between tabs.
that's the reason ctrl-tab is used for frame navigation. navigating frames is essential. tabbed browsing is a perk.
> that's the reason ctrl-tab is used for frame navigation. > navigating frames is essential. tabbed browsing is a perk. That is a matter of opinion. Lots of people would disagree with you. That is the main reason this discussion is dragging on so long. Its too bad we can't just poll all Mozilla users and prospective Mozilla users. Anyway, back on topic: the good long term solution (in my opinion :-] ) is to implement a preference. Or even make some easy way for users to change their keyboard accelerators.
> that's the reason ctrl-tab is used for frame navigation. > navigating frames is essential. tabbed browsing is a perk. Of course, this is a subjective call. That is why we have so many comments and have come no closer to deciding. Its a matter of opinion. There are many users who would agree with me that navigating tabs is more useful (essential? What is really essential?) than navigating frames. I argue that most users aren't really aware of frames, while tabbed browsing has become very popular. I use the news groups for mozilla as my source of anecdotal evidence. There are tons of threads asking for keyboard accelerators to switch tabs. Most invariably suggest ctrl-tab as the accelerator, unaware that ctrl-pageup/pagedown are already the accelerators (because they are not obvious) and unware that ctrl-tab already works for frames (probably because they aren't aware of frames).
what is essential? well, si ne qua non. certain things (in life) are essential because without them you'd die, among them are air, water and salt. some things are essential (to software products) because without them you couldn't sell your product to the US Gov or similar entities. some things are essential (to software products) because not doing them exposes you to lawsuits which could put you out of business. Oh there's also another factor, for which my history professor never provided a term, it can be phrased thusly: "you can get too much of [what would otherwise be] a good thing", examples include: air, water and salt. More specifically, if you're placed in an environment which contains 100% Oxygen, you'd probably die, similarly for water or salt. In fact the numbers don't have to be anywhere near 100% simply 20x requirements is probably more than enough to kill you. So how or where does too much of a good thing come into play? Customizability. Suppose that each user was able to customize everything. suppose that 1 in 5 users did. suppose that people visit other people and then start to use their browsers and manage to make a mess of things because they can't figure out the keys. 1 in 3 people might figure out what was happening and be scared for life, at the beginning of every browser session for the rest of their life, they'd hunt for the configuration options to either reset them, examine them, cahnge them, or create a guest account. 1 in 3 people might decide that their friends broser is broken and move along. and who knows what that other group would do. that's one way to describe customizability to the extreme. (the numbers 1 in 3 are random and arbitrary, I have done no studies on this.) the more basic problem with customizability is actually creating a UI for it that doesn't befuddle its users. (if the users get scared of the ui, they'll never become profficient enough for the extreme described above.) as for key customizability, that's a mess. it's already possible, make yourself a localization or use userChrome.css (the customizing unix page describes howto). A UI for customizing keys would be an interesting thing, however anyone who designs UIs will laugh at us for trying to implement such a thing. and such discussions do not belong in this bug. if you like newsgroups then feel free to design a spec for key customization (to be developed by a third party) in the newsgroups. If people are seriously interested in imeplementing such a creature, i suggest stealing a UI from an established open source project (well no, i'd suggest stealing one from a Sun sponsored project), OpenOffice or NetBeans. Every now and then people make strange arguements that NC4 did foo. And I always say well, NC4 was broken, it didn't really do foo, you just imagined it did foo. If any of you don't believe me, please take a moment to read bug 30864 comment 46. Mozilla is not a tabbed browser, it's a browsing suite. If the product you want is a tabbed browser, get multizilla. The features that most of the people here want are really MDI, which is really amusing since ms has spent a considerable amont of time killing it (and no ms didn't do this because MDI was a good idea and ms decided to spend millions of dollars killing a good idea. presumably ms spent money on usability studies). I think that what you'll find is that typical end users can't figure out mdi (which would explain why windows explorer isn't MDI and why MSOffice doesn't default to MDI anymore), but developers and people who are not typical end users appreciate MDI (MSDev is MDI, NetBeans had so much demand for mdi that people volunteered to code it and it's now an option). If you insist that we support typical end users, then you should start by counting yourself out. Typical end users don't use newsgroups and they don't use bugzilla (don't worry, I don't count myself as a typical end user either, how can i? I'm a developer, I know what news: is, and I use bugzilla). MSDev and Netbeans are interesting apps (but of course, they have the wrong target audience). NetBeans is a serious product, and has been for a while, as such it has real documentation, here's documentation from 2.x: http://ls10-www.informatik.uni-dortmund.de/LS10/Pages/sopra-specials/doku/netbeans/Users_Guide/pending-31.html notice they use alt-left/alt-right for switching tabs. it kind of makes sense, doesn't it? now why was it that we couldn't use those keys? oh right, something about them being used for history navigation. whoops :) while i'm digging for cross references, i should probably note http://ui.netbeans.org/access/accessibility.html for aaronl. The only reason to note it here is to indicate that netbeans is also aware of section508. it's (at least) as much of a concern to them as it is to us. Although they have an entire ui team who seriously work on stuff and they also have customizability because being an IDE it's a standard feature, whereas as a browser it isn't. Even an IDE with a target audience of developers (see earlier where I mentioned minority groups) they still care about section508. anyway, I've spent enough time for the day looking for stuff. Some day I'll get references for MSDev and Delphi (or Kylix). Personally, i'd like an alternative keyboard binding set where most navigation is single key based (lynx and w3m do this), in that world, alt-left/alt-right might actually be available for switching tabs. But remember my earlier warning, even just an alternative binding can wreak havok. Take Ben's insistance that backspace go back a page. The result of which is that if for some stupid reason mozilla decides to move focus from the modified urlbar to the document and i decide to correct the url (since that's where i expect focus to be) mozilla happily browses back a page and destroys the url i was trying to type. That's a single binding dealing considerable damage.
Keywords: mozilla1.0, nsdogfood
Timeless: Your last post was almost off topic it was so obscure. The only statement that had any even implicational value was when you mentioned law suits. Were you trying to say that making Ctrl-Tab switch tabs instead of frames would open Mozilla to a law suit for some reason? If not, it was needlessly provocative. The question here is, which of the two (frames or tabs) is most switched by end users. As was pointed out in comment 44, Newsgroup anecdotal evidence points to the fact that tab switching (not frame switching) is used more (and requested more often) by end users. Typical users aren't even aware of frames. The browser UI simply "does" this without any visual indication that something significant is happening. Nor is there ever any real need to switch frames anyway - since it's almost always all displayed on screen at the same time, and if they need to get to a text box or something in a different frame the average user will simply click on the text box with their mouse, not try to figure out how to naviagate to it via their keyboard. On the other hand, tabs are IMMEDIATELY obvious and visible in the UI, and people routinely (from Newsgroup comments) try to switch tabs via the keyboard and are annoyed when they are not able to. How many posts have you read lately asking what the keyboard shortcut is for switching frames? How many have you read for switching tabs? As for not being a tabbed browser, that's partially incorrect. Once Mozilla implemented tabs, it BECAME a tabbed browser for all of those people who use it in such a fashion. What Multizilla introduces is a bunch of bells and whistles, and extra functionality which need not make its way into the vanilla tabbed browsing environment that Mozilla offers. A good keyboard accelerator (one that's intuitively obvious as PgUp/PgDn is not) is far from fluff.
Alias: Ctrl-Tab
*** Bug 159062 has been marked as a duplicate of this bug. ***
i am new to bugzilla. how do subjective issues like this get resolved?
People argue around and around until some authority stops by, stamps in their final decision, and everybody lives happily (or not so much) ever after. ;))))
I don't have time to read this entire comment list, so my apologies if this has been suggested, but why not have an option like you have for the mousewheel? "Ctrl+Tab does: xxx" "F6 does: yyy" "Ctrl+pgup/pgdn does: zzz" Sounds like a perfect fix to me.
> I don't have time to read this entire comment list ... Then do _not_ comment. Period.
I'm in favour of this choice: " 1. Who cares, tab browsing is more important -" I don't think I've _ever_ wanted to change frames with the keyboard (which to me is so obscure it's just not funny), but I have definitely wanted to quickly scan a large number of web pages just opened from a bookmark group for updates and changes, with repeated use of Ctrl-W and Ctrl-Tab. Some of the other comments have talked about various platforms potentially having different behaviour to Win32. This is fine by me - I certainly wouldn't want to foist a windows-ism onto other platforms that have their own existing defined conventions - but Ctrl-tab really is a very widespread and useful convention for tab-switching in Win32, and it would make a lot of commonsense to use that rather than something else obscure and different (such as Ctrl-PageUp/Down).
*** Bug 160294 has been marked as a duplicate of this bug. ***
I'd just like to point out that in chatzilla, Ctrl+Tab changes the tab, and doesn't cycle through user, conversation, and text-entry line. Ctrl+PgUp/Down does the same thing. MailNews and AddressBook act like Navigator in this respect. Mozilla should at least be consistant in it's use of these keys.
============================================================================== Okay, I've finally changed my thickheaded stance on this :) Let's go with option 1 - tabbed browsing is more important. The flood of dissenters makes it an obvious choice. As long as there is some good key combination to navigate frames we're okay. On Windows this has to be F6. I spoke with a couple of blind users who assured me that they would also try F6 to navigate frames, if Ctrl+Tab didn't work. F6 is also a standard key to navigate between frames. Who's up for writing the patch? ==============================================================================
I hope you are planning to retain an option to instead use Ctrl-PgUp/PgDn instead. Ctrl-Tab makes no sense to me, since the tabs themselves are nothing but shortcuts to other pages in the stack, just like in spreadsheets that use Ctrl-PgUp/PgDn to switch among sheets in their stack.
No prefs! We don't need a pref for every little thing. Ctrl+PgUp/PgDn can continue to navigate tabs as they do now. A little redundancy is not a problem - right now Ctrl+[shift]+tab was redundant with [shift]+f6. Now [shift]+f6 will be the loner command for frame navigation.
i'm still waiting to hear what key to use for macos. the f-keys are reserved for the end user, so f6, f7, f11 are all invasions and unacceptable.
I was one of the people who talked Aaron into reserving Ctrl+Tab for frames last year. I have also changed my mind, for several reasons: 1. As several people have said here, most users do not think in terms of page frames. 2. Fixes for bug 86931 and bug 105565 will make frames even more transparent to keyboard users. 3. I've seen a lot of people ask how to switch tabs using the keyboard. 4. I'd prefer if Mozilla did not have tabbed browsing, but it does. We should fix this in such a way that non-tabbed browsers that use Gecko still can use Ctrl+Tab to switch frames. 5. Ctrl+_Tab_ is easy to remember for switching tabs in English. Since the primary reason we're fixing this on Windows is "tabbed browsing is more important than frames", I think we should fix this on Linux and Mac as well. 1. Most Mac apps do not have a shortcut for switching tabs or accesskeys on each tab. When it's possible to switch tabs using the keyboard, the shortcut is Ctrl+Tab. 2. We could use Ctrl+Tab for tabs and Option+Tab for frames, but mpt and I think it's better to reserve Option+Tab for navigating among only form elements (with a possible pref to switch Tab and Option+Tab), like Mac IE does. mpt likes having Ctrl+Tab for focusing the location bar, but that's not a Mac-specific thing.
Attached patch patch — — Splinter Review
Macdev will own the decision on what to do on Mac for this bug. Since function keys don't make sense on Mac, it might be best to leave it as it is there.
Comment on attachment 93988 [details] [diff] [review] patch The problem with this patch is that ctrl+tab from the location bar still focuses the content instead of the next tab.
jag, that's bug 114170.
Taking.
Assignee: jaggernaut → jruderman
Status: REOPENED → NEW
One more thought I had about this topic was raised by comment #56 , about being able to move both ways in the stack of open tabs. I personally think of it more like a circular buffer or a disc that can be rotated either way, but I do take your point about being able to move through the collection of tabs in both directions. On that note, if we're going have Ctrl-Tab as the way of moving forward through the open tabs, then it would make a lot of sense to also include something at the same time to make Ctrl-Shift-Tab as a way of moving _backwards_ through the open tabs. This follows for all the same reasons as adding the Ctrl-Tab behaviour - i.e. it is an existing, widespread, user-expected behaviour for moving in the reverse direction among a collection of tabs (at least on the Win32 platform). You can see this in operation in most tabbed apps, but an easy way to see it on a common app is to open MS Word, and go Tools -> Options ; Ctrl-tab will move you forward through the tabs, and Ctrl-Shift-Tab will move you backwards through the tabs. This same concept also applies when Alt-Tab switching windows: Alt-Shift-Tab moves you in the reverse direction, and Alt-Tab moves you in the forward direction. Anyway, just though I'd mention this because looking at the patch it doesn't appear to include this, and now would probably be the ideal time to add it, to include as part of the Ctrl-Tab patch.
The patch also makes Ctrl+Shift+Tab work.
regarding comment 62, MacDev failed to make a decision on this issue. Chimera is using command-{ and command-} to cycle through tabs.
i just used msexcel2000 [mdi was not enabled, this was a default install on a friends computer]. ctrl-tab switches windows (yes, the old fassioned behavior) ctrl-page* switches sheets i'm so glad we're changing this so we can be inconsistent w/ msexcel2000 i wouldn't want to remember which keys to use when i switch between excel and netscape.
re: comment #67: > The patch also makes Ctrl+Shift+Tab work. Superb! Thanks for clarifying this. re: comment #69: > i'm so glad we're changing this so we can be inconsistent w/ msexcel2000 I'm suspecting that you're a "my glass is half empty" kinda person ;) As per comment #57, the ctrl-page key commands will continue to operate just as they do now ; this ensures consistency between both spreadsheet apps, and the ctrl-tab behaviour of other apps, thus (hopefully) meeting the expectations of as many people as possible.
How about something more flexible? The ability to assign user-defined keyboard shortcuts to any of the menu items and other actions available in Mozilla? This would give Mozilla max flexibility and avoid all these "I want this shortcut not that shortcut, but only on Win32, on Mac give me the other shortcut" sort of bugs...
You can already do this for anything that has an associated command. If it does not have a command, file a bug. See http://mozilla.org/unix/customizing.html#keys This bug is about the _default_ behavior. You can always customize your setup to smithereens from there.
having used teratermpro, netscape4, msexcel2000 and some other apps, i'm going to pretend to expect ctrl-tab to do window switching. (note that i've written tirades about n4's ctrl-tab and f6 behavior, but i can still pretend to expect a given behavior) i'm more of a devil's advocate than glass is half-empty, but it's close enough. anyway, back to content. i'm going to assert that jst's statement in comment 0 disagrees with ms's view in msexcel2000. ctrl-tab switches windows, ctrl-pagedown switches through grouped objects. comment 3. excel isn't [normally] mdi (jst got that right, but picked the wrong keys) Window Switching Tab Switching Frame Switching Mac ? Cmd+; Ctrl+PgDn Ctrl+Tab Windows Ctrl+Tab Ctrl+PgDn F6 Gnome ? Ctrl+F6 Ctrl+PgDn ? Ctrl+Tab, F6 The tail of comment 17 is an argument for ctrl-tab to switch windows even though the commenter thought otherwise. Speaking of frame switching, i don't suppose i could sell people on this edit box as a frame so that i could use the frame switching key to leave it and type a tab character by pressing <tab> :^?
> having used teratermpro, netscape4, msexcel2000 and some other apps, i'm going > to pretend to expect ctrl-tab to do window switching. (note that i've written > tirades about n4's ctrl-tab and f6 behavior, but i can still pretend to expect a > given behavior) Given that you yourself have critiqued Netscape 4 in this regard, and that I've never even heard of teratermpro, and that it was Excel that you originally listed, I'm going to assume Excel is the strongest argument in favour, and therefore I'm going to use Excel in terms of a response: Excel is a pretty weak argument for UI consistency as regards ctrl-tab, because Excel is part of MS office, and therefore we should at least expect Excel to be consistent with the other apps sold in the same box as it for ctrl-tab behaviour, right? Wrong! Consider how ctrl-tab operates in Office, when pressing ctrl-tab using the following office apps with multiple windows open for that app: Word: inserts a tab or is ignored, depending on what's selected PowerPoint: inserts a tab or is ignored, depending on what's selected Access: toggles between the different DB elements or is ignored, depending on what's selected Excel: switches to next excel window However, if you wanted to use Office as the basis for an argument for intra-app window switching, you could do so. However, the command you'd have to be arguing for would be Ctrl-F6, not Ctrl-tab. Consider the effect of pressing Ctrl-F6 under the same conditions as above: Word: switches to next word window PowerPoint: Changes text alignment Access: switches to next access window Excel: switches to next excel window Due to PowerPoint it's not a perfect argument, but it is a stronger one, plus it still applies to Excel. So, what if that idea was used in Mozilla: Next Mozilla window Tab Switching Frame Switching Windows Ctrl-F6 Ctrl+Tab, Ctrl-PgDn [Whatever] That way there's a consistent set of keys to learn that will work in most of Office and Mozilla for intra-app window switching (Ctrl-F6), plus you can continue to use Ctrl-PgDn for tab switching just as you do now, plus the bulk of people that expect Ctrl-Tab to do what it does in the majority of apps (i.e. switch tabs) are happy too. Would that be an acceptable compromise?
Comment on attachment 93988 [details] [diff] [review] patch So didn't you have a patch that registers the ctrl+tab and ctrl+pg-up/dn listener(s) with the window so they work "everywhere"?
Attachment #93988 - Flags: superreview+
This does it in JS, though somewhat inefficiently - XBL event handlers would do all the key filtering stuff in C++ but attachto isn't implemented (yet :-) <field name="globalKeyEventHandler" readonly="true"> <![CDATA[({ tabbox: this, handleEvent: function handleEvent(event) { switch (event.keyCode) { case event.DOM_VK_TAB: if (event.ctrlKey && !event.altKey && !event.metaKey) if (this.tabbox._tabs && this.tabbox.handleCtrlTab) { this.tabbox._tabs.advanceSelectedTab(event.shiftKey ? -1 : 1); event.stopPropagation(); event.preventDefault(); } break; case event.DOM_VK_PAGE_UP: if (event.ctrlKey && !event.shiftKey && !event.altKey && !event.metaKey) if (this.tabbox._tabs && this.tabbox.handleCtrlPageUpDown) { this.tabbox._tabs.advanceSelectedTab(-1); event.stopPropagation(); event.preventDefault(); } break; case event.DOM_VK_PAGE_DOWN: if (event.ctrlKey && !event.shiftKey && !event.altKey && !event.metaKey) if (this.tabbox._tabs && this.tabbox.handleCtrlPageUpDown) { this.tabbox._tabs.advanceSelectedTab(1); event.stopPropagation(); event.preventDefault(); } break; } } })]]> </field> <constructor> document.addEventListener("keypress", globalKeyEventHandler, true); </constructor> <destructor> document.removeEventListener("keypress", globalKeyEventHandler, true); </destructor>
jag, neil: that's bug 114170. Yes, I have a patch in that bug, which I'm still working on.
Just filed bug 161955: "RFE: When link is focused, Accel+T to open link in new tab, Accel+N to open link in new window" Seeking opinions.
Depends on: 114170
checked in trunk (Neil asked me to do so during irc chat)
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Works pretty nice on 2002091108/Win2k.
And it works beautifully on Linux 2002091108. Thanks!
I thought the plan was to leave Mac alone, since we can't use the function keys there to navigate frames! What happened to that plan?
filed bug 169589 re comment 82.
Keywords: access
QA Contact: jrgm → sairuh
*** Bug 169640 has been marked as a duplicate of this bug. ***
vrfy'd fixed (other than bug 169589), otherwise.
Status: RESOLVED → VERIFIED
Requesting fix on windows platform. On build Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2a) Gecko/20020910 keys behave as follows: CTRL-tab, CTRL-SHIFT-tab, F6, CTRL-F6, CTRL-SHIFT-F6 - all these keys switch between "location" and page area. Requested behaviour : CTRL-tab switch between browser windows (as Netscape 3 and 4 do). I miss this way of switching windows a lot in Mozilla. CTRL-PageUp, CTRL-PageDn are ok for tab switching.
*** Bug 170323 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: