879159 - File menu "Close" (or Ctrl-W) behaves exactly like "Exit" (or Ctrl-Q)

Status: RESOLVED INVALID

(SeaMonkey :: General, defect)

Description

[Michael Patton]

User Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20100101 Firefox/14.0.1 (Beta/Release)
Build ID: 20120713134347

Steps to reproduce:

Whether SeaMonkey preference is set to open in Browser or Composer:
If File -> Close OR Ctrl-W is used THEN:


Actual results:

The entire program is killed, not just the currently open window that a person is working in. File -> Close or Ctrl-W effectively behave exactly as File -> Exit or Ctrl-Q


Expected results:

The current work should close (prompting to save changes if necessary) and the program itself should not. One should then be able to "File -> Open File" or "Ctrl-O" to choose other work without having to re-start the program.

Comment 1

[therube]

What version of SeaMonkey are you running?

As a test, create a new, clean Profile.
Does the problem persist in that new Profile?

Comment 2

[rsx11m]

therube: I think Michael is talking about closing the /last/ window causing the application to exit completely, in which case SeaMonkey would behave as intended. In contrast, other applications (looks at Acrobat Reader) just clear the window on closing, even if it's the last window, and the program itself keeps running.

The problem may be that SeaMonkey as such doesn't have an "empty document window" like those other applications, a window always has /some/ function. Additionally, closing the last window but leaving the program running doesn't provide any means to open a new window (at least on Windows and Linux), given that menu bars are tied to the windows, thus would disappear along with it.

Maybe you can be more specific what you have in mind?

Comment 3

[Michael Patton]

(In reply to therube from comment #1)
> What version of SeaMonkey are you running?
> 
> As a test, create a new, clean Profile.
> Does the problem persist in that new Profile?

therube,

1) SeaMonkey version 2.17.1

2) Not sure why a new profile might influence the issue but I created a new, clean profile for you and the behavior is the same in it as in the program "default" profile I was using. Perhaps you could explain why the profile could matter to this behavior?

Comment 4

[Michael Patton]

(In reply to rsx11m from comment #2)
> therube: I think Michael is talking about closing the /last/ window causing
> the application to exit completely, in which case SeaMonkey would behave as
> intended. In contrast, other applications (looks at Acrobat Reader) just
> clear the window on closing, even if it's the last window, and the program
> itself keeps running.
> 
> The problem may be that SeaMonkey as such doesn't have an "empty document
> window" like those other applications, a window always has /some/ function.
> Additionally, closing the last window but leaving the program running
> doesn't provide any means to open a new window (at least on Windows and
> Linux), given that menu bars are tied to the windows, thus would disappear
> along with it.
> 
> Maybe you can be more specific what you have in mind?

rsx11m,

It does happen to be the act of closing the "last" window that kills the program. To be more specific, what I have mind should certainly apply to (at least) Composer. Most every program that gets used for multiple documents (spreadsheets, word processors, WYSIWYG editors, even Acrobat Reader as you mention) are frequently used serially for their type of work, i.e. you open a spreadsheet, work on it, save it, close it, then open another for the same purposes. An example of a WYSIWYG usage might be like mine. I open a page for one website, edit it, save it (or publish it to the site) and then close the document to open another page for another site I'd like to work on. 

Killing the program on "closing" the last item makes serial use of the program at best inconvenient. This effectively makes the "Close" (Ctrl-W) option in the File menu superfluous to closing the last document and likely takes most users by surprise, if not annoying them (you can hear the cry "...All I did was close the document, NOT kill the program!! What's wrong!?...) It also gives the program a "watered down" feel that just "seems odd". 

I'm the first to admit that having to call for SeaMonkey over and over again is not that big a deal. It's just that in contrast to what has over the years come to be standard interface behavior for programs of this type, that SeaMonkey should behave so far outside that "De Facto standard" as to kill the program rather than leave it running to continue to use it to open the next document or create a new document. 

If, as you suggest, this "killing the program on closing the last document" is by design, then this "bug report" should be moved to "improvement suggestions". Sorry, but because of what I've explained here about generalized fundamental user interface expectations, it's abnormal enough to look like a bug to me.

Comment 5

[Phoenix]

(In reply to Michael Patton from comment #4)
> If, as you suggest, this "killing the program on closing the last document"
> is by design, then this "bug report" should be moved to "improvement
> suggestions". Sorry, but because of what I've explained here about
> generalized fundamental user interface expectations, it's abnormal enough to
> look like a bug to me.
Bug 456405 contain all needed details about this behavior, I don't think that SeaMonkey developers would change this if Firefox doesn't change

Comment 6

[Philip Chee]

Close Tab (CTRL-W) closes a tab or clears the last tab but doesn't close the window.
CTRL-SHIFT-W is Close Window which closes the current window. If it is the last window SeaMonkey exits (except if you are on Mac OS X).

As far as I can tell there is no File -> Close, ony File -> Close Window

Comment 7

[Michael Patton]

(In reply to Philip Chee from comment #6)
> Close Tab (CTRL-W) closes a tab or clears the last tab but doesn't close the
> window.
> CTRL-SHIFT-W is Close Window which closes the current window. If it is the
> last window SeaMonkey exits (except if you are on Mac OS X).
> 
> As far as I can tell there is no File -> Close, ony File -> Close Window

Philip,

I don't know what version you're running but in 2.17.1 under the File menu at the top of the program it says "Close or Ctrl+W". If you close the "last" window (which is frequently the only window open when using Composer) it kills the entire program by design. Doesn't sound like anyone is too interested in making the program behave like most every other program of its type on the planet so its a moot point. It's still a decent bare bones WYSIWYG so just treat it like the single use executable that it is and call for it every time you want to create or edit a document.

Comment 8

[Philip Chee]

Oh sorry I didn't notice that you were talking about the HTML Composer.

Comment 9

[Tony Mechelynck [:tonymec]]

In the browser, Ctrl+W is equivalent (on the version I use) with "File → Close Tab". There exists a preference, browser.tabs.closeWindowWithLastTab (default: true) which can be toggled in about:config but AFAIK it has no UI in "Edit → Preferences".

In the mailer, Ctrl+W is just "File → Close" and closes the current window.

I don't know about Composer.

As said in earlier comments, it is "intended behaviour" that (except maybe on the Mac) closing the last window closes the whole of SeaMonkey. OTOH, as long as you leave at least one window open, even a mere ChatZilla window, SeaMonkey won't shut down (and windows of other types can be opened by clicking the small icons at the left end of the statusbar).

IOW, Ctrl+W is not the same as Ctrl+Q… unless you have only one window left open, in which case them doing the same thing is intended behaviour, IOW, "not a bug".

Comment 10

[Michael Patton]

Tony, 

Thanks for the suggestions on a workaround to keep it alive. I have been doing exactly that and am trying to force myself to remember to leave a stub open every time I use it. It's not yet a habit. :-)  I'm aware that it closes by design when the last window is closed and that it's not a bug. I had suggested earlier that it be moved to "improvement suggestions" and out of this "bug report" vehicle as soon as it was pointed out in an earlier post that it was by design. I'm not sure how to formally request this, so maybe you have some suggestion on who to contact?

Comment 11

[Tony Mechelynck [:tonymec]]

(In reply to Michael Patton from comment #10)
> Tony, 
> 
> Thanks for the suggestions on a workaround to keep it alive. I have been
> doing exactly that and am trying to force myself to remember to leave a stub
> open every time I use it. It's not yet a habit. :-)  I'm aware that it
> closes by design when the last window is closed and that it's not a bug. I
> had suggested earlier that it be moved to "improvement suggestions" and out
> of this "bug report" vehicle as soon as it was pointed out in an earlier
> post that it was by design. I'm not sure how to formally request this, so
> maybe you have some suggestion on who to contact?

An "improvement suggestion" is just a bug report of "enhancement" severity; but if you report one to reverse this "intended behaviour" I think there's little chance of getting it FIXED (WONTFIX or INVALID sounds more likely to me). Even making it dependent on a new preference (let's say, something like general.closeAppWithLastWindow, type Boolean, default true) seems to me barely possible but unlikely.

Neil, what do you think?

Comment 12

[[e-mail]]

(In reply to Michael Patton)
> The current work should close (prompting to save changes if necessary) and
> the program itself should not. One should then be able to "File -> Open
> File" or "Ctrl-O" to choose other work without having to re-start the
> program.

Given that you've just closed the last window, where would this file menu live?

Windows does have an MDI document model where each top-level window contains zero or more document windows, however SeaMonkey currently assumes a multiple SDI document model so to support this would need a substantial amount of programming to allow all the current windows to open as separate "tabs" in a master window. Not only do the browser, composer, 3pane and message windows all believe themselves to be master windows (indeed mail tabs aren't as real as browser tabs because they have to work around these existing assumptions) there would need to be some way of multiplexing the global menu, and some consideration may have to be given to sharing code between multiple tabs of the same type.

Although it works against the Windows UI guidelines, another popular approach is the minimise to tray model, for which I believe extensions already exist.