Issue 30166 - Frequent crashes on file dialog resulting in data loss
Summary: Frequent crashes on file dialog resulting in data loss
Status: CLOSED IRREPRODUCIBLE
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOo 1.1.1
Hardware: All Linux, all
: P3 Trivial (vote)
Target Milestone: AOO Later
Assignee: thorsten.martens
QA Contact: issues@framework
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-13 23:35 UTC by ajkessel
Modified: 2004-07-01 15:17 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description ajkessel 2004-06-13 23:35:53 UTC
This has been pending about three months in the Debian BTS with no progress:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=240475

So I thought I'd report it here. I don't know if it happens outside of Debian
version.

Frequently, when I am using the save file dialog, OO just hangs entirely.  kill
-abrt does not save data.  No useful information appears in terminal window when
run from terminal window.

It appears that the hanging occurs when I enter text to navigate through
directories or chose a filename; I don't think it's ever hung when I use only
the mouse.  Sometimes it hangs on the save, but sometimes it hangs just
navigating to a directory (where the directory name has been entered with the
keyboard).

This of course is a serious problem for me and results in frequent data loss.

I don't think anyone in Debian has been able to reproduce it, but it happens
nearly daily for me if I'm not careful (i.e., if I use the keyboard rather than
the mouse).

There are no NFS or other sorts of network volumes involved.  The machine
behaves perfectly well with other applications and I've noticed no other pattern
of hanging other than this dialog in OO.
Comment 1 michael.ruess 2004-06-14 07:53:47 UTC
reassigned to component framework.
Comment 2 thorsten.martens 2004-06-14 10:40:08 UTC
Please check this problem with a more recent OOo version like OOo 1.1.2rc3
(645m44 build) and be sure that there are no stale mounts while travelling
through the volumes in the file-open dialog.
Comment 3 ajkessel 2004-06-14 13:27:51 UTC
By stale mounts, I assume you mean an NFS or other network volume that no longer
works.  This is definitely not the case--I've experienced this crash when no
network volumes are mounted at all.

I'll see if it still occurs with 1.1.2rc3.
Comment 4 ajkessel 2004-06-14 20:18:53 UTC
Appears to be fixed with 1.1.2rc3.  So far today no crashes, and the save dialog
is much "snappier" than it was under 1.1.1.

One difference appears to be that the filename is no longer "autocompleting"
like it did before--if I type the first few characters of a file or directory
name in the displayed directory, it doesn't complete.  Don't know if this is
related, but that was often where the crash occurred--when hitting return after
the automatic file/directory name completion.
Comment 5 mci 2004-06-15 09:04:35 UTC
Hi ajkessel,

thanks for using and supporting OpenOffice.org...

I'm using OOo1.1.2RC3 here on RedHat Linux and "autocompletion"of
directories/files works here...
It seems the described behaviour doesn't occur anymore on your PC(s)...
I set this Issue to "worksforme"....
Please report back if your problem occurs again...
Comment 6 ajkessel 2004-06-15 17:48:22 UTC
Actually, to clarify: the autocompletion works fine on "open" document, just not
on "save as" document. Maybe this is an intentional choice? It seems to me that
autocompletion should at least work for directory names (I can imagine
accidentally overwriting an existing file if the autocompletion occurs on
filenames, as it did with 1.1.1).

Let me know if I should open a new issue on this.  I don't know if it's just me
or not.
Comment 7 mci 2004-07-01 15:17:58 UTC
Hi ajkessel,
On the debian  issue you wrot ethat this works now even with the debian version
of OOo (which we are not responsible for)...
So I'm going to close this Issue now...
I think "no autocompletion" on saving is the wanted behaviour since
autocompletion would take an existing file/directory name, which could be a
valid file name, too.
So a user could overwrite files more easily as if the user needs to type in the
file name (ok, an error message would appear but a lot of people don't read
message boxes...)...
If you want that behaviour to be changed, please file an "enhancement" issue...