This is more an idea than a bug, but it seems to me that new windows should take the size (& other parameters) from the window with current focus. If I choose a certain size for a window, chances are that's the size I'd want new windows to be. The current behaviour is that new windows start the same size as the default window.

I can't remember whether we defined this already, re-assign it to german to check it out in the spec.

Agreed this would a desirable enahancement of the current window behavior. Don: can we do this (can be past dogfood)?

This is the way new windows worked in 4.x also. I think this is more than a trivial problem. BTW, mimic the 4.x behaviour regarding position too -- cascading down and to the right, then wrapping if needed.

Agreed, we should do this.

Hmmm, I think we need this for beta 1 'cause it's driving me crazy without this behavior. Bill, is this hard?

Moderately easy. I'm not sure there aren't scenarios where people won't think this is the silliest thing they ever heard of, but it is a simple matter to code up the JS and see how it flies.

Looks like you have way too much to do for beta 1 already.

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

CCing self -- usability bug. Note, this should apply not only to Navigator windows, but also to message windows, and (if they're ever made non-modal) address book card windows.

How about this: * Decide on a certain minimum useful size for a window of the type being asked for (x.min, y.min). * Decide on a certain useful cascading offset for new windows (x.off, y.off). This probably differs for different window types too. For example in browser windows, it would be nice if the offset was enough to see the throbber in the backmost window without moving the frontmost one -- so people browsing with multiple windows could tell when the document in a non-frontmost window had finished loading. * The coords for the new window are based on those of the frontmost existing window of the same type (x1, y1, x2, y2). So if I start a new e-mail message from the menus of an existing message composition window, for example, the new window appears in exactly the same size and position as it would if I started it from a browser window. * Pseudo-code ... (I was going to do this in more detail, but it started getting late:-) /* first we set coords to do an ordinary cascade from the previous window: */ x1.new = x1 + x.off; y1.new = y1 + y.off; x2.new = x2 + x.off; y2.new = y2 + y.off; /* but if those coords make the window fall off the edge of the screen, we need to fix them: */ if (window falls off edge of screen in either dimension) { /* is it a good idea to make the window smaller to fit it on the screen? */ if ( (window isn't plain-text message composition window) and (clipped window positions would >= the minimum size in both dimensions) and (current window >= our recommended minimum size in both dimensions) ) /* it is a good idea, so we can fix the overflow by trimming the right/bottom of the window: */ { clip edges (either or both, whichever necessary) of the window to fit the screen; } else /* it's not a good idea, so we'll need to start a new cascade: */ { x1.new = (left side of screen); y1.new = (top of screen); x2.new = x1.new + (x2 - x1); y2.new = y1.new + (y2 - y1); } } GoAndDrawTheDamnWindow(x1.new, y1.new, x2.new, y2.new); * All of the above should still be worked out even if the frontmost window of the same type is maximized/zoomed. If that window is maximized/zoomed, then the new window should also be maximized/zoomed, but its size and position should still be remembered as defined above in case the window is eventually restored/unzoomed.

Remember that some desktop enviorns, such as KDE, place windows optimally, so you don't have to.

Move to M16 for now ...

Move to M21 target milestone.

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

This is a very irritating bug (/missing feature). It is very confusing for new users that the new window has the *exact* same position as the current one since it looks like no new window has been opened but rather that the browser loaded a new url. Suggested pseudocode for position of new window: new.x = old.x + offset; new.y = old.y + offset; if(new.x + new.width > screen.width || new.y + new.height > screen.height) new.x = new.y = 0; this should apply independently of wether the new window has an explicily set size or not, and wether the window will be opened maximized or not (bug 20847)

Keep in mind that under some windowmanagers, such as KDE, window placement is handled automatically. On platforms that do not do this, however, that pseudocode sounds good.

nav triage team: we agree that this is the way it should work (the more important window handling bug is bug 29847 and bug 32148 which we are asking trudelle to reconsider and rtm+) but can't fix this bug so late in the schedule, so reluctant rtm-. M Future

I guess that should be bug 20847

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

Size of window with focus?? I presume that this summary is a bit wrong. If I have windows 1 and 2 open, 2 is large and has focus, 1 has some javascript that causes a window to open (no position or sizing code), it should NOT open based on window 2, but rather window 1. -- I'm sure we wouldn't actually implement the summary as is anyways... Law: Can you suggest where someone would go to find this code?

There are two places from which new windows can be spawned (more or less): 1. From chrome (e.g., the function OpenBrowserWindow in tasksOverlay.js). There are a fair number of these, but each is essentially the same. 2. From web content (JS "window.open"). These ultimately pass through GlobalWindowImpl::OpenInternal (in nsGlobalWindow.cpp). Of course, the various openDialog calls also come through here.

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

Related: bug 25455, need to offset position of new windows (cascading).

nav triage team: Ok, we'll try to fix this. Nsbeta1, p3

The fix should be only for creating windows of the same type as the window with focus. If I create a new message from a browser window its dimensions should be relative to the last message window i used, not to the browser window. pchen/nav triage: if you care about offset which is mentioned in this bug, but does not belong to it, please triage whichever bug that is as nsbeta1:p3 too. Offset should always happen reguardless of window types.

Shouldn't the Target Milestone at least be unset. Future contradicts the nav triage comments.

nav triage team: Setting target milestone to mozilla0.9

Isn't this fixed with bug 32148's latest fixes? Seems to work as expected for Browser, Message Compose and Composer for me with 122805 Mozilla build on NT.

Yeah, 32148 is expanding to fill all available space and is currently trying to address this issue, too. Didn't know about this bug at the time.

New windows will now in general be opened in the size, position and zoom state of the most recently focused window of that same type (previously, it was based on the most recently changed window of that type), thanks to bug 32148, which I predict will expand to take over the world by January 2002. This is (still) controlled by the "persist" attribute on the XUL window element. This bug isn't completely fixed, though, because my patch for 32148 didn't address the cascading offset problem.

Actually, I'd really rather that new windows did NOT inherit all the size preferences of previously-opened windows. I sometimes have to resize a window to read the content in a particular web page that has poor layout, but that doesn't mean I want all future windows to occupy as much display real estate. So maybe this is a feature request and not a bug, but I'd appreciate a pref which disabled inheriting future window geometry changes.

Noah: you're seriously in the minority there. Personally, when I want to do what you're describing, I zoom the window for the duration, so it and Mozilla's state persistence can be easily restored when I'm done reading the badly formatted website. We seem to both be minorities for not leaving it always maximized. If you're not as well served by the zoom widgets as I, you might want to write up a separate Request For Enhancement bug.

Since I don't see any traction on this from Bill Law (or, at least, comments from him in a couple months), taking off the mozilla0.9 radar since he's busy with some bigger things. Marking nsbeta1-, resetting target milestone.

danm@netscape.com wrote on 01-15-2001: >This bug isn't completely fixed, though, because my patch for 32148 didn't >address the cascading offset problem. I believe that problem was fixed later in January, in bug 25455. Should this bug be marked as "fixed" now? friedman@mozilla.org wrote: >Actually, I'd really rather that new windows did NOT inherit all >the size preferences of previously-opened windows. I suggest that you vote for bug 67149, "window tiling: need pref to allow New Browser to appear above existing ones". It's currently marked wontfix, but you can still vote for it, and votes will make it more likely to be reopened.

Yes, this bug has really always been dependent on the magic danm was doing in the base window code. I'm resolving this one FIXED and hoping any remaining quibbles can be addressed via other bugs. It's working well enough for now, I think.