Apache OpenOffice (AOO) Bugzilla – Issue 8928
all applications allows save file as to a directory, general io then crash
Last modified: 2003-03-13 11:13:54 UTC
when saving as if you type in a filename then click on a directory then the save button you get Error saving document Untitled1: General Error. General input/output error. if you now save, the application crashes tested with writer and calc presume all applications do this ui shouldn't allow this / code could save as the filename within the selected directory
Thank you for using and supporting OOo. Duplicated on RH 8.0, OOo 643: 1. Start Writer. 2. Enter some text. 3. File->Save 4. Enter text in Filename: field. 5. Click and highlight directory. 6. Click on "Save" button. 7. Error dialog: Error saving document Untitled1: General Error. General input/output error. 8. Do some changes. 9. Click on Save icon in toolbar. OOo crashes with "Aborted" text in terminal.
Reassigning to framework team. I hope I have the right team.
Confirmed.
Created attachment 3793 [details] stack of 8928
SFX644MI! SfxObjectShell::GetState_Impl(class SfxItemSet &) + 756 bytes SFX644MI! SfxStubSfxObjectShellGetState_Impl(class SfxShell *,class SfxItemSet &) + 15 bytes SFX644MI! SfxDispatcher::_FillState(class SfxSlotServer const &,class SfxItemSet &,class SfxSlot const *) + 495 bytes SFX644MI! SfxBindings::Update_Impl(class SfxStateCache *) + 306 bytes SFX644MI! SfxBindings::Update(unsigned short) + 537 bytes SFX644MI! SfxVirtualMenu::Activate(class Menu *) + 3815 bytes SFX644MI! SfxVirtualMenu::LinkStubActivate(void *,void *) + 15 bytes VCL644MI! Menu::Activate(void) + 76 bytes VCL644MI! PopupMenu::ImplExecute(class Window *,class Rectangle const &,unsigned long,class Menu *,unsigned char) + 853 bytes VCL644MI! MenuBarWindow::ImplCreatePopup(unsigned char) + 498 bytes VCL644MI! MenuBarWindow::ChangeHighlightItem(unsigned short,unsigned char,unsigned char) + 932 bytes VCL644MI! MenuBarWindow::MouseButtonDown(class MouseEvent const &) + 139 bytes VCL644MI! ImplHandleMouseEvent(class Window *,unsigned short,unsigned char,long,long,unsigned long,unsigned short,unsigned short) + 5483 bytes VCL644MI! ImplWindowFrameProc(void *,class SalFrame *,unsigned short,void const *) + 287 bytes VCL644MI! SalFrameWndProc(struct HWND__ *,unsigned int,unsigned int,long,int &) + 4560 bytes VCL644MI! SalFrameWndProc(struct HWND__ *,unsigned int,unsigned int,long,int &) + 513 bytes VCL644MI! SalFrameWndProcW(struct HWND__ *,unsigned int,unsigned int,long) + 38 bytes USER32! 77e02e98() USER32! 77e030e0() USER32! 77e0320f() VCL644MI! ImplSalYield(unsigned char) + 191 bytes VCL644MI! ImplSalYield(unsigned char) + 79 bytes VCL644MI! SalInstance::Yield(unsigned char) + 169 bytes VCL644MI! Application::Yield(void) + 95 bytes VCL644MI! Application::Execute(void) + 47 bytes SOFFICE! desktop::Desktop::Main(void) + 6282 bytes VCL644MI! SVMain(void) + 251 bytes SOFFICE! 0112a5a8() SOFFICE! WinMainCRTStartup + 308 bytes KERNEL32! 77e87d08()
ATR->FS: I can reproduce this bug at all OS if I use our own save-as dialog in src461- and srx644-versions. with a non-pro I get this stack:
accepting. I don't get the crash here, but even the wrong error dialog deserves some attention .... (I am unable to save or load or edit the file later on)
FS->MBA: one error is that the file dialog wrongly interprets the "save" command as finishing the dialog, though a directory is selected, and then returns the URL for the directory as target. I'll fix this. However, it seems that the sfx code does not handle this error properly, too - perhaps you may want to have a look at this, too, though "your problem" will vanish when "my problem" is fixed.
andreas, is this really a 1.0.3 issue, or are there chances for 1.1Beta?
not yet sure how to fix this. Possible alternatives: I when "save" is pressed in the dialog 1. ignore any selection in the upper pane 2. a. when a directory is selected, open this directory, as it would be done when no file name is entered in the respective field b. when a file is selected, ? II whenever a selection is made in the upper pane, fill the file name field with the title of the selected item. Should be no problem for save-as, because we have a single-selection there. I'd probably tend to II. Any opinions out there?
btw: just found that StarOffice 5.2 did a mix of the above: III. when selecting a directory, then do I.2.a. when selecting a file, then do II. sounds like an interesting solution, too :)
fixed - should be in 1.0.3 files: svtools/source/filepicker/iodlg.cxx 1.49.8.1 (SRC641 branch) 1.69.6.1 (CWS os1)
re-opening for changing the ownership
FS->TM: please verify in CWS os1
Problem has been fixed in the latest internal version. The behaviour has been changed to act the same way, the windows system dialog does.
inital reporter most happy! many thanks
Changed state to "verified" thus the fix can make its way into OpenOffice 1.1 Beta build.
*** Issue 10676 has been marked as a duplicate of this issue. ***
As mentioned on the qa dev list on March 5th I will close all resolved <wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details.