Rule of thumb is to search before reporting for both open and closed bugs.

Hi Timur, it looks like you're using passive aggression in place of communication.  Stop doing that. If you have something to say, then say it.

This bug has been marked "NEEDINFO".  What info is needed?

If the information you're asking for is a link to other bugs where this bug has already been report, then, the information is this: 

This bug has not yet been reported.

(In reply to Drew Parsons from comment #2)
> Hi Timur, it looks like you're using passive aggression in place of
> communication.  Stop doing that. If you have something to say, then say it.
Funny, I'm not in to psychology, but I do check dozen of bugs daily, as a volunteer. In the whole worlds, nobody else took your bug, sooner and with better communication. Many times reporters break the 1st rule: search before report. So they shift burden from hundreds or thousands of themselves to a couple of volunteers checking bugs. Warning is appropriate. 

> This bug has been marked "NEEDINFO".  What info is needed?
See bug 34303, bug 129292, bug 129886. Is this there, a duplicate?

Bug #34303: addresses PDF file export, not file open. Some internal discussion in the bug about fileopen, but it's not what the bug resolves

Bug #129886: addresses File Save not File Open

Bug #129292: addresses Path set in Options vs "last-saved" directory, not "currently-opened directory.

Not a duplicate.

So this is something that would change the current behaviour of using the My Documents path from Tools - Options - Paths. Let's ask UX. At least I think that the current behaviour is intentional.

Created attachment 168001 [details]
Screenshot

(In reply to Drew Parsons from comment #0)
> the Open dialog does not show the working directory...

It does, at least if you run system dialogs (Tools > Options > General: [ ] Use LibreOffice dialogs - those are self-made and may have usability issues). But even then, the current folder is shown.

Likely I don't get the point of Tools > Options > Path and your request. Could you please help me?

Screenshot made on Linux Mint with 
Version: 6.4.6.2
Build ID: 1:6.4.6-0ubuntu0.20.04.1
CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Hi Heiko Tietze, I apologise, I was away from the computer in December and missed your query. 

The unexpected behaviour is still in place.  I'll prepare some screenshot of the dialog box to illustrate and explain what I'm experiencing.

Drew

Created attachment 172807 [details]
LO_from_window_manager.png

In this case LibreOffice was launched by clicking on a file in the File Browser (Nautilus on Gnome)

Thanks for your patience, Heiko.

I think I can now identify where the problem occurs: it's happening when LibreOffice is opened generally from the menu, rather than starting LibreOffice from the command line.

If I use a menu icon to launch LO, or if I click on a file in the file browser (Nautilus 3.38.2, on the Gnome window manager), then the directory of the selected file does NOT show in the File Open dialog.

I've created a test file, test1.odt, in a test directory ~/test.
When I click on test1.odt from Nautilus, LO launches with the file open.  Then when I click on File Open, it shows as in the attach file LO_from_window_manager.png . The local directory (~/test) is NOT shown in the File Open dialog box.

If instead I go to the ~/test directory in a terminal and launch LibreOffice from the command line with
   $ soffice
(even without specifying the file) and then select File Open, in this case the File Open dialog does show the test directory. Shown in attachment LO_from_command_line.png.

In both cases the default directory selected in the Open dialog is still some past working directory, which is also annoying but is a different problem.

Comment on attachment 172807 [details]
LO_from_window_manager.png

demonstrates missing local directory (LO launched from window manager), clicking on file in the File Browser (nautilus on Gnome)

Created attachment 172808 [details]
LO_from_command_line.png

Demonstrates LO launched from command line.  Local directory is shown.

It looks to me that the File Open dialog is showing the working directory, as set from the launch context of LibreOffice, irrespective of the files already opened.

This bug is requesting for the File Open dialog to show the context directory for the current file.

Seems to be not our bug. Caolan, your Gnome wisdom is needed... (in a nutshell: file open dialog show the local/current directory only if started per commandline; supposedly soffice instead of swriter)

It's a Debian Linux installation with libreoffice-writer 1:7.1.2~rc2-1

The executable is also accessible as lowriter (/usr/bin/lowriter), but that's just a wrapper script which calls the launch script /usr/lib/libreoffice/program/soffice

My understanding is that the "left-hand pane of available folders" belongs to the gtk file dialog and isn't under our control and it decides itself what to show.

It appears to list the cwd of the process there as shown in the picture in comment #13

This is also probably the case in the picture in comment #12 except in that case the cwd is presumably the $HOME dir which is already listed under "Home".

I expect the same is true when launched from ~/Documents or ~/Music that those dirs are not duplicated at the end of the list and only a cwd not already listed among the special locations is put at the end of the list in the left-hand pane.

So left-hand pane is presumably working as the authors of that intended and either way I don't think we can influence it.

The directory shown by the file open dialog, the one in the right pane, is probably set by us and is presumably simply just whatever directory the file open dialog was in the last time it was used.

I'm guessing the mismatch of expectations as to what's shown here is that if libreoffice is launched by something external to open a file and then file open is used that we show what was used by the file open dialog the last time it was used and that hasn't any connection to what file was actually "last opened in the office suite" as opposed to "last opened by our file dialog".

If that is the case, and is worth addressing, then changing whatever we are storing as the "last file open location" for the dialog to be updated to the "last file opened" (like the recently-used list shows) might be the way to go. Though perhaps opening remote file vs local files complicates that in practice as to whether the last open file location is suitable for use in the open file dialog)

Looks like the Gnome/gtk dialog might need to be given the context of the current LibreOffice document. The gtk API includes methods for manually adding these shortcuts if needed, such as https://developer.gnome.org/gtk3/stable/GtkFileChooser.html#gtk-file-chooser-add-shortcut-folder

They also have a gtk_file_chooser_add_shortcut_folder_uri() variant, which I imagine would take care of remote files.

Ultimately not an UX topic. Would be nice if we can solve it otherwise it's a topic for the Gnome people.

Caolán's suggestion does sound good to me, to replace "last file open location" for the dialog with the "last file opened".

That would deal well with my secondary complaint (why is an old, unrelated folder being shown?) as well as the primary complaint (why is the "current" folder not being shown?)

I can still reproduce this issue following the procedure in https://bugs.documentfoundation.org/show_bug.cgi?id=133783#c11

Starting LibreOffice from the command line, the File Open dialog does shows the local directory in 

Starting LibreOffice from an icon or a Nautilus file entry or from Application search results, the File Open dialog still does NOT show the local directory of the file which is currently open.

Here testing the debian build of LibreOffice 25.8.4.2
on Linux (6.18.3) with Gnome 49

(In reply to Drew Parsons from comment #26)
> the File Open dialog does shows the local directory...
Without reading the comments in detail again, this seems to be kind of a misunderstanding. The behavior is described in https://help.libreoffice.org/25.8/en-US/text/shared/guide/workfolder.html?&DbPAR=SHARED&System=MAC - you start from what is defined under Tools > Options > Path in both cases, Load and Save.

Do you ask for an option to not use the document folder but the path where you start Libreoffice from? Like /home/<user>/test/soffice => and you default all file operations to ~/test?

If so, I think this would be very unusual and contradicting the system-defined folder (which would make sense to use rather than self-defined).

Hi Heiko, the documentation you linked to,
"Changing Your Working Directory" https://help.libreoffice.org/25.8/en-US/text/shared/guide/workfolder.html
and also 
"Paths" at https://help.libreoffice.org/25.8/en-US/text/shared/optionen/01010300.html

they seem to be confusing the concepts of "working directory" and "default document directory".

The instructions written there explain how to change the default document directory ("My Documents").  And the File Open dialog does show that default document directory. That's not the problem.

Not every file that I'm working on is located in the "My Documents" directory. (To be honest, *none* of the documents I work on are located in "My Documents".  My work is organised hierarchically, using different subdirectories for different tasks).

Each file has its own working directory. In general they're not the same directory, and their various file-specific working directories are not the "My Documents" directory.

What I'm expecting, and not seeing, is that when accessing Open in the context of a currently open file, that the File Dialog window will show the working directory of that current file, as least as an alternative that can be selected. 

The use-case is for opening other files within the same project related to the currently open file, where all these files are collected together in the same working directory.

(In reply to Drew Parsons from comment #28)
> What I'm expecting, and not seeing, is that when accessing Open in the
> context of a currently open file, that the File Dialog window will show the
> working directory of that current file, as least as an alternative that can
> be selected. 
And there are plenty of other workflows where a "current folder" is not valid. What if you have documents from two projects open at the same time? 

However, there is the idea of a session in bug 117237, some kind of "master file" that bundles documents from different modules, makes quick access easy, and could also set the project path instead of the application default. How about that?

(In reply to Heiko Tietze from comment #29)
> (In reply to Drew Parsons from comment #28)
> > What I'm expecting, and not seeing, is that when accessing Open in the
> > context of a currently open file, that the File Dialog window will show the
> > working directory of that current file, as least as an alternative that can
> > be selected. 
> And there are plenty of other workflows where a "current folder" is not
> valid. What if you have documents from two projects open at the same time? 

The working directory should be the directory of the current document. Only one of them has focus at one time.

> However, there is the idea of a session in bug 117237, some kind of "master
> file" that bundles documents from different modules, makes quick access
> easy, and could also set the project path instead of the application
> default. How about that?

To me that sounds way more complicated then simply having the working directory determined by the current document that has focus.

(In reply to Drew Parsons from comment #30)
> The working directory should be the directory of the current document. Only
> one of them has focus at one time.
+1

As a practical consequence, one could have, for example, open documents from three different projects (each project with its own folder). With the proposed behavior, one could open a desired (project) folder by having focus on any open document from that folder, in contrast to current behavior, which is to display the last directory used in the Open or Save dialog.

(While it is not clear how to specify the directory for "saving" a new document , the proposed enhancement  would make it much easier to get the right (desired) directory opened, when documents have been opened from several different folders.)