This is toggled by the SFX. However, I think, this should be discussed with UX
first.

The feature works as designed. 

I wouldn't recommend to change it and of course not with this target.

So if you want to insist on your request please change the target and send it to
mmp, because this touches the user experience.

The current behaviour seems non-standard and limits functionality. Re-opening.
BTW, why do engineers always close a task even when there is an open question?

IBIS and IZ offer me no mechanism to change the target milestone or the
assigned-to engineer.

I didn't close it, I just asked you to change the target, because we will not
implement any new feature in OOo2.0.

OK, so I will do it. Besides that your request needs a change in the
specification, so I asked you to send it to the spec owner. Seems that you
overlooked it, so I do it also.

Matthias, here's a feature request for our startup module.

IMHO we have no time left for features in OOo2.0 and BTW I don't support the
request anyway, but of course I consider you to be the expert for this and let
the decision up to you. Maybe you already have some plans for the startup module
in OOo>2.0 and can discuss the request in this context.

The backing window (aka Start module) has no use in itself. It is a patch for 
accidential exit of the application and slow startup performance. A "content
close control" on each window, in addition to the window close control would
make the window a object of the user's domain and add complexity to her mental
model.

- spec link added
- bug set to invalid

- closed

- chanched spec URL

(the issue was marked CLOSED INVALID)

Re-opening issue (until the discussion has finished).

1. The window is already an object that the user is aware of (minimise,
maximise, resize, behaviour of secondary windows associated with main window, etc.).

2. When the user selects File/New/<document>, the window will be "reused" if the
user then uses that window to open a document. 

So the user is aware of the window as a primary object and is able to use it to
open an existing document.

Now, here is an example of the kind of use case I want to support:

User wants to work through a set of documents and extract some information to
summarise in a single document. The single document is positioned in the top
half of the screen, a second document window is put in the lower half. The user
uses the window in the lower half to open each document in turn.

This is very tedious with the current window-management approach, but it would
be trivial if every window had a 'close document' button.

ad 1) With "primary objects" I mean objects that have value for the user.
Documents have. WIndows have not. The latter are just supporting the way the
user gets access to her data. 

ad 2) Reusing an Untitled/Unsaved/Empty document window is fine, because the
user has no interest in this document.  In most cases she does not even notice
that OOo/SO reuses these kinds of windows.

ad 3) [oops there was no 3] Please do not mix up problem and solution. Your
scenario gives me some insights what you have in mind.  Thanks for that. 
During our engineering innovation week we also talked about tabbed windows for
OOo/SO. They might be a better suited solution for your scenario. 

- assigned issue to Colm  to decide when we are done with this dicussion.

Windows have value because the user must manipulate them to see the document.
The user must position them to see the right content of one or more documents.
See my earlier comment for the kind of use case I want to support. Your tabbed
windows proposal does not solve this because a tab only shows one document, but
two tiled windows show two documents simultaneously.

I restate, information of and about documents is the only  information that
matters to the user of OOo. Everything else are supporting objects and concepts. 

And here is how my proposal solves your scenario. Open target docT in window 1.
Open all source documents docS1, docS2, ... in window 2; window 2 is a tabbed
window. Grap data from the target documents one after another and close  it once
you are done. Window 2 will present all docSn documents until you are done. 
Voila - no artificial empty window involved. 

Even without a tabbed window the scenario already works today. Whenever you
close the lower window its current position and size is stored and will be
reused when you open the next document of that kind. The only difference to the
scenario you described is that you have to press the FileOpen button in the
upper window instead of in the lower one. But all source documents will appear
at the same location on screen and the task can easily be achieved. The target
document window would never be covered.

However, I could understand that all windows should have the same decoration.
The user might not notice that only the last open window gets an additional
closer or, to put it differently, why the closer somtimes just disappears (In
fact when he opens additional documents).
What about putting a small closer to every window, but only the last would keep
the office process running ? In all secondary windows this closer would close
the whole frame exactly as the big window closer would. In other words: the
small closer would just be a shortcut to File->Close. (Which already behaves as
described)

The 'stored' window location workaround assumes that the user is opening
documents of the same kind. The solution I propose works for any document type.

It is essential that the 'x' closer button only closes the content and not the
window; the point is to keep the window open in the same place so that it can be
reused.

OpenOffice.org Issue Tracker - Feedback Request.

The Issue you raised is currently 'Unconfirmed' pending review, but has not been
updated within the last 3 years. Please consider re-testing with one of the
latest versions of OOo, as the problem(s) may have already been addressed.
Either use the recent stable version: http://download.openoffice.org/index.html
or consider trying the new OOo 3 BETA (still in testing):
http://download.openoffice.org/3.0beta/
 
Please report back the outcome so this Issue may be Closed or Progressed as
necessary - otherwise it may be Resolved as Invalid in the future. You may also
wish to search for (and note) any duplicates of this Issue that may have
advanced further by checking the Issue Tracker:
http://www.openoffice.org/issues/query.cgi
 
Many thanks,
Andrew
 
Cleaning-up and Closing old Issues as part of:
~ The Grand Bug Squash, pre v3 ~
http://marketing.openoffice.org/3.0/announcementbeta.html

Shaun 1/30/13. I wasn't able to replicate this bug, perhaps more information would help.