Bug 53570 - FILEOPEN Unknown File Type Brings up Spreadsheet CSV Import Dialog or Opens Writer instead of Filter List
Summary: FILEOPEN Unknown File Type Brings up Spreadsheet CSV Import Dialog or Opens W...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: CSV-Dialog
  Show dependency treegraph
 
Reported: 2012-08-16 05:03 UTC by Rainer Bielefeld Retired
Modified: 2023-08-29 03:18 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (794 bytes, application/octet-stream)
2013-05-23 21:57 UTC, Harald Koester
Details
testcase (6 bytes, application/octet-stream)
2016-06-08 17:27 UTC, Juan Picca
Details
testcase files to reproduce behavior with localc (294 bytes, application/x-compressed-tar)
2016-06-08 17:31 UTC, Juan Picca
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2012-08-16 05:03:50 UTC
Steps how to reprodue with Server Installation of  "LibreOffice 3.6.0.4  German UI/Locale [Build-ID:  932b512] on German WIN7 Home Premium (64bit):

0. Download sample document "y"
1. Start LibO
   LibO Start Center appears 
2. LibO Menu 'file -> Open -"y" -> <open>
   Expected: import filter list appears
   Actual: Spreadsheet CSV import dialog

I created sample document: 
Download Attachment 59008 [details]
Rename the .jpg to "x"
Do a 7z compression leads to "x.7z"
Rename "x.7z" to "y"
Comment 1 Urmas 2012-08-16 06:21:56 UTC
Indeed, CSV filter is offered even for text files.
Comment 2 Tristan Miller 2012-08-16 06:24:42 UTC
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.
Comment 3 Kohei Yoshida 2012-08-16 14:04:49 UTC
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?
Comment 4 Tristan Miller 2012-08-16 14:35:17 UTC
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.
Comment 5 Kohei Yoshida 2012-08-16 14:43:47 UTC
(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.
Comment 6 Tristan Miller 2012-08-16 15:45:41 UTC
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.
Comment 7 Kohei Yoshida 2012-08-16 15:47:17 UTC
(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.
Comment 8 Kohei Yoshida 2012-08-16 15:49:01 UTC
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.
Comment 9 Tristan Miller 2012-08-16 17:16:06 UTC
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.
Comment 10 Kohei Yoshida 2012-08-16 17:30:17 UTC
(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.
Comment 11 Urmas 2012-08-18 16:08:17 UTC
Am I the only one concerned with Yoshida's obscurantist behaviour? First he publically refuse fixing to critical bugs, and now this?
Comment 12 Rainer Bielefeld Retired 2012-08-18 17:31:25 UTC
> 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"
Comment 13 Ivan Timofeev (retired) 2012-08-18 18:53:54 UTC
(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.
Comment 14 Ivan Timofeev (retired) 2012-08-18 19:01:03 UTC
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.
Comment 15 Tristan Miller 2012-08-18 19:21:33 UTC
(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.
Comment 16 Harald Koester 2013-05-23 21:57:09 UTC
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
Comment 17 QA Administrators 2015-03-04 02:21:43 UTC Comment hidden (obsolete)
Comment 18 Harald Koester 2015-03-06 11:33:20 UTC
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.
Comment 19 tommy27 2016-04-16 07:27:04 UTC Comment hidden (obsolete)
Comment 20 Juan Picca 2016-06-08 17:27:11 UTC
Created attachment 125554 [details]
testcase
Comment 21 Juan Picca 2016-06-08 17:28:05 UTC
Comment on attachment 125554 [details]
testcase

csvdialog_oneline_utf8_dos.xxx
Comment 22 Juan Picca 2016-06-08 17:31:54 UTC
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.
Comment 23 Harald Koester 2016-08-26 18:41:19 UTC Comment hidden (obsolete)
Comment 24 QA Administrators 2018-07-21 02:39:41 UTC Comment hidden (obsolete)
Comment 25 Harald Koester 2018-07-24 13:07:20 UTC Comment hidden (obsolete)
Comment 26 QA Administrators 2019-07-30 03:13:00 UTC Comment hidden (obsolete)
Comment 27 Harald Koester 2019-08-28 13:18:36 UTC
Bug still exists respective Comment 18 with version 6.3.0. (64 Bit, Win 10)
Comment 28 QA Administrators 2021-08-28 03:53:08 UTC Comment hidden (obsolete, spam)
Comment 29 QA Administrators 2023-08-29 03:18:22 UTC
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