Closed Bug 17149 Opened 21 years ago Closed 20 years ago

New windows should inherit size of window w/ focus

Categories

(SeaMonkey :: UI Design, defect, P3)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: vectro, Assigned: law)

References

Details

(Whiteboard: [rtm-])

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.
Assignee: shuang → german
I can't remember whether we defined this already, re-assign it to german to
check it out in the spec.
Assignee: german → don
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.
Component: UE/UI → XPApps
Summary: New windows revert to default size → [FEATURE] New windows should inherit size of window w/ focus
Agreed, we should do this.
Assignee: don → law
Severity: trivial → minor
Priority: P3 → P2
Target Milestone: M14
Hmmm, I think we need this for beta 1 'cause it's driving me crazy without this
behavior.

Bill, is this hard?
Status: NEW → ASSIGNED
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.
Target Milestone: M14 → M15
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 ...
Target Milestone: M15 → M16
Summary: [FEATURE] New windows should inherit size of window w/ focus → New windows should inherit size of window w/ focus
Target Milestone: M16 → M18
Move to M21 target milestone.
Target Milestone: M18 → M21
*** 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)
Keywords: rtm
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

Whiteboard: [rtm-]
Target Milestone: M21 → Future
*** 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?
Keywords: mozilla0.9
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
Keywords: nsbeta1
Priority: P2 → 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
Target Milestone: Future → 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.
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla0.9 → ---
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.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
QA Contact: claudius → jrgm
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.