although i have changed the shortcut property to open mozilla in a maximized window it does NOT! build 2000052708

Tested with Build # 2000060208 on Windows 98 SE Bug is reproducable everytime

this bug is not part of component "other" other is reserved for tracking bugs. updating component and owner

assigning to danm, nominating for nsbeta3

nsbeta3-

I can reproduce this with build 2000091317. I tested with screen resolution of 1024x768 and 800x600. This was done on Win98 FE.

Build 2000101014 affected too I guess the maximize message is sent to the splash screen window instead of the main window

Presumably a Windows shortcut would give us a STARTUPINFO structure, which is supposed to make the correct choice of window state automatic. This wants a little investigation to find out whether that's true, and then a little bit of windows-specific code to not set the state of the first window opened. I'd take a patch. In the meantime, now that bug 32148 is (largely) fixed, this is less of a problem because at least the app itself remembers window state.

hyp-x, wanna take a look?

Hmm. The way the first window should be shown is passed as the last parameter of WinMain. Looking at http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsAppRunner.cpp#1304 it seems that mozilla doesn't use that parameter. If it was my program, I'd set a global variable in WinMain and use it on window creation, where I'd also reset it to some "don't ever use me again" value. The problem is that I'm not too familiar with mozilla to decide where such code should be put.

The splash screen, being the first window opened, is probably clearing the STARTUPINFO window flags. I'd look at adding something to the Windows version of the nsNativeAppSupport object to pass nCmdShow from WinMain on to the first window opened. The first window is opened right there in the same file as contains WinMain, in Ensure1Window(). There is a problem of how best to pass that info to the window opening code without disrupting the XP APIs. Disregarding that, this should be pretty straightforward. But personally I'm not planning on getting to this any time soon. That "helpwanted" thing still applies.

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

I might look into this; bug 64620 lists the constants that we'll need to address. But first, assuming the command is: |start "Mozilla Wacko" /max mozilla -console -mail -browser| what do we want to have happen ;-? start "Mozilla Wacko" /max cmd.exe ^works as expected start "Mozilla Wacko" /max notepad ^ignores title. more normative examples: |start /max mozilla -mail| |start /max mozilla -console| |start /max mozilla| <- no special settings in prefs |start /max mozilla -nohome| <- not implemented, but hopefully it will be. |start /max mozilla| <- prefs:open browser and mail minimize: |start /min mozilla -mail| ... |start /min mozilla| <-- assume that prefs say one mail, one navigator, and that both were maximized on last use. Ah the wonderful variations. If anyone can think of others about which they care i'm interested in hearing. I suspect that we will ignore nCmdShow for any case that results in multiple open components. [that's relatively rational] -console is an interesting case, however I think most likely we'll ignore the console window and send maximize to the one other window. If we can get the title param, should we title the console using it? I think titling the console could be really neat and even useful. Rambling, maybe -console should include mozilla version by default.

Good points. My take: Premises: (1) We have our own, internal window state memory. (2) I can imagine that people fond of maximized windows could actually make use of a stack of simultaneously open maximized windows, moving among them using the taskbar or by toggling minimization. (3) Our state memory ignores minimization. (4) Why would you open an application minimized, unless you wanted it open without it taking up any space your desktop? Suggestions: (a) Because of (1), apply the shortcut window state only to windows mentioned in the command line. That is, allow windows opened using preference settings to use their cached state. That seems internally consistent. (b) Because of (2) (3) and (4), apply the window settings to all windows mentioned in the command line, no matter what they are. The user asked for it, after all, and this is a somewhat power user feature. I think you don't have to worry about the value of nCmdShow. Just pass it along, whatever it is. Well, except SW_HIDE. That one seems dangerous. I promise I came to my conclusions without thinking of the code impact. But I think that implementing it as I suggest would be not much harder than the simplest case. I'm pretty sure the code changes will still be relatively well contained.

(3) is bad and a bug. Fixing (3) leads users to step one of mozilla preload. fwiw, we don't get the start commandline, all we'd get is the nCmdShow flag set appropriately as a function of start [which just happens to be the easiest way for someone to describe/force a window pos w/o a shortcut] SW_HIDE is also along the lines of preload. if we had support for -nohome and were able to not kill areselves if -nohome is called [and we don't end up w/ windows], then someone could execute mozilla -nohome w/ some message to SW_HIDE and then later run mozilla w/ a document. [this is dependent on a lot of other bugs, for now I will gladly ignore SW_HIDE]

We're stuck with (3), you know. It'd be easy to fix, but there are vehement forces arrayed against it. And we do process the command line; mozilla -mail overrides your startup window preferences, after all. However, an evening's thought makes me reconsider. I didn't consider the most likely case; the one where no specific window is specified in the command line. Then it falls back on the preferences. Now to follow my above suggestions there have to be exceptions, and that's too complicated. I say just open all initial windows, whether specified in the command line or through preferences (already coded) to the state (if any) specified in the command line or shortcut (not coded). That's easiest to predict; least likely to surprise. A bit more programming effort. I'm always concerned about invisible windows: they can be a security bug. I don't know whether it's possible to make a shortcut specify a hidden window, and even if so whether that's really a security issue, since it's all local. So I'm not much worried about SW_HIDE, but it could potentially be a problem.

shortcuts can't, rundll might be able to. The most likely case is where someone is borrowing mozilla.exe instead of embedding it (eg for their help system), so they want it to preload, and then ask it to open a help file. However i won't cry if we don't support sw_hide, minimized should work well enough [although -nohome might benefit from some implementation of sw_hide]

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

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

Closing this as a duplicate of a much newer bug, because the layout of the land has changed in the four years since this bug was opened and it isn't entirely correct any longer. This bug is actually fixed unless the state saved from the last window on the last invocation of the app dictated that the first window of the next invocation should be maximized. This is probably simply because of the loss of the splash screen. *** This bug has been marked as a duplicate of 220546 ***