Apache OpenOffice (AOO) Bugzilla – Issue 63067
Context-Menue crashes OOoBase and destroys/deletes all forms from database
Last modified: 2006-06-01 13:03:39 UTC
Hi all (Sorry for any bad english) Specs: Win XP Pro SP2 x86 patched up2date OOo 2.02 Base german Database engine: HSQL Also tested and recreated the problem with an Win2k3R2 (patched up2date) in a VMware session. some error-reports were sent with the automatic recovery utility, the id's are: rsq89f and rsq89f and r6889f and r3889 and r5889f. Problem: An open contextmenu in a forms-window(data input or editing the form itself) could crash OOo Base, corrupting the database. The automatic repairmode will try to restore the database, but with no success. All existing forms are defective and unable to open. Closing OOo and/or saving the database deletes the forms completely. Detail: 1. A forms-windows is open. 2. By clicking with the right mouse button on a field, the contextmenue appears(copy/paste/....) 3. without closing the context-menue(the user does not click anywhere inside the window or neither selects a option from the context-menue) the user closes the windows by 'X' 4. OOo base -> crash to desktop 5. the automatic reapirmode appears and informs the user about the crash and the repair-mode. 6. user is clicking himself through the repairmode (selecting the database, filing an error-report and so on) 7. OOo base is starting now the 'repaired' database. 8. the forms appear in the list, but by clicking on them a 'file not found-error' is displayed 9. with closing the database the user will be asked to save the database. 9.1 with saving it, the next time the database will not have any forms. If required, I could send you the complete database (69 kb) by email. Cu all
Created attachment 34783 [details] the database after the crash - no forms left
Attached the database, which i mentioned i could seny by mail
confirmed with ooo 2.0.2 on WinXP and Linux crash reports have been sent, Issue ID was mentioned in the description
Hi, I can reproduce this, reassign it to the right developer and set target. - open any context menu inside an embedded form - click on the close (X) for this window - select "discard" when closing ==>> crash Bye Marc
fs->pl: the one we talked about. Problem is that the main window is closed while the PopupMenu::execute is still on the stack. While it's up to impossible to implement all *usages* of PopupMenu::Execute in a way that closing the surrounding document is deferred until the menu is closed, we agreed that we could find a central place in VCL to do this: Determine that a popup menu is still open, cancel it, and defer the closing until the menu is not being executed anymore.
for the record: the part that the document recovery destroys all forms in the database document is now issue 63113 (http://qa.openoffice.org/issue_handling/basic_rules.html#one_per_issue)
fixed in CWS vcl56
please verify in CWS vcl56 re-open issue and reassign to msc@openoffice.org
reassign to msc@openoffice.org
reset resolution to FIXED
verified in cws vcl56 You can found more information about this CWS in the EIS tool at http://eis.services.openoffice.org/EIS2/cws.SearchCWS
Hi, this is fixed in the current master. The current master is available at http://download.openoffice.org/680/index.html I close this issue now. Bye Marc