Apache OpenOffice (AOO) Bugzilla – Issue 44830
mis-ordered shell stack crasher ...
Last modified: 2005-03-30 12:56:22 UTC
To repeat: start impress -> Create in the wizard Switch to a view with editable text, start typing some text ** With the text still focused ** select 'Master Pages' in the right-hand-side 'Tasks' pane Now select a different task/background, then click on the expand/contract widget above - bang ... The root cause of this problem [ after much tiresome investigation ] seems to be a mis-ordered SfxShell stack in the SfxDispatcher. in sdview.cxx (sd::View::BegTextEdit) we have: pViewShell->GetViewFrame()->GetDispatcher()-> GetShell(0)->SetUndoManager(pUndoMgr); I have verified that this sets the TextObjectBar's UndoManager (as expected). Unfortunately - when we come to sd::View::EndTextEdit we have: if (pViewShell) { pViewShell->GetViewFrame()->GetDispatcher()-> GetShell(0)->SetUndoManager(pUndoMgr); But now it is the case that GetShell(0) returns an 'AllMasterPagesSelector' shell - which we duly re-set the UndoManager on. Unfortunately, that leaves the TextObjectBar's UndoManager pointing at a (now destroyed) object - which sooner or later crashes everything as we try to construct a context menu for that. <segv> #11 0x4868e1fc in sd::ViewShell::GetMenuState () #12 0x486a2fa1 in sd::DrawViewShell::GetMenuState () #13 0x486c380e in SfxStubDrawViewShellGetMenuState () #14 0x4416eb37 in SfxDispatcher::_FillState () #15 0x44178b4e in SfxBindings::Update_Impl () #16 0x4417b2f9 in SfxBindings::NextJob_Impl () #17 0x4417b190 in SfxBindings::LinkStubNextJob_Impl () #18 0x4016c515 in Timer::Timeout () I attach some notes I took while chasing it - we've shipped with a nasty hack to sd::ViewShell:ImpGetUndoManager. Needless to say, one can think of more robust & reliable ways of managing this state.
Created attachment 23696 [details] rambling debug output, traces & thoughts of dubious value
Whoops! For me it is just enough to apply a different masterpage background. It works under windows.
"to apply a different masterpage background..." after typing in some text I mean.
AF, please take over
Accepted
This is quite a nasty problem. 1. The crash as described above occurs too when the context menus of the master page controls are used to assign master pages to the document. The context menu are the big problem here. 2. In order to show a context menu we need a view shell. This view shell has to be high enough on the SFX shell stack so that it overrides other shells that handle the same slots. 3. The SFX shell stack is a stack. So when we just rearrange the order of the three view shells asociated with the three master page controls we have to take all shells above those three from the stack, rearrange the three master page view shells, and put the other shells back on the stack. 4. To be on the save side the three master page view shells are not only rearranged but are moved to the top of the whole SFX shell stack as well. 5. All this takes place while the edit mode is active and the undo manager is bound to the top most shell: The association between undo manager and view shell is broken. When the edit mode is finally ended the wrong undo manager is restored. Crash. There are two solutions (that I can think of) for this problem: 1. Leave the edit mode when a master page is assigned to slides in the document. The poblem with this is that the edit mode has to be ended before the context menu is displayed. Even when the user does not select any of its entries. 2. Do not modify the shell stack. For this we have to do two things: a) do not move the view shells of the master page controls to the top of the shell stack; make sure that the slots of the context menus are not used by any other view shell possibly on the stack. b) Replace the three view shells by one that forwards the slot calls to the correct master page control. At the moment I favor the second solution. It does not alter the behaviour (ending the edit mode) as much as the first solution. It does, however, need more changes to the code with more chances of new errors.
good 'oh; I'm glad there was no trivial fix I was missing. I was slightly amazed to see the hard-coded 'get-shell [0]' assumption all over the place, it seemed to me the way the undo-manager itself is managed is really not that optimal. If all the uses of it are fiddling with the 'top' shell in the dispatcher - is it then, really sensible & necessary to associate it with an SfxShell instead of a dispatcher ? and/or have a separate stack of undo contexts [ or something ]. Still - I have no idea what these objects really do in fact.
In the future we certainly have to make the handling of undo managers more robust and logical (do they belong to the view shell, the dispatcher, frame, or maybe to the document?). However, it would be unwise to do that now. I am afraid we have to live with that and other historical problems for the time being and try to fix the crash by adapting to them.
Well, I decided to use the first solution described above: end the text editing before removing or reordering shells from/on the shell stack. This means that the text editing is canceled before a context menu is displayed, even when none of its entries is selected.
what cws is that ? and/or any chance I can extract the patch for testing / SuSE 9.3 ? :-)
The fix in itself is quite simple. Just update sd/source/ui/view/ViewShellManager.cxx to revision 1.11.54.1. The CWS is impress39.
*** Issue 45089 has been marked as a duplicate of this issue. ***
To QA for verification. re-open issue and reassign to wg@openoffice.org
reassign to wg@openoffice.org
reset resolution to FIXED
When now applying an ew masterpage under windows all the former inserted text is lost. Ok under linux and solaris. Back to you.
Reassigned.
This new problem is covered by issue 45640 and occurs in the master, too. Therefore I set this issue back to FIXED.
Back to QA. re-open issue and reassign to wg@openoffice.org
Verified in CWS.
Tested in master m89. Closed.