17149 - New windows should inherit size of window w/ focus

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[vectro]

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.

Comment 1

[shuang (gone)]

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

Comment 2

[german]

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

Comment 3

[neil]

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.

Comment 4

[Chris McAfee]

Agreed, we should do this.

Comment 5

[don]

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

Bill, is this hard?

Comment 6

[Bill Law]

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.

Comment 7

[don]

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

Comment 8

[Dan M]

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

Comment 9

[Matthew T (active 1999-2002)]

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.

Comment 10

[Matthew T (active 1999-2002)]

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.

Comment 11

[vectro]

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

Comment 12

[don]

Move to M16 for now ...

Comment 13

[don]

Move to M21 target milestone.

Comment 14

[Asa Dotzler [:asa]]

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

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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)

Comment 16

[vectro]

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.

Comment 17

[johng]

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

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I guess that should be bug 20847

Comment 19

[Matthias Versen [:Matti]]

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

Comment 20

[timeless]

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?

Comment 21

[Bill Law]

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.

Comment 22

[Matthias Versen [:Matti]]

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

Comment 23

[Jesse Ruderman]

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

Comment 24

[Paul Chen]

nav triage team:

Ok, we'll try to fix this. Nsbeta1, p3

Comment 25

[timeless]

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.

Comment 26

[Asa Dotzler [:asa]]

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

Comment 27

[Paul Chen]

nav triage team:

Setting target milestone to mozilla0.9

Comment 28

[Asa Dotzler [:asa]]

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. 

Comment 29

[Dan M]

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.

Comment 30

[Dan M]

  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.

Comment 31

[Noah Friedman]

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.

Comment 32

[Dan M]

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.

Comment 33

[Paul Chen]

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.

Comment 34

[Jesse Ruderman]

[e-mail] 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?

[e-mail] 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.

Comment 35

[Bill Law]

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.