Issue 117585 - closing a document programmatically results in event order different from when closing it by UI
Summary: closing a document programmatically results in event order different from whe...
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: DEV300m104
Hardware: PC Windows NT
: P3 Normal (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2011-03-28 19:06 UTC by Frank Schönheit
Modified: 2017-05-20 10:48 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Frank Schönheit 2011-03-28 19:06:41 UTC
Recently, the implementation of the TDOC UCP has been modified to remove a document which it keeps track of when the XCloseListener::notifyClosing event arrives. Before that change, the removal was done when the OnUnload event was notified via the XDocumentEventBroadcaster.

The change was necessary since there are other listeners which react on the OnUnload event, and rely on the document still being tracked on the TDOC UCP - which is not guarateed if the TDOC UCP removes the document upon OnUnload.

So, the assumption here was that the notifyClosing event always arrives after the OnUnload event, so the removal can happen in notifyClosing.

This assumed order of events is true when you close the document via user interface.

However, it is *not* true when you close the document programmatically - in this case, notifyClosing fires *before* OnUnload.

fs->mab: Talked about this with MBA, and we agreed that all means to close a document should fire the events in the same order - which in this case would probably mean some refactoring of the SFX code. I don't remember the exact details of the Great Plan MBA and /me created for this, but I offer my help to re-create it :)

To illustrate the problem, use the complex.sfx2.DocumentEvents test case, to be found in the sfx2/qa folder. Uncomment the "@Test" in front of the testCloseByAPI method, and run the test - it will fail now in exactly this method, complaining about a wrong event order.

Note(1): The test is committed to CWS fs34b at the time of this writing, and still needs to manifest in MWS.

Note(2): There's actually two test methods which are currently not ran: testCloseByAPI, and testCloseDocEvents. The former does an XCloseable::close on the document, the latter dispatches an ".uno:CloseDoc" URL to the document's view. Interestingly, the latter fails, too, while dispatching a ".uno:CloseWin" (see testCloseWinEvents) succeeds, i.e. fires the proper events.

Note(3): when this bug here is fixed, pleas re-enable the assertion at At the moment, this assertion is disabled, since it is triggered during the smoketest (which closes documents programmatically), and thus (since CWS debuglevels) breaks the smoketest.
Comment 1 Oliver Brinzing 2011-03-29 10:55:04 UTC
Comment 2 Oliver-Rainer Wittmann 2012-06-13 12:17:07 UTC
getting rid of value "enhancement" for field "severity".
For enhancement the field "issue type" shall be used.
Comment 3 Marcus 2017-05-20 10:48:00 UTC
Reset assigne to the default "".