Closed Bug 25455 Opened 25 years ago Closed 24 years ago

window tiling: New Browser appears above existing one

Categories

(SeaMonkey :: UI Design, defect, P2)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: nathan, Assigned: bugs)

References

Details

(Whiteboard: [nsbeta3-])

Attachments

(1 file)

implement per-window-type cascading.
7.13 KB, patch
Details | Diff | Splinter Review 
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.
Component: Browser-General → UE/UI
Summary: Right click on link, Open new Window. New Browser appears over exsitning one → New Browser appears above existing one
elig, how is thie working with each of the 3 platforms?

don, who gets this?
Assignee: nobody → don
Component: UE/UI → Browser-General
QA Contact: nobody → elig
Yep, it should.  Let's fix it post beta 1 tho'.  Ben, who should own this?
Assignee: don → ben
Priority: P3 → P2
Target Milestone: M15
[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.
OS: Windows NT → All
Hardware: PC → All
Status: NEW → ASSIGNED
not a priority, pushing out as far as possible.
Target Milestone: M15 → M20
Target Milestone: M20 → M30
*** 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).
Keywords: nsbeta3
Whiteboard: [b3nav+]
*** 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
Summary: New Browser appears above existing one → window tiling: New Browser appears above existing one
*** Bug 10979 has been marked as a duplicate of this bug. ***
nav triage team: [b3nav+] now = [nsbeta3+]
Whiteboard: [b3nav+] → [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)
Component: Browser-General → XP Toolkit/Widgets
QA Contact: elig → jrgm
Priority: P2 → P3
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.
Assignee: ben → trudelle
Status: ASSIGNED → NEW
Priority: P3 → P1
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.
Whiteboard: [nsbeta3+]
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.
Whiteboard: [nsbeta3-]
Target Milestone: M30 → Future
Status: NEW → ASSIGNED
*** Bug 54727 has been marked as a duplicate of this bug. ***
*** Bug 54623 has been marked as a duplicate of this bug. ***
Keywords: mostfreq
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
Assignee: trudelle → don
Status: ASSIGNED → NEW
Component: XP Toolkit/Widgets → XP Apps
QA Contact: jrgm → sairuh
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
Assignee: don → vishy
nav triage team:

Yeah, it's annoying for most people. Marking nsbeta1, p2, reassigning to pchen
Assignee: vishy → pchen
Keywords: nsbeta1
Priority: P1 → P2
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
Target Milestone: Future → 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.
Assignee: pchen → ben
Fix checked in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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!
Status: RESOLVED → VERIFIED
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  |
+---------------------------------------------------------+
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.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: