Closed Bug 20847 Opened 26 years ago Closed 24 years ago

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

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.8

People

(Reporter: hyatt, Assigned: danm.moz)

References

(
URL
)

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: relnote3 → relnote
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, rtm → ui
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.
URL: data:text/html,<A HREF="http://mozill...
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 ago → 24 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.