When a new window is created it should appear cascaded from the original. Mozilla creates it directly over the original. It should behave like other windows apps (obvoiusly only on Windows!)

Changing summary. I should add that, if the browser is in full-screen, the new window should open in full-screen, too.

elig, how is thie working with each of the 3 platforms? don, who gets this?

Yep, it should. Let's fix it post beta 1 tho'. Ben, who should own this?

[Changing OS/Platform to 'All'.] This appears partially working on Mac OS --- there are two window locations that alternate, rather than cascading down the screen as Comm 4.x did. On Linux, windows repeatedly appear on top of each other --- but, it does so on Comm 4.x for Linux, too. I'm not sure if that's a bug or a feature, and defer to an X-head.

not a priority, pushing out as far as possible.

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

Er, um, this is an important bit of functionality (window cascading). Adding the [b3nav+] from the dup (whatever that means). And ... isn't this danm's type of bug (although he may have a dup of this anyways).

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

This needs to be fixed for editor windows too.

this sounds like a duplicate of bug #10979; can someone tell me how they are different?

changing summary to say window tiling

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

nav triage team: [b3nav+] now = [nsbeta3+]

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

Mail and Address Books windows should follow this too.

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

isn't this really a danm bug? changing component to toolkit. (so I can find the stinkin' dupes next time)

nav triage team: we have already long ago nsbeta3+'d this bug and have determined it to be high priority (P1)due to the useability concerns. However, it is misassigned, so reassigning to XPToolkit team. We realize that our triage results aren't yours but nonetheless, we already went through the process.

clearing nsbeta3+ for triage by new owners. I really think this is an application policy issue though, not a widget-level issue. In fact, one of the dups was an XPApps feature that missed the cuttoff. Given the known bugs, incoming rate, and time/resource constraints, I don't think this deserves to be on our nsbeta3+ list, but I'm willing to listen to reason.

Like Bug 48108 says, I think users are going to be very confused when a new window appears directly on top of the old one, covering it up 100%. It looks like the old window disapeared, in Windows at least. There is also 5 dups of this bug and both Nav 4 and IE do this properly.

I agree that this is a desirable feature, but please understand my point of view. Right now, the person who would own this is working on a bug where we crash clicking on just about anything. That kind of problem will confuse users a lot more, and we have too many bugs like that. Why is this one worse? I need to know that in order to delay other bugs to work on this.

Arg. In the last couple of nightly builds on Linux (window manger Window Maker), I see the extreme opposite of this behavior. At first, new windows appear normally (cascaded, basically), but after a while, they start appearing on the extreme right of the screen so that only a few pixels are visible. Closing all other windows doesn't help -- the new ones still want to be there. If you exit and restart, the first window is normal, but all future ones are still way off to the right. Deleting my ~/.mozilla directory fixes the problem temporarily, but then it comes back. Is this some sort of overcorrection to the problem listed here?

I think this feature is more than desirable, certainly it is expected on Windows (an on the other platforms). If the argument is that it won't get fixed before release than I would disagree becuase it will confuse a lot of users and me one more excuse not to bother switching from their other browser. If it is just that 'Right Now' the fixer is too busy but it will be fixed before release then fair enough leave it (until later).

Matthew: what you're describing sounds like a separate problem, deserving a separate bug report. Nathan: I think I've been clear about our predicament. We cannot afford to keep adding features just because they are expected. To fix this, we'd have to leave one or more other defects in the product.

cc pav. Is this another case where we should just let the WM handle the window positioning/sizing?

peter - yes. because the windows all have the same x,y coords saved, we put a new one right on top of the old one.

If this bug fix is on the critical path from release then leave it till later. I'll definately vote for a robust not-so full featured product soon, rather than either a fragile product soon , or 'all' the features late.

nsbeta3-/future. we aren't going to do add a new window tiling feature at this point, although this may be covered by other bugfixes on some platforms by allowing the window manager to place the windows.

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

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

This is especially problematic because of bug 34930. If the second window is at the same web location, there is almost no visual indication when the second window is closed, which will lead users to close both windows.

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

I think the apps folks wrote some new code for this, although it has problems too. ->xpapps

This isn't a bug. I love the way Mozilla open the window exactly where the previous one was. I move and size my browser window to exactly where i want it (as does anybody not working in full screen - beginners work in full screen, so they aren't even affected). What better feature than to have the new window nicely placed where you want it. The windows taskbar shows what programs are open, so I really don't see how anybody could get confused. Please, please leave this feature as it is.

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

nav triage team: Yeah, it's annoying for most people. Marking nsbeta1, p2, reassigning to pchen

Shouldn't the Target Milestone be unset or set to mozilla0.9. Future contradicts the nav triage comment.

nav triage team: Whoops, missed that, marking mozilla0.9

OK, if you really must break this good feature (placing the new window where the old one was - namely where the user wants his window to be), then at least don't move or resize the new window TOO much. 3-5 millimeters should be more than enough for anyone to see that there are two windows (duh, each task is shown in the taskbar), without completely rearranging the users' chosen windows position.

This really is a bug, but some people obviously like it. Any chance of making it an option?

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

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

A new Browser window SHOULD appear above existing one (as an option). I love the way Mozilla opens a new window exactly where the previous one was. I move and size my browser window to exactly where i want it (as does anybody not working in full screen - beginners work in full screen, so they aren't even affected). What better feature than to have the new window nicely placed where you want it. The windows taskbar shows what programs are open, so I really don't see how anybody could get confused. Most "windowed" windows take up at least 80-90% of the screen; so if one has more than 5-10 windows open at a time, it is nearly impossible to switch between windows by clicking on a covered window (and get the right one) anyway. The only way to do it without getting the wrong window or accidentally clicking a vertical scrollbar or resizing a window (causing a refresh) is via the toolbar. Please, please leave this feature as it is - or at least make it an OPTION.

Certainly, as an option, it is fine. But many of us run browser windows at 780-1024 pixels wide while running at 1280x1024 or 1600x1200. In those cases, cascading is extremely valuable. I depend on it very heavily with Netscape 4.x.

How about an option in prefs to please everyone? Should it be default on?

added self to cc

An option in prefs sounds GREAT. Thank you. My preference would be to have it ON by default (i.e. location exactly as previous window). The previous comment by Joel: MOST people use 800x600 and 1024x768 - here cascading is definetely not as desirable as at the unusually high res's you were quoting. At 1024, a windowed window already fills most of the screen and cascading only tends to do weird things. Usually computer "freaks" have such high res's and they would know where to turn ON cascading in the prefs. Therefore, i suggest to have cascading OFF by default for the majority of users with "normal" resolutions.

We also have the consistancy problem. Almost every other app that opens multiple windows on Windows at least cascades them, and I would really like that too. The main reason being to make it easier to go back to the previous window when I "open in new window". Right now when I have done that I have to check all the open mozillas (there can be many) in the taskbar to find the right one. The icons in the taskbar are often not big enough to show even the first letter of the window title. If the windows cascade, it's just to click the window title bar right above the current window's title bar.

For consistancy, cascading should be the default. Putting windows directly on top of each other is quirky and weird. I don't mean to disparage people who like it that way -- just that it is nonstandard UI behavior.

not to mention contributing to novice users who can't tell when a new window has been launched.

Peter Lairo wrote: > The windows taskbar shows what programs are open, so I really don't see how anybody could get confused. You can't assume this, it's possible to have the taskbar on auto hide so it's only visible when you move your mouse to the bottom of the screen, I know people who do this. Also a few people may be running a different window manager such as litestep (www.litestep.net) which doesn't have the Win32 taskbar. Also looking to the future Windows Whislter is going to do things in a similar way to the BeOS taskbar and only have one item for each application instead of each Window to see the list on individual Windows you'll have to click on the appropriate application which will pop up a list, this is intended to reduce taskbar clutter. I expect the old default behaviour of one taskbar entry per window will still be available as an option. As for making this bugfix an option personally I believe if we do make it an option it should just be one of these options that you'd have to change by altering the prefs manually, I don't see many people wanting this pref and it would just add confusion and pref clutter (what wording could we use for the pref?)

Exactly. Having windows appear immediately on top of each other would be confusing enough; making it an option would be even worse.

I really don't see at all how giving users an option could ever be a bad thing. There are entire OS's that have this as default behaviour. Since M$ Win is the most used OS, I agree that the default should probably be to cascade, but please please include an option in prefs to have new windows opened on top of the previous one. I suggest adding this preference to prefs - appearance. There is plenty of space there right under "Show Tooltips" and is applicable because it affects the general appearance of the app. Suggested Radio Buttons: Placement of new windows <> New Mozilla windows are opened Cascaded (Default) <> New Mozilla windows are opened directly on top of each other

On Linux, under both KDE and good old TWM, mozilla 0.7 (nor the earlier milestones I've used) does not even seem to have the ability to specify the initial position of the first window opened, nor does mozilla remember the location from one start to the next (it remembers the size, but not position). Cascading aside, it would be nice to have the ability, like I had with Netscape 4.x, to specify the position of the initial window, or, at least, for mozilla to remember from one run to the next, where its browser window was positioned (a la IE on windows).

I was complaining to a friend that I never get any email and he said "Sign up for Bug 25455 and you'll never be lonely again!" I see what he means. Look, it's a bug to 99% of the users. Fix it and be done with it.

Placing of new windows should follow what is customary for the platform. On Windows this means cascading. NN4 and IE5 does this too. It is extremly confusing clicking on links that opens a new window, because you think it was opened in place and you are wondering why you can't go back.

if an option is easy to implement, it would be helpful if you could do so. If not, so be it (pity). Maybe some of us then aren't forced to work in a "customary" way. All that can be said on this subject has been said. It is now up to the development team to decide how they want to proceed. shhhhhh.

I have a fix for this.

sr=hyatt

Fix checked in.

Yeah!

This prevents from opening first window on previous place. Browser does not uses saved window position for first window, not "new above existing"

Verified Fixed on trunk build from today. Finally fixed!

I would submit that this is only half fixed. All "secondary" windows open in a tiled position relative to the original window, but are still stacked on top of one another. So it still doesn't behave like IE which tiles all additional windows, not just the first. This is what I am seeing on build 2001-01-30-Mtrunk on NT.

That sounds like the way that Netscape 4.07 works for me on Win2k. I'm constantly going to the window at the bottom and opening up the new blank window from there.

I have a sneaking suspicion that this fix is causing bug 67079.

danm fixed my broken logic in his fix for 67079, and also added some other nice tricks: - no window will ever open directly over another (with a small amount of slop) - it now really does work for multiple monitors (except on Windows, where nsWindow::ConstrainPosition appears to be busted).

This fix is a horrible day in app development - windows spawning all over the place, even the first window is now not where the user wants it. Could you at least include a pref do disable this terrible feature?

Get a build tomorrow, these issues have been addressed in 67079.

please see my bug 67149 that suggests adding a pref to disable/enable window tiling (to fix what this bug-fix broke). There should be a pref under "Appearance" for: +-- Window Positioning -----------------------------------+ | <> Cascade new Mozilla windows (default) | | <> Open new windows directly on top of previous window | +---------------------------------------------------------+

no.

geezer

I vote for Peter Lairo's pref in appearances

mrmazda@atlantic.net: that's covered by bug 67149. Even though the bug is currently marked wontfix, you can still vote for it.