Issue 95654 - Can we survive .uno:CloseDoc while we have a modal dialog open
Summary: Can we survive .uno:CloseDoc while we have a modal dialog open
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: DEV300m34
Hardware: All All
: P3 Trivial (vote)
Target Milestone: AOO PleaseHelp
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2008-10-30 15:37 UTC by caolanm
Modified: 2013-07-30 02:17 UTC (History)
4 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

testtool script for use without base installed as an example (816 bytes, text/plain)
2008-10-30 15:38 UTC, caolanm
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description caolanm 2008-10-30 15:37:41 UTC
Can we survive .uno:CloseDoc while we have a modal dialog open ?

i.e. with the testtool and *without* OOo base installed the attached example
will open the qatesttool .odb example, which will get the modal File Select
dialog instead of base. In a bit testtool will give up and call .uno:CloseDoc on it.

I see that the .uno:CloseDoc event get processed, deletes all windows etc, but 
Dialog::Execute() remains executing 

    while ( !aDelData.IsDelete() && mbInExecute )

when we've finished deleting all windows and destroying everything then
Dialog::Execute gets a go and dies with accessing of mpDialogImpl->mnResult.
Even if we avoiding touching mpDialogImpl->mnResult when mpDialogImpl is NULL it
still returns to code which is now totally screwed as some other things it
depends on has gone away.
Comment 1 caolanm 2008-10-30 15:38:22 UTC
Created attachment 57576 [details]
testtool script for use without base installed as an example
Comment 2 philipp.lohmann 2008-10-30 16:18:39 UTC
Basically the answer is: no. Two reasons:

- dialogs are often created on the stack (e.g. error messages, warning boxes).
The document cannot simply delete them or get rid of them otherwise.
- closing the document while having a dialog child does something intrinsically
evil: it destroys windows in the wrong order. This has to be ALWAYS child first,
then parent. Also this has always been so.

You may say this is a shortcoming of vcl and you'd be right, but the amount of
restructuring this would require is quite some. Do fix this really we'd need to
make windows refcounted. Had only this idea appeared to the creators back in
windows 3.1 times, but alas, it is not so.

Another way could be to at least reparent any child to the being deleted
window's parent (or to the default window for that matter). The side effects
however might be staggering (e.g. focus handling comes to mind).

Since this involves a larger structural rework I'll call it an enhancement. And
unless someone can think of simpler solution (even a good hack) I have no idea
about the target.
Comment 3 caolanm 2008-10-30 17:53:27 UTC
Could we do something at a higher level than vcl in some framework area to maybe
on a .uno:DoClose on a frame we actually call "cancel all modal dialogs for that
frame" and at tne end post a new event of sort of .uno:DoRealClose would that in
theory give a valid sequence of 
cancel events
process handlers for cancels
and then the real doclose

Comment 4 philipp.lohmann 2008-10-30 18:22:26 UTC
good question. First this new method would have to know the running modal
dialogs (at least in vcl there should be a method to retrieve them). On these
would then be called EndExecute( 0 ) (where 0 may or may not be the correct
value). Then the postuser event would have to execute the real close.

let's ask the framework experts whether that is feasible.
Comment 5 mikhail.voytenko 2008-10-30 19:16:13 UTC
As far as I remember, the last time when we tried to reach something like this,
the problem with vcl dialogs was that they had to be closed in correct order, to
avoid crashes in case the dialog is already on the stack. That was workarounded
by storing locally the order of vcl-dialogs if I am not wrong. 
Currently the dialogs started asynchronously, so now the situation could be

But the main problem were the java dialogs, system dialogs and other non-vcl

As for the framework general solution, I do not see any general solution here.
Each non-vcl dialog has to be handled separately. It is quite common situation
that a frame does not know more about currently shown dialog as the vcl.
Additionally, please do not forget addons that also might show dialogs.

We could of course let each dialog register itself in the way that it must react
to the document/frame notifications, but that would be a new API as well. And it
would be no enhancement, it would be a new feature. I am actually not sure that
it worses the efforts. But may be there is a nice simple way I just do not see.
Comment 6 philipp.lohmann 2008-10-30 19:32:21 UTC
oh, yes, the non vcl dialogs are a problem. Even if only vcl is involved there
is another problem (in a more complicated scenario):

- open document 1
- open document 2
- open modal dialog (modal to document 2)
- switch to document 1
- open modal dialog (modal to document 1)
- switch back to document 2
- open modal sub dialog (modal to document 2 and its already modal dialog

-> the process stack of the main thread now looks somthing like this

    Dialog::Execute() (from doc 2)
       Dialog::Execute() (from doc 1)
           Dialog::Execute() (from doc 2)

You cannot really fall out of the execute for the dialog in the middle, although
that is probably the smaller evil compared to a crash.

Then again this is quite an elaborate example.
Comment 7 caolanm 2008-10-31 10:13:28 UTC
eek, the easier fix for me then is probably to instead just look at the qa test
itself and add in a "Kontext Filter Dialog" fallbacks check before heading
towards .uno:Close and pretend the problem doesn't exist :-)

Feel free to close this out as "never going to happen"
Comment 8 philipp.lohmann 2008-10-31 11:14:39 UTC
I wouldn't say never, but this will probably stay with us until we switch away
from vcl. Whenever that's going to be.
Comment 9 Rob Weir 2013-07-30 02:17:35 UTC
Reset assignee on issues not touched by assignee in more than 2000 days.