Closed Bug 20306 Opened 25 years ago Closed 15 years ago

Can't open more than 2 windows with navigator button in component bar

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: rzach, Unassigned)

References

Details

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.
Assignee: nobody → shuang
Component: Browser-General → UE/UI
QA Contact: nobody → elig
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
QA Contact: elig → don
Reassigning to Don, who should know who to give this to.
Assignee: shuang → don
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.
Assignee: don → law
Target Milestone: M16
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
*** 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.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
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
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
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.
OS: Linux → All
Hardware: PC → All
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
Target Milestone: M16 → M18
Dean: QuickLaunch bar, Start menu, system tray, whatever ... see bug 28174.

Move to M21 target milestone.
Target Milestone: M18 → M21
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. ***
QA Contact: don → mpt
Marking helpwanted per law.
Keywords: helpwanted
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.
Keywords: mozilla0.9
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...
QA Contact: mpt → zach
> 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.)
Assignee: law → disttsc
Status: REOPENED → NEW
Component: User Interface: Design Feedback → XP Apps: GUI Features
QA Contact: zach → sairuh
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
Assignee: jag → jaggernaut
->future
Target Milestone: --- → 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. ***
Blocks: 104125
filter keyword: nothingnessless
*** Bug 154785 has been marked as a duplicate of this bug. ***
Blocks: 157199
Summary: Can't open more than 2 windows with navigator button → Can't open more than 2 windows with navigator button in component bar
No longer blocks: 157199
*** 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.
Product: Core → Mozilla Application Suite
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).
Severity: normal → enhancement
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.
Assignee: jag → nobody
QA Contact: bugzilla → guifeatures
Component: XP Apps: GUI Features → UI Design
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
Status: NEW → RESOLVED
Closed: 25 years ago → 15 years ago
Keywords: helpwanted
Priority: P3 → --
Resolution: --- → WONTFIX
Target Milestone: Future → ---
You need to log in before you can comment on or make changes to this bug.