40853 - Windows shortcut setting (nCmdShow) ignored, causing "run maximized" checkbox to have no effect

Status: RESOLVED DUPLICATE of bug 220546

(Core :: XUL, defect, P3)

Description

[john russell]

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

Comment 1

[John Dobbins]

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

Comment 2

[Asa Dotzler [:asa]]

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

Comment 3

[Peter Trudelle]

assigning to danm, nominating for nsbeta3

Comment 4

[Peter Trudelle]

nsbeta3-

Comment 5

[Barry A. Wilson]

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

Comment 6

[noog]

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

Comment 7

[Dan M]

  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.

Comment 8

[Blake Ross]

hyp-x, wanna take a look?

Comment 9

[Péter Bajusz]

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.

Comment 10

[Dan M]

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.

Comment 11

[Dan M]

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

Comment 12

[timeless]

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.

Comment 13

[Dan M]

  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.

Comment 14

[timeless]

(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]

Comment 15

[Dan M]

  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.

Comment 16

[timeless]

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]

Comment 17

[Jesse Ruderman]

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

Comment 18

[R.K.Aa.]

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

Comment 19

[Dan M]

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 ***