Code pointer: http://opengrok.libreoffice.org/xref/core/filter/source/textfilterdetect/filterdetect.cxx#150 ?
    150         // Decide which filter to use based on the document service first,
    151         // then on extension if that's not available.
    152         if (aDocService == CALC_DOCSERVICE)
    153             aMediaDesc[MediaDescriptor::PROP_FILTERNAME()] <<= OUString(CALC_TEXT_FILTER);
    154         else if (aDocService == WRITER_DOCSERVICE)
    155             aMediaDesc[MediaDescriptor::PROP_FILTERNAME()] <<= OUString(WRITER_TEXT_FILTER);
    156         else if (aExt == "csv" || aExt == "tsv" || aExt == "tab" || aExt == "xls")
    157             aMediaDesc[MediaDescriptor::PROP_FILTERNAME()] <<= OUString(CALC_TEXT_FILTER);
    158         else
    159             aMediaDesc[MediaDescriptor::PROP_FILTERNAME()] <<= OUString(WRITER_TEXT_FILTER);

Checked with version 5.2.0. Bug still exists.
Checked with version 4.0.5. Bug already exists.
Checked with version 3.6.7. Bug already exists.
Checekd with version 3.6.0. Bug already exists.
Checked with version 3.5.7. Works as expected.
Checked with version 3.3.0. Works as expected.

Henced Bug is a regresseion and has been introduced with version 3.6.0.

As can be seen in the code pointer comment 1 (have been some minor changes for support of compressed csv since--so http://opengrok.libreoffice.org/xref/core/filter/source/textfilterdetect/filterdetect.cxx#175 )

// Decide which filter to use based on the document service first,
// then on extension if that's not available.

Document service will be WRITER_DOCSERVICE if Writer is open with focus. CALC_DOCSERVICE if Calc is open--where the Text Import filter dialog will assert for files with extensions: csv, tsv, tab, xls, csv.gz

A comma, tab, semicolon, space or user defined delimiter text file will open by default into Calc -- that was done for bug 68903

Meaning if the StartCenter is present, the Open button opening a comma separated (.CSV/.XLS/.CSV.GZ) or tab separated (.TSV/.TAB/.XLS) labeled file (semicolon, space or user selected dlimiters would need one of the established extensions) will all present the "Text Import" filter dialog and the delimited fields will be opened into the Calc module.

If Draw, Impress, or Math module is active and has focus the File -> Open .uno:Open action will call the "Text Import" filter dialog for import into a Calc session based on file extension.

If the File -> Open comes when an active Calc module has focus--the CALC_DOCSERVICE is active and the CSV/TSV/TAB/XLS delimited file will call the "Text Import" filter dialog and be parsed into a Calc sheet.

Only if the File -> Open comes when an active Writer module has focus--and the WRITER_DOCSERVICE is active and the CSV/TSV/TAB/XLS/CSV.GZ delimited file will all open as text in Writer.

This behavior is consistent and not unexpected. No reason to change.

(In reply to V Stuart Foote from comment #4)
Hi Stuart,
> 
> Only if the File -> Open comes when an active Writer module has focus--and
> the WRITER_DOCSERVICE is active and the CSV/TSV/TAB/XLS/CSV.GZ delimited
> file will all open as text in Writer.
> 
> This behavior is consistent and not unexpected. No reason to change.

I'm sorry I don't agree. To my opinion generally the 'character' separated value files should be opened with calc by default. Usually only Calc is able to interpret these kind of files and to display them in a convenient way. This should be done independently from where (Start Center, Writer, Calc, ...) these files are opened. A different treatment only irritates the user like I was.

It may be possible that in some rare cases a user likes to open these kinds of files with Writer. But then to my opinion a user should explicitly select this option. I see two ways to do this. First it can be done by selecting text documents ["Text documents (*.oth, *odt, ...)] in the Open dialogue or secondly with a check box "Open with Writer" in the Text Import dialogue. But also in these cases this should always be done independently from where these files are opened.

Hence Status set back to NEW.

Best

The textfilterdetect source could be reworked to eliminate WRITER_DOCSERVICE from the filter process--and adding specific filter type for opening with Writer on occasion a user really prefers that. 

But not clear there is much demand for adjusting what is presently a consistent and rational default behavior.

UX-advise, and see if any dev has an interest.

As .csv files arent displayed when "Text document" is selected, not sure how it can be opened in writer in that manner.

But back to the point, i would have .csv file exclusively open in calc, as users who want to edit it otherwise would open it in gedit rather than writer.

(In reply to Yousuf Philips (jay) from comment #7)
> As .csv files arent displayed when "Text document" is selected, not sure how
> it can be opened in writer in that manner.
> 
> But back to the point, i would have .csv file exclusively open in calc, as
> users who want to edit it otherwise would open it in gedit rather than
> writer.

Believe that's the point of OP, it can't. Internally if the Writer module is running the WRITER_DOCSERVICE takes precedence over the file extension in selecting the text filter to open the comma separated value .CSV file (a.k.a "character" separated value).

With WRITER_DOCSERVICE set (because the call to open comes from a Writer session) the document is not passed to the Text import filter for opening into Calc.

Meaning--if you want to open it in Writer, launch Writer and open it there--regardless of handling for the file extension. Otherwise the file extension will trigger the text import filter from any other launch scenario. And why I don't see much need to change anything.

(In reply to V Stuart Foote from comment #8)
> Believe that's the point of OP, it can't. Internally if the Writer module is
> running the WRITER_DOCSERVICE takes precedence over the file extension in
> selecting the text filter to open the comma separated value .CSV file (a.k.a
> "character" separated value).

Harald stated in comment 3 that the issue was a regression, so it used to work in 3.3.0 and is broken presently. So i would be in favour of returning the old behaviour of it always opening in calc and not reply on what module is currently open.

OK, but the filter for being able to open in Writer will need to be added or we actually will end up with issue of bug 89684.

Also if doing this, as in bug 89685 for "Spreadsheets", the filter group for "Text documents" as well as the Writer and Calc filter segments will need entries.

Formats that can be opened by more than one app, such as html rtf and plain text (which is what a csv file is, as there is no way to "detect" csv files by content) are opened in the currently active app. That's an intentional change made in LO, as noted by Kohei at https://lists.freedesktop.org/archives/libreoffice/2014-July/062540.html

To me it is understandable and consistent behavior, as if you open a .csv file from inside gedit, you don't expect it to open in Calc, because that's a separate app. So the same should apply to Writer (which isn't exactly a separate app technically, but it is for the end user). That's a way to open the file in Writer for someone who need it, instead of telling him to scroll a long list of formats. And open Calc to be able to open the file from there is just one click away.

I however do understand why some people prefer that a plain text files with a .csv extension would always open in Calc. But instead of fighting endlessly on what the default behavior should be, I suggest to make this configurable, so hopefully everyone will be happy.

According to comment 3, it was first reproduced in 3.6.0.4, thus updating version accordently.

Removing needsUXEval since we have more or less an agreement to load CSV by default into Calc regardless of where it is being opened. But I disagree with Maxim's suggestion in comment 11 to have an option, at least not in the configuration dialog.

(In reply to Heiko Tietze from comment #13)
> Removing needsUXEval since we have more or less an agreement to load CSV by
> default into Calc regardless of where it is being opened. But I disagree
> with Maxim's suggestion in comment 11 to have an option, at least not in the
> configuration dialog.

I don't agree to a change from current behavior. It is not necessary.  

Placement of configuration setting to modify behavior of the WRITER_DOCSERVICE could be either the Options dialog, or as and Expert configuration stanza. Or alternatively do what was suggested (comment 6) eliminate/override the document service and open CSV by default to Calc, but provide specific filter entry to open in Writer.

It all depends on what we see as correct default behavior for opening a CSV when a Writer session is open and has focus. To me, and as currently implemented we have the correct defaults in place and honoring the document service.

Deciding a default, and where to place configuration needed to change it, remains a UX issue.

(In reply to V Stuart Foote from comment #14)
> I don't agree to a change from current behavior. It is not necessary.  

Looks like I misunderstood:

(Yousuf Philips (jay) from comment #9)
> Harald stated in comment 3 that the issue was a regression, so it used to
> work in 3.3.0 and is broken presently. So i would be in favour of returning
> the old behaviour of it always opening in calc and not reply on what module
> is currently open.

(V Stuart Foote from comment #10)
> OK, but the filter for being able to open in Writer will need to be added or
> we actually will end up with issue of bug 89684.

And as you say with
 
> Placement of configuration setting to modify behavior of the
> WRITER_DOCSERVICE could be either the Options dialog, or as and Expert
> configuration stanza. Or alternatively do what was suggested (comment 6)
> eliminate/override the document service and open CSV by default to Calc, but
> provide specific filter entry to open in Writer.

you accept to open Calc by default but provide specific filter in Writer. As a side note many confusion comes from the module agnostic approach to open files with the module that is linked with the extension.
 
What do you expect from UX now? Where a configuration should be stored? My take on this is

(In reply to Heiko Tietze from comment #13)
> ... I disagree with Maxim's suggestion in comment 11 to have an option, 
> at least not in the configuration dialog.

Tickets will not go into production unless UX is removed, that's what has been agreed lately in the ESC.

It's worth mentioning that the behavior can be changed via extensions. Just override the "DetectService" property of the "generic_Text" type with your own service, and implement it the way you want (with a possible fallback to the default one for cases you don't want to handle). I tried it, and it seems to work. So there is no real need for additional config in LO core.

These fall through generic_Text filter behaviors are as designed [1], and current order of CALC_DOCSERVICE -> WRITER_DOCSERVICE -> file "extension", or fall through to Writer is intentional [2].  

As in the see also bug 65017 for RTF handling it is a feature introduced at 3.6, removing "regression".

Again, if you want a CSV (of any flavor delimiter (comma, tab, space, etc.) to open into Calc--do not have a Writer session open with canvas focus! Writer can be open, but not have focus--and the Text Import dialog for import to Calc will launch.

**And if you want to open CSV into Writer--open it from a Writer session**

This is the way the generic_Text filter was implemented. Again see no need to change our handling--no need to change filter order--and there is nothing incorrect as implemented!

The otherwise valid enhancement of adding missing filter(s) to the Writer module and Calc module type lists (e.g. bug 89685) is not bound to generic_Text filter handling of the CSVs.

If UX needs to drive this a different direction (the Writer_DOCSERVICE filter could be removed)--please just be aware that what we have was intentional and well reasoned and works. 

=-refs-=

[1] Kohei's initial PlainTextFilterDetect for CSV & TXT by DOC_SERVICE first and then by extension, subsequently expanded to more formats...  https://cgit.freedesktop.org/libreoffice/core/commit/?id=8b8e24544793f4ec6f61edb7ce8ac10bf6bb0981

[2] Current support for open into Calc for file extensions "csv", "tsv", "tab", "xls" and ".csv.gz" file extensions when Writer service is not active.
http://opengrok.libreoffice.org/xref/core/filter/source/textfilterdetect/filterdetect.cxx?a=true#181

Created attachment 130066 [details]
extension to open csv always in calc

Following my last comment, attached a simple extension that will make csv open always in Calc.

In addition, I forgot that the current behavior is actually controlled by the special .uno:OpenFromWriter command. Making csv open always in Calc is only a matter of customizing the toolbar/menubar and swapping .uno:OpenFromWriter with a plain .uno:Open.

I think Stuart explains clear why the current behavior is not a bug, designed and consistent.
One would expect that users working with csv files will understand this fast enough and do what is needed to open such files in the module they prefer.
Using the extension that Maxim kindly attached, can be done too of course.

Having the changes in the past in mind, I support Stuart's and Maxim's point of view.

(In reply to Maxim Monastirsky from comment #18)
> In addition, I forgot that the current behavior is actually controlled by
> the special .uno:OpenFromWriter command. Making csv open always in Calc is
> only a matter of customizing the toolbar/menubar and swapping
> .uno:OpenFromWriter with a plain .uno:Open.
Very interesting. Didn't know that there exists 2 ways for opening a document. In the function list of the Customize dialog are 2 "Open" items but it's not obvious for the user what they do or what's the difference between them. (Hopefully fixing bug 108458 will improve that.)

We had a hot discussion during the design meeting. There are arguments for both options and people are split. The safest way is to keep the current behavior, so WF.

*** Bug 157601 has been marked as a duplicate of this bug. ***

CSV is a spreadsheet file format defined in rfc 4180. It is counter productive to have to modify libreoffice to get the files to open with the correct application, text files also should be opened with writer by default. 

Opening a .csv with calc will bring liberoffice in line with rfc 4180
See the definition of a CSV format:
https://www.rfc-editor.org/rfc/rfc4180#page-2

It is a common work flow use case to be working in a text document then needing to open a CSV for reference. 
I would say if a user has a need to open CSV files in writer then they should use an extension for that.

I attached a untested patch in my closed bug report 157601 that restores the correct behavior. 
Thank you for your consideration

(In reply to Turtle from comment #24)

Unfortunately, your post gives nothing new to the discussion already happened here. It is a common place that there's a RFC (which is, btw, just a memo to summarize some existing and most common elements of the huge variety of existing (and pre-existing) CSV flavors). It is known that some people open CSVs when already work with text files.

FTR: the correct code pointer is not comment 1, but comment 4 (so it is PlainTextFilterDetect::detect which needs to be changed, it this request is implemented).

Let me summarize the arguments.

1. In favor of the change:

1.1. CSV is a tabular format, and it is exceptionally rare to want to open it in Writer, in which case, there is a mechanism to explicitly choose the filter.
1.2. Opening it differently depending on the currently active document may be seen as unexpected and counter-intuitive- by people who are well-aware that LibreOffice is a monolithic application.
1.3. Writer is not a text editor anyway; so it not suited to edit plain text documents - if so wanted, users would use notepad/gedit for such a task.
1.4. The extensions like CSV, TSV, XLS (also often used in CSVs) is usually given explicitly to automatize opening in the spreadsheet application.

2. In favor of the current behavior:

2.1. Exactly contrary to 1.2, for people who are used to the concept that each module is "separate" (e.g., coming from MS Office), the behavior that when a file is opened using Writer menu, it would be opened in Calc, would be counter-intuitive; such people would rather open CSVs not from Writer menu, but e.g. from file browser. Current behavior is consistent with, say, what Word does. Opening a file depending on its extension is usually not done from another application's recent list or file open dialog. Again, file browser (or OS-provided recent files list) is used for such a task.
2.2. There is an "easy" way to customize behavior using extension provided in comment 18. (Only for those who reads this issue here.)
2.3. Current behavior allows to use command line's "--writer" together with the file name, to tell which module to use, and avoid specifying the exact filter name.

Personally I do not see a compelling reason for the change.

(In reply to Mike Kaganski from comment #25)
> FTR: the correct code pointer is not comment 1, but comment 4 (so it is
> PlainTextFilterDetect::detect which needs to be changed, it this request is
> implemented).

Sorry, a thinko while preparing the previous comment. Please ignore this part.

(In reply to Mike Kaganski from comment #25)
> (In reply to Turtle from comment #24)
> 
> Unfortunately, your post gives nothing new to the discussion already
> happened here. It is a common place that there's a RFC (which is, btw, just
> a memo to summarize some existing and most common elements of the huge
> variety of existing (and pre-existing) CSV flavors). It is known that some
> people open CSVs when already work with text files.
> 
> FTR: the correct code pointer is not comment 1, but comment 4 (so it is
> PlainTextFilterDetect::detect which needs to be changed, it this request is
> implemented).
> 
> Let me summarize the arguments.
> 
> 1. In favor of the change:
> 
> 1.1. CSV is a tabular format, and it is exceptionally rare to want to open
> it in Writer, in which case, there is a mechanism to explicitly choose the
> filter.
> 1.2. Opening it differently depending on the currently active document may
> be seen as unexpected and counter-intuitive- by people who are well-aware
> that LibreOffice is a monolithic application.
> 1.3. Writer is not a text editor anyway; so it not suited to edit plain text
> documents - if so wanted, users would use notepad/gedit for such a task.
> 1.4. The extensions like CSV, TSV, XLS (also often used in CSVs) is usually
> given explicitly to automatize opening in the spreadsheet application.
> 
> 2. In favor of the current behavior:
> 
> 2.1. Exactly contrary to 1.2, for people who are used to the concept that
> each module is "separate" (e.g., coming from MS Office), the behavior that
> when a file is opened using Writer menu, it would be opened in Calc, would
> be counter-intuitive; such people would rather open CSVs not from Writer
> menu, but e.g. from file browser. Current behavior is consistent with, say,
> what Word does. Opening a file depending on its extension is usually not
> done from another application's recent list or file open dialog. Again, file
> browser (or OS-provided recent files list) is used for such a task.
> 2.2. There is an "easy" way to customize behavior using extension provided
> in comment 18. (Only for those who reads this issue here.)
> 2.3. Current behavior allows to use command line's "--writer" together with
> the file name, to tell which module to use, and avoid specifying the exact
> filter name.
> 
> Personally I do not see a compelling reason for the change.

Thanks for the summary, I agree with all points other than 2.1. While I have been exclusively a openoffice then libreoffice user since 2002 (21 years) so I can't say I have any experience with Microsoft word, I did just now try to reproduce 2.1 by signing up for a free trial version of word and opening a CSV file it opens with excel. 
I would  also change 1.1 to
Opening a CSV into calc from writer would be part of a normal supported work flow. In the work flow scenario where a user opens writer and is typing a document such as a letter, it would be logical for a user to refer to a CSV spreadsheet, such as to copy and paste a few numbers from a downloaded data file, then close the csv and continue composing in writer. 
It makes no logical sense to open a CSV into writer and use it as a text editor and should not be a supported work flow, other than with an extension. 
Also add:
1.5 When in calc if one needs to open a .txt file and refer to it, the text file should be opened with writer. As text/plain is not a spreadsheet format.
Thanks again for your consideration.

Created attachment 190074 [details]
patch for 7.5.6.2

Patch for testing, opens .txt files from calc with writer. Opens CSV and TAB with calc always.

Created attachment 190079 [details]
Screen cast opening a CSV in MS Word 2016

(In reply to Turtle from comment #27)
> (In reply to Mike Kaganski from comment #25)

Please do not overquote. My post is completely available just above. Only quote what creates a specific context for the answer; or just mention that you answer some specific comment as a whole. Thanks.

> While I have
> been exclusively a openoffice then libreoffice user since 2002 (21 years) so
> I can't say I have any experience with Microsoft word, I did just now try to
> reproduce 2.1 by signing up for a free trial version of word and opening a
> CSV file it opens with excel. 

No, it definitely opens in Word. See the attachment.

Created attachment 190080 [details]
Opening a TXT in Excel

(In reply to Turtle from comment #27)
> Also add:
> 1.5 When in calc if one needs to open a .txt file and refer to it, the text
> file should be opened with writer. As text/plain is not a spreadsheet format.

Same with Excel: opening a TXT from it, opens it in Excel, not in Word. This is what my point 2.1 in about; and no matter how hard you try, *many* (most - given how many are used to MS Office) users are accustomed to *this* (already existing) behavior implemented in LibreOffice currently.

(In reply to Mike Kaganski from comment #30)
> Created attachment 190080 [details]
> Opening a TXT in Excel
> 
> (In reply to Turtle from comment #27)
> > Also add:
> > 1.5 When in calc if one needs to open a .txt file and refer to it, the text
> > file should be opened with writer. As text/plain is not a spreadsheet format.
> 
> Same with Excel: opening a TXT from it, opens it in Excel, not in Word. This
> is what my point 2.1 in about; and no matter how hard you try, *many* (most
> - given how many are used to MS Office) users are accustomed to *this*
> (already existing) behavior implemented in LibreOffice currently.

I can't reproduce this behavior.
what would be an example work flow where this would be useful?

Comment on attachment 190074 [details]
patch for 7.5.6.2

I have now tested the patch on linux and it works as expected.

Created attachment 190094 [details]
Screen cast opeing a csv from msword on mac

Created attachment 190095 [details]
Opening a CSV from open office writer on mac os

Created attachment 190096 [details]
Open a .txt from open office calc on a mac os.