Indeed, CSV filter is offered even for text files.

This problem occurs with almost every unknown file type I've tried.  See Bug 53553 and Bug 53554 for two unknown file types which produce different (but also wrong) behaviour.

Also, Astron wrote to me in an e-mail that "there is now a difference between opening files from the Start Center, from Writer and from Calc", so someone should try opening a file from each of these starting points (and maybe also from the command line) to see if the problem is consistently reproducible.  I won't have time to do so myself for at least a day.

Yes.  This behavior is somewhat intended, though it could perhaps be improved.

The ascii text file type is now the last catch-all type that we use, when all the other file type detections fail to detect it as their type.

BTW, what's the use case of trying to open an unknown file format?  If the format is unknown to us, then there is no way to open it correctly anyways?

Is there any possibility that the format autodetection will throw a false negative?  (That is, you try to open a file with a format that LibreOffice supports, but LibreOffice fails to recognize it as that file format.)  In such cases it *would* be of use for the user to manually select the file format from a list.

(In reply to comment #4)
> Is there any possibility that the format autodetection will throw a false
> negative?

Sure it's possible, and that would be a bug.  Not a reason enough to warrant this ugly file format selection dialog IMO.

Why is it necessarily a bug?  There are some files which could easily be interpreted as valid in two or more formats.  To take a trivial example, a file containing the following single line could be a CSV file or it could be a text file:

Hello, world!

Say this filename is saved without an extension (as text files sometimes are).  Try to open it with LibreOffice and it's automatically assumed to be a CSV file.  Why not ask the user what format it really is?  It's not necessary to present him a list of every single format LibreOffice supports; the list could be restricted to plausible entries.

(In reply to comment #6)
> Why is it necessarily a bug?  There are some files which could easily be
> interpreted as valid in two or more formats.  To take a trivial example, a file
> containing the following single line could be a CSV file or it could be a text
> file:

For the purpose of type detection, csv and text files are considered one and the same.  It depends on whether you open it from calc or writer that determines its fate.

Besides, if you want to force a particular file type, you can do that in the file open dialog.  Just specify the file type there, and that will be honored.

On Thursday 16 August 2012, Kohei Yoshida wrote:
> It depends on whether you open it from calc or writer that
> determines its fate.

What about the cases where such files are opened in neither Calc nor Writer?  Sometimes the files are opened from Base or Draw or the Start Center. Sometimes they're opened from the command line.  Sometimes they're opened from a file manager. Sometimes they're opened by clicking on a link in a web browser, newsfeed aggregator, e-mail client, or IM client.  Particularly in these last cases, the user may not have an easy way of forcing the file to open in a particular LibreOffice component; the file doesn't yet exist on his system, so he can't first open Calc or Writer and then use File->Open.

(In reply to comment #9)
> On Thursday 16 August 2012, Kohei Yoshida wrote:
> > It depends on whether you open it from calc or writer that
> > determines its fate.
> 
> What about the cases where such files are opened in neither Calc nor Writer? 

Then open Calc or Writer first before opening the file, or do what I said in Comment 8.

> Sometimes the files are opened from Base or Draw or the Start Center.

Sure, and that *never* brought the file selection dialog when opening a text file.  What's your point there?

 Sometimes
> they're opened from the command line.  Sometimes they're opened from a file
> manager. Sometimes they're opened by clicking on a link in a web browser,
> newsfeed aggregator, e-mail client, or IM client.  Particularly in these last
> cases, the user may not have an easy way of forcing the file to open in a
> particular LibreOffice component; the file doesn't yet exist on his system, so
> he can't first open Calc or Writer and then use File->Open.

Still, if you are opening a text file, that had *never* brought up that ugly file type selection dialog.  So I don't see your point there.

FYI, that file selection dialog occurred *only when* the type detection failed.  Deciding which app to open a text file was never, ever part of that type detection process.  So we are talking past each other here.

Anyway, I'll remove myself from CC.  I already said what I had to say on this topic.

Am I the only one concerned with Yoshida's obscurantist behaviour? First he publically refuse fixing to critical bugs, and now this?

> FYI, that file selection dialog occurred *only when* the type detection failed.

That would be a useful behavior. But I doubt that a file type detection can fail more clearly than with my "y", so the question is whether there still documents are left where the document filter list will open?

LibO 3.3.3, 3.4.5, 3.5.1 ofer the Writer encoded .txt filter for that "y", IMHO not useful
With LibO 3.6 we now have the Spreadsheet .csv filter, what also is not useful.

So I wonder: Is there a rule when the file type filter should open instead of leaving user decide using the file type list in the file open dialog? Do we need that filter dialog at all? What is the difference in the result between selecting a file type there and in file open dialog?

@Ivan:
I added you to cc because this issue hire might have influence to "Bug 41000 - FILEOPEN - Filter Selection dialog needs structure and preselection"

(In reply to comment #12)
> so the question is whether there still
> documents are left where the document filter list will open?

In theory if LibO *can* open a doc (i.e. has a wanted filter), its type/filter should be detected right. But who knows, I am just guessing.

> Do we need that filter dialog at all? 

Hmm, probably not (so I won't fix Bug 41000, cool) if there are no bugs in the format detection code.

Maybe it would make sense to show in corner cases something like:

  "Unable to detect a format of <filename.ext>"
  [Open as text] [Open as spreadsheet] [Cancel]

if a file gets opened from a Start Center.

(In reply to comment #14)
> Maybe it would make sense to show in corner cases something like:
> 
>   "Unable to detect a format of <filename.ext>"
>   [Open as text] [Open as spreadsheet] [Cancel]
> 
> if a file gets opened from a Start Center.

Yes, that's what I was thinking.

Created attachment 79725 [details]
Example file

I think I observed the same bug with a little png file where I changed the file extension from "png" to "xxx" and tried to open it. I will provide this file as attachment. I made some more tests with this file. The result depends on from where you open this file:
(1) From the Start Center: File is opened with Draw. OK!
(2) From Writer: A text document is opened. Not OK !! Expected: Either opening with Draw (best case) or a message according to comment 14 or provide an organized list where the user can select an appropriate file format according the proposal of bug 41000.
(3) From Calc: Dialog "Text Import" is displayed. I assume that this dialog is meant with "CSV import dialog" of the initial description. To my opinion not OK, hence LibroOffice assumes that the file is a text file which should be imported to a spreadsheet. But this is not the case !! Expected: Either opening with Draw (best case) or a message according to comment 14 or provide an organized list where the user can select an appropriate file format according to the proposal of bug 41000.
(4) From Impress, Draw, Math: File is opened with Draw. OK!

I did the same tests with a LO installation where I deselected the installation component "Graphic Filters". In this case the result is different:
(1) From the Start Center with "Open...", Calc, Impress, Draw and Math: Dialog "Text Import" is displayed. To my opinion not OK, hence LibroOffice assumes that the file is a text file which should be imported to a spreadsheet. And this is not the case !! Expected: Either a message according to comment 14 or provide an organized list where the user can select an appropriate file format according to the proposal of bug 41000.
(2) From Writer: A text document is opened. Not OK !! Expected: Either a message according to comment 14 is displayed or provide an organized list where the user can select an appropriate file format according the proposal of bug 41000.

In order to reproduce the bug, download the attached document and try to open it under the mentioned conditions.

Just an idea: What about a message something like:

  "Unable to detect a format of <filename.ext>"
  [Open as text] [Open as spreadsheet] [Open other format] [Cancel]

And then if the user clicks "Open other format" s/he gets the full list of possible formats.

OS: Win 7, LO version: 4.0.3

In version 4.4.1 with Win 7 the behaviour is improved significantly. If the Graphic Filters are installed (see comment 16) and with the attached test file LO always starts Draw and displays the graphic of the test file correctly. 

But if the Grapic Filters are not installed the behaviour with the test file is not correct. If you open the test file from the Start Center, from Writer, from Impress and from Draw Writer is started and displays nonsense. If you open the file from Calc the Text Import dialogue is opened. Also in this case nonsense is displayed. In both cases I would expect a filter list.

Also if you try to open a file created according the original description of Rainer the behaviour is not OK. If you open the file "y" with Graphic Filters installed, from the Start Center, from Writer, from Impress and from Draw also here Writer is started and shows nonsense. If you open the file from Calc the Text Import dialogue is opened and also shows nonsense. Expected: Filter list.

Hence the behaviour has changed also summary changed.

Created attachment 125554 [details]
testcase

Comment on attachment 125554 [details]
testcase

csvdialog_oneline_utf8_dos.xxx

Created attachment 125555 [details]
testcase files to reproduce behavior with localc

NOTE: ignore the previous attachment

I can reproduce this bug in libreoffice 5.1.3-2 (debian stretch/sid).

To reproduce, i try open a csv file (separated by tabs instead of commas) with a bad file extension (in my case, the file extension is generated by a program with the ods extension, but i change it to xxx here to avoid confusion) using localc.

I attach some files created by hand while try to understand the cause of the bug.

The conclusion from the files: if the file has non-ascii characters (ñ) separated by a dos newline (\r\n) it open the file using writer. In the other combinations the calc csv import dialog is shown.

Bug still exists respective Comment 18 with version 6.3.0. (64 Bit, Win 10)

Dear Rainer Bielefeld Retired,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug