After two browser windows are open, the navigator button (bottom left corner, beneat the sidebar) no longer works. To reproduce: 1. Click the navigator button. A second browser window appears 2. Click it again. Actual result: Button depresses, but nothing happens. Expected result: A new browser window should appear. On Linux build 1999112908 Additional info: 1. Might be related to 7672. 2. File|New Navigator Window works for more than 2 windows.

Reassigning all of leger's unscreened Browser-General bugs to nobody@mozilla.org for pre-screening and triage.

The described behaviour matches the 4.x behaviour on WinNT (1999122208). So is this by design/spec. To be specific: 1) if 1 browser window currently, it opens a second window 2) with 2 browser windows currently open, the button brings the other window to the foreground 3) with 3+ browser windows currently open, the button cycles through the currently open browser windows 1->2->3->1... (although you must press the button in the currently open foreground browser window to get the cycle, and I never knew this before now). Passing to shuang/elig -- default owner/qa for UI/UE

Reassigning to Don, who should know who to give this to.

I believe the spec as described by 3jrgm is correct thus the implementation should be done as current 4.x. reassign it to don. eli, do you think we should change the bug title ( since navigator button does not open more than 2 windows) ?

If the implementation should be done as current 4.x, then there is nothing that needs to be done. The behaviour I described 12/24 is how mozilla 2000010908 win95 functions today (and then). (On the other hand, I (a user survey of exactly one :-} find it less ambiguous if the button always opens a new window, but it makes no real difference to me -- I always use keystroke Ctrl-N anyways).

still a bug, should match File | New Navigator Window, which can do n new windows. m16, post-beta, law.

Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.

*** Bug 31445 has been marked as a duplicate of this bug. ***

It works the way it worked in 4.x (on windows, at least). Worst case, preserving this behavior provides users the comfort of a familiar environment. Lacking any evidence that some alternative is quantifiably better, I think we should leave it the way it was/is. Note that there is considerable utility provided by the current behavior, not provided by other means. If you want Ctrl-N, press Ctrl-N.

The way it works in Windows is redundant and useless. We have the taskbar, and mozilla has a tab that brings up a list of all of the current open windows, which is better than blindly switching to the next window. Therefore, this is of no utility, not considerable utility provided by no other means. (Here is evidence that the "other" way is better) There is, however, no way to open up a new window (a VERY useful thing) with one mouse click. Ctrl-N does not count as it is a not mouse click. Taking one's hand from the mouse to the keyboard is the biggest inconvenience a browser can create. This is as bad as having to right click to open a link in a new window, while we could use the middle mouse button (another bug which is going to be fixed). I strongly disagree with the dismissal of this bug and it's resolution as invalid. Could someone please remark it as something to be changed?

OK, so there might be some reason why you'd want it to work that way. But I wouldn't want to fundamentally change the way this works from 4.x without a bigger groundswell of support. BTW, create a personal toolbar button with the url javascript:window.open() and you've got your one-mouse-click new window button!

Marking Verified as invalid. Won't Fix for Seamonkey this version

I hope you all would reconsider fixing the bug. Just becase Netscape 4.x did something wrong does not mean mozilla does also :)

Given the discussion that occurred in n.p.m.ui this week, nobody likes how it behaves no, the 4.x behavior. The support seemed to be behind having it always open a new window.

Not to be an ass, but I am reopening this. The discussion on UI merits it I feel, and as asj mentioned, no one had any say on what 4.x did or does. Perhaps a pref would be good for this, but the whole point of having the taskbar there, imo, was for when netcaster came out and wanted to hide the start menu. Netcaster is dead, and thus make the default behavior silly.

Using the Navigator button to cycle between windows is silly for several reasons. * You have to specify a different, inconsistent, behavior for the button when only one window is open. * There are already two quicker ways of getting to the exact window you want -- the Open Windows menu, and the Tasks menu. In addition, a platform-universal method of cycling through windows is also available on all platforms (except MacOS). * If the button doesn't cycle to the window you want, you have to move the mouse in order to get to the same button on the next window. This makes it too much of a waste of time to be useful, so one of the other methods mentioned above will be used instead. So if the spec specifies the same behavior as 4.x, then the spec is misguided. Until now, I had assumed that the 4.x behavior was a bug.

Here is one voice in favor of the 4.x functionality. I use the cycle-window button all the time.

*** Bug 31561 has been marked as a duplicate of this bug. ***

Two issues that came out of bug #31561 ... 1) *IF* the final implementation will be to match Nav4.x behaviour, then one platform parity difference should be addressed, namely: On win32, if a) you have two or more browser windows open b) window B is behind window A c) user clicks on the wheel icon of window B Actual behaviour: Window B is initially raised to the top, but is immediately covered by Window A, resulting in a brief flash of Window B on the screen. Expected behaviour: Window B should be raised to the top, as if any other visible part of Window B had been clicked. Mac (4.x/mozilla) and Linux (4.x) exhibit the "Expected behaviour". 2) The current implementation on Linux of toNavigator (CycleWindow) does *not* raise the next window in the cycle. It will create a second window, but will not otherwise raise another window (2000032410 linux rh6.1)

*** Bug 31303 has been marked as a duplicate of this bug. ***

*** Bug 34956 has been marked as a duplicate of this bug. ***

Ok, how about this. {component} = Navigator, or Messenger, or Composer, or whatever. * If you have no {component} window open, clicking the {component} button in any window opens a {component} window. * If you have 1 or more {component} windows open, clicking the {component} button in any window which belongs to the *same* component opens a new window for that component. But clicking the {component} button in any window for a *different* component just switches to the most recently used window for that component. Example: you have 1 Messenger window and 2 Navigator windows open. Clicking the Navigator button in the Messenger window switches to the most recent Navigator window. But clicking the Navigator button in the Navigator window opens a new Navigator window, rather than switching to the other Navigator window. This would still be slightly inconsistent, but no more so than the 4.x implementation, and I think it would be more intuitive.

That last suggestion makes some sense, but I would have to once again ask why (windows users) need a button to get to an open page (which one? how would it be determined?)if the taskbar is a few pixels away. And if we were used to the navigator icon giving us a new window most of the time, this behavior could get frustrating. Just my opinion, what do say, mpt? In retrospect, when the component toolbar is undocked (ie floating), the window cycling behavior can be pretty spiffy as a fast way to flip through open pages. It's not as useful when sitting in the bottom of the window, though. It seems that mozilla probably won't have this undocking behavior, so the fact that the cycling is usefull when the component bar is undocked is null. I could see some group getting together and making a floating control window like the one that the component bar becomes in 4.x, and having it appear by selecting it from tasks, much like a history or bookmarks window. Then we'd have the best of both worlds.

Actually, I'm coming to the conclusion that Mozilla should not have a component bar at all. The component bar is trying to be both a task launcher, a window switcher, and a biff utility all at once; as a result it is doing none of these jobs well, and it is producing bugs like this one (and all the bugs which have been marked as a dup of this one). Task launching is better done by shortcuts to the relevant chrome URLs in the QuickLaunch toolbar (Windows), the Launcher (MacOS), or the equivalent for your favorite X desktop. Window switching is better done, with only one click, by the Windows taskbar (Windows), the Window or Tasks menu (MacOS), or the equivalent for your favorite X desktop. And e-mail notification can be done better by a separate window (or even a separate XUL utility), which can be put anywhere on the screen and which can show additional info such as the number of messages waiting. So I think the component bar should go. Assuming that such a radical change is unlikely to be implemented in this Mozilla version, however, my recommendation for the component bar's behavior (while the component bar still exists) remains unchanged.

I like your idea mpt about only opening a new window if you are in the same component. But this could also be confusing as sometimes it will open a new window and other times not. You can always use the taskbar to switch to the window you want anyways. I think the best idea would be for it always to open a new window.

I agree with David. Unless we get to the point where there's a floating component bar, which I think would be a separate module. Matthew, your idea is closer to a behavior that makes sense, but as you pointed out it's still slightly inconsistent. Sure, 4.x had the window-cycling functionality, but that was only for the floating component bar. I have the bar docked because it takes up less space that way. I had always assumed - until recently that is - that clicking a button always opened a new window. I was more than a little surprised when I found out that this wasn't the case. But I find that I actually do use the component bar in Moz. Mostly it's to open mail, but if I use it to open a new mail window then I'm thinking that there's a bunch of people out there that use it to open a new browser window as well. Also, Matt you said that, "Task launching is better done by shortcuts to the relevant chrome URLs in the QuickLaunch toolbar (Windows)". I don't have the QuickLaunch bar / Desktop Update installed in Windows, and neither do half of the people in my office, so this isn't a concrete alternative.

pushing out to m18 for now

Dean: QuickLaunch bar, Start menu, system tray, whatever ... see bug 28174.

Move to M21 target milestone.

Well, I can easily implement mpt's suggestion (I cleaned up that bit of JS code), and probably any other (sensible) algorithm thought of, if/when someone makes a decision.

I don't want to spam, but how will the final decision be made and who has to make it? Should we bring the debate to the newsgroups? If Mr. Annema is ready to go, I'd like to see this bug resolved. Personally, this bug in NS4.x is what got me interested in Mozilla in the first place and I'd like to see how it plays out. (I'm for M. Thomas' resolution or just always opening a new nav window myself).

A decision will be made when the bug is assigned to someone who feels able to make a decision about it. If you think they are taking too long, then take the issue up the mozilla.org food chain as appropriate. Or, Peter Anemma could just make his patch and try for review/approval as a way of forcing a decision, in the knowledge that the patch might be declined.

To be clear, a decision was made 6 months ago. At least one Netscape engineer, and one member of the "Net community" (3jrgm) disagreed with the choice, but them's the breaks. This will not be changed at this point on the Netscape branch. However, a lot of people have spoken since then in favour of an alternate behaviour for this button. The most compelling argument in favour of making a change would be working code, which I know Peter is capable of producing. With working code, and broad support, I expect that this might well be approved (and Netscape would have to work around it if Netscape is determined to retain this behaviour).

Heh. This bug is assigned to me. But there just isn't any way I'm going to do anything with it anytime soon. I will have the same problem in the near future that I've had since this was reopened: I must work on the bugs that *must* be fixsed in the next Netscape release (it was PR1, then PR2, then PR3, now RTM). This isn't such a bug. If somebody wants to do something with it short term, please take it from me, pretty please!

See bug 8002 for more discussion about whether reusing windows for Ctrl+1, Tasks|Navigator, and the Navigator "taskbar" button makes sense or not.

*** Bug 61375 has been marked as a duplicate of this bug. ***

Marking helpwanted per law.

BAH, I had no idea that the "Press navigator button -> Flip to other open navigator window" was desired behaviour. I always thought it was a silly bug. I liked mpt's original suggestion that if you're in the same component, you launch a new instance, if you're in a different component, then you first switch to any pre-existing instances before launching a new one. Using that bar as a task switcher is counter-intuitive, most users (who haven't been exposed to that behaviour in NS 4.x) expect those buttons to only launch a new instance, and *maybe* if you're selecting a different component, to switch to open instances of it first. The current behaviour will be viewed as buggy by the average user, even if it is as intended by design. Anyways, there's another problem with the current implementation which is DEFINATELY a bug: 1) Open new browser from first one. 2) Open mail window. 3) Close first browser window (hit "x"). 4) Press Navigator button -> Switches to open mail window! Nominating this for some kind of a decision for Mozilla 0.9, because the current behaviour will be seen as buggy by most new users.

Something's going wrong with getMostRecentWindow(windowType) there (see bug 8002 for more).

How about we keep both behaviors. Right-click does one option (open new browser window or flip browser windows) and left-click does the other.

To add to Ben Ruppel's comment (left vs right click on buttons): Ctrl+1 could open a new Navigator window and Ctrl+Shift+1 could cycle among open Navigator windows. Opening a new window should be the default action because: - There are plenty of other ways to switch windows (find the window title on the Tasks menu, use the OS taskbar, Alt+Tab). - Switching between windows of a single app is app-centric, which doesn't really make sense for Mozilla, since different browser windows often contain unrelated information.

could we use alt-1 for windows switching? i'd prefer ctrl-shift-1 to activate composer [alt-shift-1 could switch among composers].

Timeless: why do you think we need three different shortcuts? It might make sense to have Ctrl+1 focus a Navigator window if a Mail window is currently focused, but IMO pressing Ctrl+1 from a Navigator window should always open a new Navigator window.

ctrl-1=>open new navigator ctrl-shift-1=>open new editor alt-1=>switch to next navigator alt-shift-1=>switch to next editor ctrl-2=>open mail? ctrl-shift-2=>open address book alt-2=>switch to next mail alt-shift-2=>switch to next address book ... [2 might not be mail, i don't remember]

Timeless: I'd rather not use up alt+number and ctrl+alt+number just so composer and address book can have redundant shortcuts. They already have 4 and 5; why add shift+1 and shift+2?

i'd like to return 4 and 5 to the free list.

As a rule you should use "accel" for the modifier, only in a few exceptional cases (backward compatibility) is hardcoding "alt" okay. I don't see what exactly we need all these accelerators for. Switching between windows works fine through the platform's own mechanism and we're providing an "open windows" list on top of that. Your suggestion to move starting a task from accel+num to shift+accel+otherNum seems bad to me, partially because of backward compatibility, partially because you're adding an extra modifier (shift), and partially because you're moving from a simply system (accel+num is start a task, so you only have to remember the number) to a more complex system (accel+num or accel+shift+num to start a task, where you have to remember the number, and the modifier combo). I think we should just always open a new window, unless we have a good reason to only have maximally one instance open, in which case we switch to the open instance. So why do you want to "return 4 and 5 to the free list"?

I agree with jag. One minor point: I think we meant ctrl to be accel (rather than alt being accel). Accel is just too awkward to type.. it needs a synonym that doesn't start with A (like Alt) or C (like Cmd and Ctrl). If jag and I get our way, though, that won't matter for this bug though :)

It's not a matter of getting our way, it's a matter of doing what makes sense. Timeless' suggestion doesn't make sense (to me, at least). On the name of accel, it's my way to say "the default accelerator modifier, as determined by the platform / chosen by the user". So if someone chooses their accelerator to be alt, then these accelerator keys will be alt+1, alt+2, etc., if they choose ctrl it will be ctrl+1, ctrl+2, etc.

we already have ctrl-n => navigator ctrl-shift-n => editor the following should logically follow ctrl-1 => navigator ctrl-shift-1 => editor in fact, the above is logically foolish, why assign both 1 and N to the same problem? fwiw, ctrl-shift-2 opened address book in nc4 which makes a lot of sense since ctrl-2 opens mail. As for the free list, there are many projects based on mozilla and if we monopolize the basic numbers (say 1-7) then that means it will be very hard for users to use other components that they add. I think the best solution is to transition the tasks menu into bookmarks and include a field that users can use to assign hotkeys (ie does this with all shortcuts).

timeless: IMO, Ctrl+1 and Ctrl+N are both Navigator because Ctrl+N will be "clone window" in the future (like it is in IE), whereas Ctrl+1 will open a fresh window to the homepage or to a blank page, depending on the startup pref. I think it's best to use shift as the "switch between" modifier because shift is least likely to be the user's accel key :) Using shift on numbers may cause internationalization problems, though. Mozilla shouldn't reserve large blocks of keys for launching Mozilla-based apps, since it doesn't make sense to include an option to launch any Mozilla- based app (but no others) in the task menu of every other Mozilla-based app. The operating system can provide a way to add shortcuts for launching those apps, just like it does for all others. Reserving a block for user-defined shortcuts (possibly using bookmarklets as a backend) would be nice, though. I think it would make sense to give users Ctrl+num (if accel isn't ctrl), Alt+num (if accel isn't alt and the user doesn't mind conflicts with page accesskeys), and Ctrl+Alt+num. But that's another bug.

Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...

> alt-1=>switch to next navigator > alt-shift-1=>switch to next editor >... > alt-2=>switch to next mail > alt-shift-2=>switch to next address book Sorry, those combos are reserved for typing the `¡' (Spanish opening exclamation mark), `/' (vulgar fraction bar), `™' (trademark), and `€' (euro) symbols respectively. > in fact, the above is logically foolish, why assign both 1 and N to the same > problem? The fact that accel+N doesn't open a new message composition window in Mozilla's mailer (whereas it does in most other GUI mailers), and that accel+N doesn't open a new document in Composer (whereas it does in most other GUI editors), is a rather bad UI bug in Mozilla. It can be fixed, and I'd like it to be fixed, but it would take a couple of years to fix it in the way that was least painful to existing users. (Someone file a bug, if they want.) Reassigning to Jag based on Law's 2000-10-12 comment, for Jag to fix before this bug report gets out of hand and people start proposing truly disturbing things such as customizing the UI through bookmarks. (Oh, wait. Crap.)

mpt: so can I bug you for a nice spec? :-)

> Matthew Thomas (not reading Bugzilla a.t.m., e-mail me if necessary) I think that means ...

Urgh. Thanks :-)

jag: While the component bar remains in Mozilla, I suggest its operation follow what I described in my 2000-04-26 comment. For consistency, this should apply to the equivalent items in the `Tasks' menu as well as their buttons in the component bar.

I support mpt's scheme and I'd love to see it implemented.

*** Bug 82586 has been marked as a duplicate of this bug. ***

Mass move to jaggernaut@netscape.com

->future

*** Bug 87426 has been marked as a duplicate of this bug. ***

*** Bug 87750 has been marked as a duplicate of this bug. ***

I agree with Robert Crawford. You can't open multiple mail windows or address books. Clicking on those items when their windows are active has no effect. So why should the browser icon be different and always open a new window? Or perhaps you would like a pref for the maximum number of windows to open?

Speaking of prefs, doesn't somebody want a pref to open bookmarks, history, mail message and other externally originated URLs in new browser windows, in which case the taskbutton could respect the same pref?

> You can't open multiple mail windows or address books. Those bugs should be filed separately. > doesn't somebody want a pref to open bookmarks, history, mail message and > other externally originated URLs in new browser windows, That's bug 75138. > in which case the > taskbutton could respect the same pref? No, links for URLs are conceptually very different from buttons for components.

*** Bug 96061 has been marked as a duplicate of this bug. ***

filter keyword: nothingnessless

*** Bug 154785 has been marked as a duplicate of this bug. ***

*** Bug 64678 has been marked as a duplicate of this bug. ***

Strange, this bug is worksforme since months (?) ago. As I can see from duplicates, only one is relatively recent (one month old) and it doesn't mention of the build used. Is it fixed or is there something in my preferences/registry that prevents the bug from appearing? I can open as many windows I want, using the taskbar shortcut and build 2002072904/Win2K. Note: the shortcut is "hand made" (C:\bin\mozilla.exe -p myprofile), since i always use the zipped builds.

Dimitrios -- I think you're talking about something else. This is the little bar at the bottom of the window, not the OS taskbar.

You are right. I had cc'ed myself for exactly the same reason as described in the original report (it is exactly this behaviour inconsistency between the desktop shortcut and the statusbar icon that was always annoying me). Scratch my previous comment.

I believe it would make sense to boldly redefine the meaning of the component bar buttons to simply open a new window of the corresponding type, if possible. Opening a new window is one of the most frequent actions and many people who do most things using the mouse will expect a quick way to do this using the mouse too. The alternate way via the menu is very cumbersome, especially since you have to go different ways depending in which window you are (try to open a new browser window from a browser window, mailnews or the address book). So I believe making the "new" function available for mouse users will find support from most users. Opening new windows would be possible atm for browser, composer and mailnews (mailnews would just add a new window with the default inbox, the user can change this any time to something else). If a component can have only one window, the button should just bring up that window or do nothing if pressed within that window. IMO this is a functionality that is often needed, not otherwise available, easy and intuitive to understand and easy to implement.

johann: what about the idea in comment 22?

Peter, it is all a matter of taste of course so the only way to come to a reasonable decision is either to speculate or to test what the majority of users will find most convenient. In my view there are several arguments against the solution in comment 22: - buttons should work consistently and do what one expects. They should not do different things in different contexts. - it is now and with the solution in comment 22 *especially* complicated to open a new window for a different component (as i pointed out, opening a new different component windows involves several steps that even differ from component to component). Simply changing the behavior to "always open a new window (if possible)" will make this a simple and quick action in *any* situation. - the functionality requested in comment 22 for different components (bring up existing window) is easily accessible by practically every desktop manager I am aware of, especially since the implementation of different icons for different components that get shown in task bars, minimized icons etc. But again, the most important point is that UI elements should behave consistently and not do different things in different situations.

*** Bug 182655 has been marked as a duplicate of this bug. ***

*** Bug 217691 has been marked as a duplicate of this bug. ***

I don't see much likelihood that users universally expect those icons to mean either "switch to" or "open new". I think this bug calls for a UI pref for users to decide the meaning. Personally, I NEVER want a new window opened for a component that already has an open window, so I would choose the "switch to" option, which hopefully would mean "open new" only if that component doesn't already have an open window, and make clicking the focused component icon to nothing. I'd personally go further still, having the icon for the focused window hidden, were it not for the special case of biff.

THis proble still persists on my Linux. Usually I'd been avoiding this by hitting "^N" to create another browser window, but now I use <entry name="gtk_key_theme" mtime="1142436036" type="string"> <stringvalue>Emacs</stringvalue> for key bindings: (in short, key bindings works as if it's in emacs). Then ^N doesn't launch another browser windows (maybe it's interpreted as "next line"). So now the only way to add another browser window is select "File" menu->"New"->"Navigator Window". It's a trouble since clicking mouse some times to open a brwoser window is troublesome. So I hope this bug (hey, is it a feature?) fixed.... Why doesn't by default clicking "M" icon on the left bottom create doesn't work for 3rd or later windows?

Given that this is working as designed (comment 2, et al), this is an enhancement request to "open new window with every click...". I prefer current functionality (echoed in comment 17 and comment 64) as default behavior - which mirrors ctrl-1 behavior. A key which cycles browser windows is, well, nice. The focus of the component bar should IMO be more of an application control/switcher, not a new window creator (if that makes any sense).

I still want to open more than 2 windows at a click or just an easy key shortcut; On X Windows on Linux, I don't mind switchng at all. Since I changed my keyboard theme to Emacs like (using gconf-editor desktop->interface->gtk_ke_theme), ctrl-N doesn't open new navigator window of mozilla/seamonkey built with gtk2. Isn't it a problem? When I want to open more than 2 navigator windows, i need to File->New->Navigator Window, and as many feel, it's a bit troublesome. 3 clicks required. So I strongly want 3 or more navigator windows with an easy operation (key shortcuts or simple mouse click) on Linux or maybe any unix-like OS's.

(In reply to comment #82) > I still want to open more than 2 windows at a click or just an easy key > shortcut; On X Windows on Linux, I don't mind switchng at all. Since I changed > my keyboard theme to Emacs like (using gconf-editor > desktop->interface->gtk_ke_theme), ctrl-N doesn't open new navigator window of > mozilla/seamonkey built with gtk2. Isn't it a problem? look for, and if not found file, a bug? > When I want to open more than 2 navigator windows, i need to > File->New->Navigator Window, and as many feel, it's a bit troublesome. 3 > clicks required. > > So I strongly want 3 or more navigator windows with an easy operation (key > shortcuts or simple mouse click) on Linux or maybe any unix-like OS's. indeed. some ideas... look for a bug request for a new window button for the navigation bar (think I saw one). A 2-click workaround - any bookmark on your personal toolbar (or link on an existing page), right click, new window. Is there an existing (bad word) extension?

>> I still want to open more than 2 windows at a click or just an easy key >> shortcut; On X Windows on Linux, I don't mind switchng at all. Since I changed >> my keyboard theme to Emacs like (using gconf-editor >> desktop->interface->gtk_ke_theme), ctrl-N doesn't open new navigator window of >> mozilla/seamonkey built with gtk2. Isn't it a problem? > >look for, and if not found file, a bug? actually not. maybe a feature. So I think I had filed as a feature enhancement or something, but was redirected to here as duplicate....it's a long ago and I lost where I was from....or I forgot! Should I file again?

Latest comment was 2 years ago. Resetting A+QA on the assumption that they aren't current anymore. Developers, feel free to ACCEPT this bug. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008043002 SeaMonkey/2.0a1pre - Clicking the statusbar browser icon still switches windows without opening a 3rd one, so this bug is not (yet?) FIXED. Alternately, it is conceivable that switching between existing window would be more useful than opening a 3rd one, which would mean WONTFIX. - There does exist "an easy key shortcut", viz., Ctrl+N, which is "discoverable" since it is mentioned on the "File -> New -> Browser window" menu.

Component Bar items work the same way as Accel+1, Accel+2, Accel+4, Accel+5 and Accel+6 in Seamonkey 2. New Navigator windows come with Accel+N. Discussion here gave no clear result. WONTFIX