Closed
Bug 17149
Opened 25 years ago
Closed 23 years ago
New windows should inherit size of window w/ focus
Categories
(SeaMonkey :: UI Design, defect, P3)
SeaMonkey
UI Design
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.
Updated•25 years ago
|
Assignee: shuang → german
Comment 1•25 years ago
|
||
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.
Updated•25 years ago
|
Component: UE/UI → XPApps
Summary: New windows revert to default size → [FEATURE] New windows should inherit size of window w/ focus
Comment 4•25 years ago
|
||
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?
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 9•25 years ago
|
||
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•24 years ago
|
||
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.
Reporter | ||
Comment 11•24 years ago
|
||
Remember that some desktop enviorns, such as KDE, place windows optimally, so you don't have to.
Updated•24 years ago
|
Summary: [FEATURE] New windows should inherit size of window w/ focus → New windows should inherit size of window w/ focus
Target Milestone: M16 → M18
Comment 14•24 years ago
|
||
*** 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
Reporter | ||
Comment 16•24 years ago
|
||
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•24 years ago
|
||
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
I guess that should be bug 20847
Comment 19•24 years ago
|
||
*** Bug 59305 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
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
Assignee | ||
Comment 21•24 years ago
|
||
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•24 years ago
|
||
*** Bug 59471 has been marked as a duplicate of this bug. ***
Comment 23•24 years ago
|
||
Related: bug 25455, need to offset position of new windows (cascading).
Comment 24•24 years ago
|
||
nav triage team: Ok, we'll try to fix this. Nsbeta1, p3
Keywords: nsbeta1
Priority: P2 → P3
Comment 25•24 years ago
|
||
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•24 years ago
|
||
Shouldn't the Target Milestone at least be unset. Future contradicts the nav triage comments.
Comment 27•24 years ago
|
||
nav triage team: Setting target milestone to mozilla0.9
Target Milestone: Future → mozilla0.9
Comment 28•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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.
Assignee | ||
Comment 35•23 years ago
|
||
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: 23 years ago
Resolution: --- → FIXED
Updated•23 years ago
|
QA Contact: claudius → jrgm
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•