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?)