Description: Using tab and the caret, it becomes very complex to save a file at an appropriate place Steps to Reproduce: 1. Press ctrl-s in a new document 2. Try to save a file entering his name 3. Try to locate it Actual Results: 1st, the fact your caret goes to the location instead of the filename is not conventional. Second, after entering the location, finding the name edit box is a pain. Next, entering the name is not easy only via keyboard, as it scrolls the history, etc. Finally, for some reasons, it happens sometimes that the location comes back to the origin. Expected Results: As a typical GTK box: the caret goes in the filename, then shift-tab or tab enables to choose the other settings. In the filename, we can enter the full path. Stable Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 6.4.0.3 Build ID: 1:6.4.0-1 Threads CPU : 4; OS : Linux 5.4; UI Render : par défaut; VCL: gtk3; Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded Cette version est fournie par The Document Foundation/Debian.
I have the standard dialog when pressing Ctrl+s. Version : 6.4.2.0.0+ Build ID : c1a79354e6ae96a287095abcfc53f41aa2d43358 Threads CPU : 12; OS : Linux 4.19; UI Render : par défaut; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-6-4, Time: 2020-02-06_17:23:05 Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded Also tested on: Version : 7.0.0.0.alpha0+ Build ID : 25649502e08a52087dea5e482d34a1d4150f0930 Threads CPU : 12; OS : Linux 4.19; UI Render : par défaut; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-02-05_14:59:38 Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded
Hi, Thanks Patrick for your feedback. I fixed the thing: 1. Open LO 4.2 2. Uncheck the box "ust the LO open and dave dialogs" 3. Save, exit and open a newer Libreoffice I think the upgrade process should, somewhere, uncheck this box: so far it disappears from the interface but its status is maintained, hence a confusion in the configuration. regards
> I think the upgrade process should, somewhere, uncheck this box: so far it > disappears from the interface [...] ?? It's still there in the interface.
The same problem in a different context: I have a folder with 2 .odt files, ꞌdoc1ꞌ and ꞌdoc2ꞌ and a master document ꞌmasterꞌ. If I select ꞌExport...ꞌ in the master document, the dialog opens with ꞌmasterꞌ in the field ꞌFile nameꞌ. File format is ODF Text Document. But the focus is on ꞌdoc1ꞌ. If I click on ꞌExportꞌ button, I get the message: ″A file named doc1 already exists. Do You want to replace it?″ The first time I confirmed without reading the message and doc1 was overwritten. This behavior is new in version 6.4 Found in Version: 6.4.0.3 with Windows 10 64 bit
I can confirm this. The caret should default to the filename entry location instead of the directory location. This is also an issue in the file export window. Enabling/Disabling the LO dialog setting did not affect it for me. This is a rather annoying regression in 6.4.
*** Bug 131863 has been marked as a duplicate of this bug. ***
*** Bug 132107 has been marked as a duplicate of this bug. ***
*** Bug 131794 has been marked as a duplicate of this bug. ***
1st entry in dialog is marked and selected (for save as, PDF export etc.), regardless of what's in the filename. In LibreOffice dialog. Also in Windows.
When using LibreOffice dialog, 1st entry in dialog is marked and selected (for save as, PDF export etc.), regardless of what's written in the filename. That can lead to file overwrite and loss, as explained in duplicates. Started as Linux but also reproduced in Windows.
(In reply to Timur from comment #6) > *** Bug 131863 has been marked as a duplicate of this bug. *** I disagree! The bug discribes what it LO shows as filename. This should result in an own testcase.
(In reply to Timur from comment #7) > *** Bug 132107 has been marked as a duplicate of this bug. *** I disagree! The bug discribes a difference between the filename in the dialog and the used one. This should result in an own testcase. For security reasons this bug should be classified very high!
Bibisected with linux64-6.4 to https://git.libreoffice.org/core/+/09e3d45cdc5c739e5246388a83ccfc6d76bf66e9%5E!/ weld fpicker cluster Adding Cc: to Caolán McNamara This was at first confusing because the option to choose the LibO Open/Save dialogs in Options - General was not visible in the earliest commit of the 6.4 repo.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/23ddc3811d4d1890e4024f4e0f6bb5129a694fdc Resolves: tdf#130505 give default focus to the file name field It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
default focus is in the file name field now in master, backport to 6-4 in gerrit so I'll call it fixed. Odd to see see continued use of this dialog when its defaulted off in favour of a system file dialog on all major desktops.
Verified, thanks! Arch Linux 64-bit Version: 7.0.0.0.alpha0+ Build ID: 23ddc3811d4d1890e4024f4e0f6bb5129a694fdc CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 30 April 2020
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fae06bab169605f057601d0a5b719387cf188105 Related: tdf#130505 strangely all these point to the same pair of widgets It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Buovjaga, did you verify also duplicates or some need to be reopen?
> Buovjaga, did you verify also duplicates or some need to be reopen? No, I hope the reporters can test with a build newer than 30th April and change the status of their reports, if needed. https://dev-builds.libreoffice.org/daily/master/current.html
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/b065d68266a8b897bc2dab26135577d1d0e9a7ff Resolves: tdf#130505 give default focus to the file name field It will be available in 6.4.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Duplicates look ok to me. Caolán, bug 131898 is not bibisected, but looks related, please take a look.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-4-4": https://git.libreoffice.org/core/commit/60992be6508607ddd8103d9f016303a7a92d3363 Resolves: tdf#130505 give default focus to the file name field It will be available in 6.4.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 132826 has been marked as a duplicate of this bug. ***