Closed Bug 20847 Opened 25 years ago Closed 23 years ago

Windows need to persist maximized state and not use (x,y,width,height) when maximized

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla0.8

People

(Reporter: hyatt, Assigned: danm.moz)

References

()

Details

(Keywords: helpwanted, regression, relnote, Whiteboard: relnote-user)

If you maximize the nav window and then close it, you end up with a
non-maximized window when you next start up.

Also, make sure the persistence JS code lives in the global UI package so that
all windows can get to it.  If you could run over the components and police them
to make sure people aren't wrongly referencing your code using
"chrome://navigator" and/or haven't just copied it over to their component
instead of sharing, that would also really help me out.

Thanks!
Status: NEW → ASSIGNED
Target Milestone: M13
*** Bug 17982 has been marked as a duplicate of this bug. ***
Priority: P3 → P2
Target Milestone: M13 → M15
Not required for beta 1.
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
*** Bug 25466 has been marked as a duplicate of this bug. ***
*** Bug 26258 has been marked as a duplicate of this bug. ***
Also, if you maximize a browser window and then press ctrl-n, the new window 
appears to be maximized but isn't, making it difficult to resize the new window.

Mozilla should remember: 
1. If it's maximized
2. Location when not maximized
(both between sessions and when the user uses ctrl-n)
*** Bug 29986 has been marked as a duplicate of this bug. ***
Bug 30529, "Implement minimize/maximize/restore" looks suspiciously similar,
if very terse...but then it could always be another issue entirely.
Move to M16 for now ...
Target Milestone: M15 → M16
spam, open xptoolkit qa contact moving over to jrgm
QA Contact: paulmac → jrgm
Target Milestone: M16 → M18
Ok, there's really three issues here.

* After startup, the first {component-name} window should inherit the
  maximized/non-maximized state of the last open {component-name} window in the
  previous Mozilla session. Fine.

* When you open a new {component-name} window (using the relevant keyboard
  shortcut, or Tasks menu item, or whatever), the new window should inherit the
  maximized/non-maximized state of the last active browser window. That's ok,
  too.

* When a link opens in a new window (through TARGET="_new" or whatever), if the
  original window was maximized the new one should be too. Sounds sensible, but I
  think this one would actually be a bad idea -- because novice and intermediate
  users would often not even realize that a new window had opened. So I think
  that all windows which open as a result of a Web page itself should always open
  in a non-maximized state.
> So I think that all windows which open as a result of a Web
> page itself should always open in a non-maximized state.

Oh yuck. This should be an OPTION - choose the behaviour. Right now, Nav 4.7x
does NOT behave this way, and I'd like it to remain the way it is! I can see
your point, certainly, but that means it should be an option, not a completely
new behaviour. People are going to expect some things to behave the same way,
and quite frankly, I don't want to use a browser that's designed for the novice.
If I wanted my computer to behave like that, I'd use a Mac. :)

Move to M21 target milestone.
Target Milestone: M18 → M21
*** Bug 42919 has been marked as a duplicate of this bug. ***
*** Bug 43362 has been marked as a duplicate of this bug. ***
adding mostfreq keyword
Keywords: mostfreq
Can it be made earlier that M21? It's mostfreq...
I agree, this is something that could be hindering adoption of Mozilla for 
full-time browsing.
(sorry for the spam) As a "power surfer," I open tons of new windows to make 
sure I visit all interesting links on a page. Having to click Maximize on every 
new window (especially when the Maximize button is often off th escreen) is a 
real pain.

Could this bug please be fixed earlier than M21? Look at how many people are 
disconcerted with this behavior. This shouldn't be too difficult to fix--maybe 
if you posted a few pointers on where a person should look to fix this, an 
outside developer could take care of this?
Nominating for nsbeta3.
Keywords: nsbeta3
Oh, I think this is a VERY important bug. It gives bad impression with the first 
 open-> new window! It should be fixed for Mozilla beta1 (at least).
This is one of my most annoying bugs in mozilla and the one that keeps me from 
using it very often.  Please get this scheduled as soon as possible! Thanks!
*** Bug 45015 has been marked as a duplicate of this bug. ***
I'm tired to maximize each new window... Very tired...
It's prevent many people to do "each day surf" with Mozilla.

I think we must nominating it for nsbeta2 and make it M17. 
Agreed. This has 14 votes. I know you guys are busy, but it should be M17.
Putting on [nsbeta2-] radar.  But this bug could be fixed by the net community 
and checked in via approval from brendan or waterson. 
Keywords: helpwanted
Whiteboard: [nsbeta2-]
*** Bug 46297 has been marked as a duplicate of this bug. ***
Nav triage team: [nsbeta3+]
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
I'm doing three things:

1. Removing [nsbeta3+] so that this bug can be re-examined.  I'm not sure that 
the symptoms described here are severe enough to warrant immediate attention.

2. Making this bug dependent on bug 32148, per discussion I had with Dan 
regarding how to fix this (he already had a bug that he thought covered this 
one, but we've decided to keep this one alive because of its nsbeta3 status).

3. Reassigning to danm.  He thinks he should fix it because it requires changes 
to nsGlobalWindow.cpp, which he owns (for all intents and purposes).

Dan and I discussed how to fix this.  It requires:

1. Recording that a window has been maximized (or minimized?).
2. Upon closing, persist the window state (=max/min/normal).  But in addition, 
*don't* record the window size/pos if it is maximized (i.e., don't lose the 
"restore size/pos", in Win32 terminology).
3. When restoring a window size/pos, check the persistent state and reset the 
window to match.

This last item is slightly hard, because there is no known method by which xp 
code can "maximize" a window.  Something would need to be added to nsIWidget to 
facilitate that (so it seems).
Assignee: law → danm
Status: ASSIGNED → NEW
Depends on: 32148
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta2-]
nsbeta3-, unable to commit to fixing this due to Daniel's current bug backlog.
May still pick it up, but in the meantime, perhaps someone can contribute a patch?
Priority: P2 → P4
Whiteboard: [nsbeta2-] → [nsbeta2-] [nsbeta3-]
Target Milestone: M21 → Future
This isn't really a patch, but it does fix the problem for me.  I also use it 
with Internet Explorer.  It's a tiny program called AutoSizer, available from 
this site:
http://www.firase.com/
You just have to select a Mozilla window to have it automatically maximize all 
Mozilla windows.  It's best to start the program before starting Mozilla, 
otherwise Mozilla get's a little screwy.  Hope this helps people until the bug 
gets fixed.  
*** Bug 48683 has been marked as a duplicate of this bug. ***
Does anyone have any idea whether this will be fixed for release?? I have been
OK in knowing that this is not essential for beta, but for release I feel that
this is the most irritating bug in all of Mozilla. I can verify that there is no
way my company will adopt a browser that doesn't maximize windows. Our intranet
spawns new windows with many links and having those windows appear the same size
but offset by even a few pixels (as seems to be the case now) would not impress
anyone as a viable browser.

If this isn't picked up it needs to be release noted, but I hope it doesn't come
to that. 21 votes and mostfreq

Please don't let this become a "New Feature" for Netscape 6 or Mozilla .9/1.0
Nominating for RTM.  This is driving me nuts being a laptop user.
Keywords: rtm
one more thing. When a new window is opened it should not get the same x and y 
position as the current one but rather something like

new.x = old.x+30 < screen.width-old.width ? old.x+30 : screen.width-old.width;
new.y = old.y + 30;
if(new.y + new.height > screen.height)
  new.x = new.y = 0;

ofcource that 30 could be something else...
Jonas, that's bug 17149.
*** Bug 55167 has been marked as a duplicate of this bug. ***
This should seriously be looked at.
Its very annoying to have to maximise the mozilla window ever time I start it up.
You start it just up, but I browse in >4 windows + opening/closing it, so I must 
do it very often... At moments I'm about crying coz this bug and bug 49141, but 
still use mozilla - I want to test it for reporting bugs and get the best 
browser.

Can we mark it for RTM?
sure, rtm-/future. No time for this, fix is non-trivial, too late to land such
changes on branch.
Whiteboard: [nsbeta2-] [nsbeta3-] → [nsbeta2-] [nsbeta3-] [rtm-]
It's stupid... Have you seen a programm which cannot open a new _full sized 
window_? I've seen - Mozilla/NS6. :(

I would hold for it. 2-3 days does not change anything, but this bug will 
resolved + others bugs in this time. I'd better wait a week, but get a good 
product, than get it quicker with bugs...
This has 25 votes and mostfreq. Would it be OK to use the mozilla1.0 keyword?
Keywords: mozilla1.0
just adding me mdaskalo@tlogica.com to CC field.
damn has attached a patch to bug 32148 to fix this problem on Windows! <jumps up 
and down in excitement>

Please, _please_, check this in. There are innumerable dupes, 32 votes, and 
Mozilla is the only app anyone knows of that can't cope with maximised windows 
properly. 

Gerv
Keywords: patch
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm-] → [nsbeta2-] [nsbeta3-] [rtm need info]
Gervase, you are way out of line changing my triage for my team's bugs.  Do not
do it again. This bug is rtm-. 
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm need info] → [nsbeta2-] [nsbeta3-] [rtm-]
Peter, I believed that it was perfectly reasonable to request a re-evaluation 
based on a change of status. I've done that in at least one other bug (I can't 
remember if it was one of yours) without a problem. 

The fact remains that there's a < 1 page patch to fix a problem from which end 
users are suffering immensely. I have seen no other bug which has as many 
comments like "This is really annoying", and "This is driving me nuts." I am 
well aware of the stance on taking crashing fixes only (one which Brendan seems 
to be expressing views on in the newsgroups right now) but if the product is 
stable but unusable, that doesn't help anyone.

FWIW, I have not been using Mozilla as dogfood because of this bug, and if NS 6 
ships with it, I won't be using that either. "Netscape 6 unable to cope with 
maximised windows" is not something I would guess marketing want to see in RTM 
product reviews!

Gerv
I fail to see what is out of line about requesting a bug be reevaluated.
Perhaps the process wasn't exactly correct.  I think the correct process is to
remove the rtm- from the status whiteboard (a shared field).  I think Gerv added
the patch keyword and removed the rtm- and added need info.  Either way I don't
see this as a violation of the process.  It has been done more times than I can
count in the last few months and will probably continue to happen as long as we
have a keyword + status whiteboard nomination process.  Gerv did nothing
malicious and explained his intent in a comment.  
Changing the triage result to exactly the phrase used to approve work on N6 is
not requesting re-evaluation,it is effectively changing my triage team's
disapproval into approval to work on the bug for RTM, which is unacceptable.
This is especially bad when done without adding a comment requesting re-eval and
describing the change, and cc'ing me so that I would see the request. You have
requested such re-eval in many bugs over the last several months, so I don't
understand why you wouldn't call my attention to it this time. It is perfectly
acceptable to request such re-eval, but the way to do it is in a comment,
optionally deleting the previous triage results to get the bug back on our
'radar'.  Changing the results of the triage could cause us to waste time on
things that won't help N6, instead of things that will.  It can cost us money,
time and product quality. I can understand that you might not have fully
understood the convoluted process that we have to use right now, *nobody does*,
but I am asking that you try to understand my objections, and agree to try to
avoid mis-using the process, even accidentally.  Okay?  
BTW, I apologize for any implication that this was malicious, or even
intentional.  I feel strongly that it is the wrong thing to do, and allowed that
to improperly shade my response, but I don't intend to malign anyone personally
for making a simple mistake. Gervase is a Good Guy, and I value his input.
Peter - I apologise if I mistook the process for requesting a re-evaluation for 
a bug by the PDT. At no time did I intend to attempt to assign Netscape 
engineering resource (I wasn't really even aware that such a thing was possible 
using Bugzilla.) In mitigation, though, if you admit that no-one understands the 
process, I'm sure you can understand that a mistake is easy to make :-)

I also apologise for not noticing that you were not CCed on this bug when 
requesting re-evaluation. I assumed that the PDT did queries for certain types 
of bug, and you would pick it up that way.

I hope that we can all agree that everyone's actions and words have been 
good-faith attempts to further the interests of the NS 6 product, and leave the 
situation as it now is.

Gerv
Thanks Gervase.  Yes, this Process facilitates mistakes more than anything else;
even the PDT can't agree on it.  Two small notes:
1) There is no process for getting PDT to re-consider bugs that have been marked
[rtm-] by the engineering team. They say they have no intention of doing that,
although they have been known to make mistakes too.
2) I'm not on the PDT, although I get their mail and they occasionally hijack me
and force me to do their bidding.
I just wanted to chime in that this one is -EXTREMELY- irritating when
always-on-top windows wind up hiding bits of mozilla, especially when that bit
is the titlebar... which then hinders window positioning. Mozilla can be
maximized manually by right-clicking in the taskbar and selecting maximize, but
this experience and having to repeat it with every new mozilla window is
disconcerting nonetheless. After having to put up with the current behavior so
long a fix sooner than M21 would be very appreciated for sanity's sake.
This one drives me nuts as well, and has done so for a VERY long time.  Glad to 
have finally tracked down the bug for it.  Why hadn't I earlier?  Because it was 
such an in-your-face (yet trivial) bug that I couldn't IMAGINE anyone missing it 
and letting it make it to the final product.

I see I was wrong.

rtm- should not be a one-way street.  Customer feedback after a bug is labeled 
as such NEEDS to be taken into serious consideration.  Especially in this 
instance, where letting this one slide into NS6.0-final will leave the 
impression to consumers that Mozilla/Netscape programmers are incompetant and 
can't take care of little obvious details.   I know that's not the case, but 
there needs to be attention to details like this in order for the general 
acceptance of NS6 to be popular.  Just because it doesn't crash the browser 
doesn't mean it isn't important... it might be just as important for other 
reasons.  A crash could mean the programmers didn't take something into 
account... something like THIS might come off as saying (to a consumer) that the 
programmers are "blind" and "just don't care".  Which is worse?

There needs to be an attention to details.  The final product MUST give the 
impression of a polished piece of work.  The new theme has gone a long way to 
providing this, but that doesn't mean we can slack off on other things like this 
bug.
Keywords: relnote3relnote
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm-] → [nsbeta2-] [nsbeta3-] [rtm-] relnote-user
I just added vote No. 40 for this, very annoying bug. How many votes does it
take yet to get that re-evaluated for RTM?

As I've seen another comment from IT responsibles, I am COO of an ISP and I can
confirm, that we'll definitely would have to reconsider using NS6, with a
browser that makes backsteps in the general look and feel behaviour.

Same applies to the share URL bug 31343.
s'cuse the spam
Spam is very much disliked. Please go away. I'm busy failing a project or two, 
then i'll commit something to trunk.
This bug also affects the built-in NIM (when the IM setup wizard opens to the
AOL registration page, it doesn't open and present the entire page. This has
confused some beta users).

Also, the Netscape Netbusiness Messenger beta looks comparatively worse when
using NS6 as the default browser vs. NS4 or IE. Both of these apps open their
windows to the full screen by default.

Since the RTM bandwagon is pretty much left, it's probably time to work on
targeting the next release, and possibly changing the priority to 
vote 53!
I think I'll file a bug on bugzilla: "we should delete the vote-system -
developers don't care about!"
This was/is nsbeta2, nsbeta3, rtm and it'll make a real bad impression for
users, it would have been fixed for months if there had been developing-work
instead wasting time discussing this bug.
just seen: The status is still NEW!! Could anyone please confirm it? and make it
mozilla0.9 and not mozilla1.0
Niko, bugzilla.mozilla.org uses unconfirmed/new instead of new/confirmed.
Adding to the Mozilla 0.9 radar. It would be much better if we could do this
sooner rather then later.
Keywords: mozilla0.9
Strictly speaking, this bug is already fixed -- it remains open because it seems 
to be the focal point for people concerned about the problem. The work remaining 
to fix the problem in a noticeable way is covered by bug 32148. A patch to fix 
that bug was posted to it nearly a month ago, but its checkin was held up for ... 
nontechnical reasons. We'll get it punched through somehow by the end of the 
week.
Status: NEW → ASSIGNED
Seems I spoke prematurely when I laid down a deadline in the comment above. 
timeless is working on a patch acceptable to the unofficial committee overseeing 
bug 32148. We'll have this fixed once he finds a path through the oversight 
obstacles. No ETA.
*** Bug 60951 has been marked as a duplicate of this bug. ***
*** Bug 60794 has been marked as a duplicate of this bug. ***
*** Bug 60794 has been marked as a duplicate of this bug. ***
for tracking purposes... here is the comment from #60794:

The following is reported by Jacob Arnold at
http://www.macintouch.com/netscape6.html

The browser's window position isn't saved if you option-click the zoom box to
resize it. After dragging the window to a new size manually, it seems to save.
Keywords: nsmac2
clef@optushome.com.au wrote:

  I agree, this is something that could be hindering adoption of
  Mozilla for full-time browsing.

isaacg@adiis.net wrote:

  This is one of my most annoying bugs in mozilla and the
  one that keeps me from using it very often.  Please get this
  scheduled as soon as possible! Thanks!

Mike Young wrote:
  I feel that this is the most irritating bug in all of Mozilla

Echo! I feel the same way, please fix this as soon as possible!  I'm not using 
Netscape 6 right now because of it. Vote #62.

Marcos.
This is now the only bug that's keeping my curious fingers away from Mozilla. I 
really don't know what is taking so long. I can only wonder, such a great 
browser as Mozilla is, this kind of little things are the most important 
things for mr. User.
Depends on: 345, 3432, 4634, 6435
<shrug>

Gerv
No longer depends on: 345, 3432, 4634, 6435
Platform & OS -> All
OS: other → All
Hardware: PC → All
*** Bug 62190 has been marked as a duplicate of this bug. ***
*** Bug 62435 has been marked as a duplicate of this bug. ***
Target Milestone: Future → mozilla0.8
The severity on this bug should be raised.  This is basic stuff guys!
Severity: normal → minor
Keywords: nsbeta2, nsbeta3, patch, rtmui
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm-] relnote-user → relnote-user
From what I can see there is only one other bug that has more votes than this.  
So what happens?  20 minutes after I suggest the severity should be raised from 
normal it is instead lowered to minor.  Why bother voting at all?
It looks like the severity was lowered by someone other than the reporter or 
QA, who own that field and should be the only ones to change it (although I've 
bent that rule myself on bugs I own).  Current severity does fit the criteria 
though: "minor loss of function, or other problem where easy workaround is 
present".  I'll increase priority to P3 though, this really needs to work. 
DanM: is this still covered by bug 32148?
Priority: P4 → P3
  Well, as I keep explaining, this bug describes an internal state, and actually 
has been fixed for months. It's bug 32148 that people are really thinking about 
when they vote for this one. And that bug is pretty much fixed. (Hooked up only 
for the browser window, uses the window last adjusted rather than the one in 
front, and implemented only on Windows and the Mac (Pavlov tells me that it can't 
be made to work on Linux, so barring an epiphany or a patch, that's the way it'll 
be)). A few more tweaks to that other bug, and they both get closed.
  DanKirkd: it was probably just unfortunate timing that this bug's priority was 
lowered right after your posting. Why timeless did that, I don't know. He's kind 
of the step parent of these two bugs, though, and they're almost fixed, so no 
bigs.
If this persistence aspect of this bug is really being fixed in 31248, then what
is the point of this bug? Shouldn't it be a dupe?

The reason I'm asking is that I was playing with the settings of my NS6 shortcut
on my WinNT destkop. I set the Shortcut tab | Run property to "Maximized", and
it still opens in somewhat random non-mazimized x,y window geometry.

  It's not really so much a duplicate as dependent. And it's the other one that's 
dependent on this one. This one could be closed. But I've been leaving it open 
because this seems to be the one people find when they're searching for this 
problem in Bugzilla: it has always had more votes; three times as many even now.
  Benjamin, the specific problem you're describing won't be addressed by this 
bug, which deals with persistence, not reading the Windows shortcut settings. 
That's covered in bug 40853.
No longer depends on: 32148
Bug 32148 is fixed enough that people should be complaining only about sub-
problems; not the general thing. And of course this bug has actually been fixed 
for a while. Seems like time to call it. Further problems with state persistence 
should be mentioned in 32148.
Blocks: 32148
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
An enormous sigh of relief resounds throughout all of Mozillaland. Sounds of
rejoicing are heard from all corners of the Earth. "They have conquered the
beast!" the voices cry.
And the dimensions remain constant 'till the end of days.
		from The Book Of Mozilla, 7:24

Thanks to all of the engineers who helped fix this and its related bugs. Mozilla
has come a long, long way, and I finally feel comfortable in recommending this
browser to my company. Keep up the good work everyone -- I look forward to 1.0 !
Until bug 81787 gets fixed, we should reopen this, don't you think?
Gor.
In 2001090408 Win98, this bug is occurring again. When opening a link such as
the one displayed by

data:text/html,<A HREF="http://mozilla.org/" TARGET="_blank">Test</A>

Mozilla opens the new window in the restored window state, not the correct
maximized window state. This occurs with all link targets that open new windows.
This does not occur when selecting the context option "Open link in new window,"
or windows opened on startup.

Ironic, because this is the same problem that's happening in IE6.
Status: RESOLVED → REOPENED
Keywords: regression
Resolution: FIXED → ---
Let's use bug http://bugzilla.mozilla.org/show_bug.cgi?id=96475 for the 
recent, specific regression and let this antiquated bug rest in peace.
Status: REOPENED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
gerrychu@bigfoot.com filed a bug to reverse this change: bug 56514,
"Context-menu 'Open in new window' opens link in new window the same size as the
parent window".
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.