Closed Bug 220546 Opened 21 years ago Closed 10 years ago

Applications do not "run minimized" if they were maximized when they were last closed

Categories

(Core Graveyard :: GFX: Win32, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mozilla, Unassigned)

References

Details

Attachments

(2 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20030926 Firebird/0.7+ Build Identifier: Mozilla Thunderbird 0.2 (20030901) If Windows' "run minimized" option is selected (from any shortcut icon - Quick Launch, Programs Menu, Startup folder), Thunderbird still opens a full window, rather than only a taskbar button. Reproducible: Always Steps to Reproduce: 1. Right-click a Thunderbird shortcut icon and select Properties 2. Set the Run option to Minimized 3. Activate the shortcut icon Actual Results: Thunderbird opens as a full restored/maximized window Expected Results: Thunderbird should open minimized, i.e. only as a taskbar button This seems to apply also to Firebird 0.7+ (unconfirmed)
This is now confirmed as applying to: App Suite 2003-10-01 Firebird 2003-10-01 Thunderbird 2003-09-24 Sunbird 2003-08-02
This applies only when the window was previously maximised. I'm assuming the application maximises itself *after* Windows has told it to be minimised, overriding Windows' command.
Summary: Thunderbird does not "run minimized" → Suite/birds do not "run minimized" if last closed maximised
Still there in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7) Gecko/20040722 Firefox/0.9.1+
Assignee: mscott → win32
Component: Mail Window Front End → GFX: Win32
Product: Thunderbird → Browser
QA Contact: ian
Version: unspecified → Trunk
Summary: Suite/birds do not "run minimized" if last closed maximised → Applications do not "run minimized" if they were maximized when they were last closed
It could just be me, but I don't see us handling nCmdShow at all in WinMain().
> It could just be me, but I don't see us handling nCmdShow at all in WinMain. In fact I think we don't even use WinMain. A debug build anyway doesn't show WinMain in the stack trace. It goes straight to main from a console app startup entry point. I believe Windows itself enforces the initial window state on the first window shown, and I believe Greg is correct, when our own program state sees that the window should be maximized, it overrides the initial state either because SW_SHOWMAXIMIZED has the quality of overriding the default, or because ::SetWindowPos/ShowWindow is called twice and Windows intercedes only the first time. I forget which. It's one of those two reasons and it doesn't really matter which. This isn't that tough to fix. The only real trick is determining at the widget level that it's the first (visible) window and then looking for system hints. That would require an interface change, unless I miss my guess. And by the way > Still there in ... Gecko/20040722 Firefox/0.9.1+ That's because no one is working on it. We're taking patches, you know. I'm otherwise engaged. Haven't seen a patch in four years:
*** Bug 40853 has been marked as a duplicate of this bug. ***
Attached patch Basic patch (deleted) — Splinter Review
Attached patch Advanced patch (deleted) — Splinter Review
This patch makes it so that if you closed the browser maximized, and start it with a minimizing shortcut then it restores to maximized.
Comment on attachment 156343 [details] [diff] [review] Advanced patch Cool, I would have forgotten about the WPF_RESTORETOMAXIMIZED part. r=me if you'll count it.
Comment on attachment 156343 [details] [diff] [review] Advanced patch Mmmmmmmmmm I'm giving this one a provisional thumbs-down. It looks fine and seems to work quite well in Mozilla. But I have two concerns: 1) It's probably not quite right when launching Mozilla/Suite with prefs set to open two windows immediately (i.e. browser and mail). That's alright and this is still an improvement and I wouldn't turn down the patch for this reason. 2) However on a related note, I'm concerned what this will do in embedding apps. It seems to me that if an app were constructed so that the first window opened wasn't a Gecko window, this could cause an unexpected bug. For both cases I'd feel better if there were some interface on widget allowing the app to specifically request this behaviour for specific windows, rather than relying on a magic static state flag.
Attachment #156343 - Flags: review-
*** Bug 269920 has been marked as a duplicate of this bug. ***
*** Bug 345658 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > *** Bug 382751 has been marked as a duplicate of this bug. *** > On Firefox (XP Pro), when my shortcut is set to run |Minimized|, it never opens minimized, it always opens |Normal|. I don't know how these patches are used. Do they work? How are they installed?
In the latest releases, the behavior is worse - there is now no way to start the application minimized at all, so the "if they were maximized" part of the title doesn't apply anymore. The functionality is useful for webapps you want to run in the background.
Product: Core → Core Graveyard
Perhaps it's obvious, but I tested 1.9.0, 1.9.1b3pre, 1.9.2a1pre and none have the ability to start minimized under any set of conditions. In case anyone was interested in the parity question, I tested these other browsers, IE7 - works GChrome - works Safari - works Opera - doesn't work RIP bug 220546
This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX. [Mass-change filter: graveyard-wontfix-2014-09-24]
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: