Download it now!
Bug 125267 - KDE5: Base 'Database Wizard' open existing database_file fails
Summary: KDE5: Base 'Database Wizard' open existing database_file fails
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.3.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Katarina Behrens (Inactive)
URL:
Whiteboard: target:6.3.0 target:6.2.5
Keywords: wantBacktrace
Depends on:
Blocks: KDE
  Show dependency treegraph
 
Reported: 2019-05-13 16:46 UTC by Drew Jensen
Modified: 2019-05-17 22:27 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Drew Jensen 2019-05-13 16:46:51 UTC
Test system Ubuntu 18.04.1 (AMD 64), LO Version: 6.3.0.0.alpha0+
Build ID: 98630a0bd49bd80652145a21e4e0d0ded792b36b
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: kde5; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-04_04:44:35


To reproduce:

1 - From the Start Center click the button 'Base Database' to start the Database Wizard.

2 - Select 'Open an existing datebase file'

3 - click the 'Open' button.

4 - Select any .odb from the open file dialog and click on 'Open'

Expected result: the file opens.

Actual result: An information dialog opens with "Please choose 'Connect to an existing database' to connect to an existing database instead."

5 - close the information dialog

Look at the Wizard dialog now - the option 'Connect to an existing database' is now selected.
Comment 1 Drew Jensen 2019-05-13 16:50:11 UTC
Also, still using the KDE5 (Plasma) desktop if I restart LO with
SAL_USE_VCLPLUGIN=GTK ./soffice the problem goes away.
Comment 2 Julien Nabet 2019-05-13 19:41:48 UTC
Just for the record, on pc Debian x86-64 with master sources updated today, I don't reproduce this.

I tried with:
- SAL_USE_VCLPLUGIN=kde5 only
- SAL_USE_VCLPLUGIN=kde5 + QT_QPA_PLATFORM=wayland
Comment 3 Alex Thurgood 2019-05-14 06:33:29 UTC
@bubli: thoughts ?
Comment 4 Vera Blagoveschenskaya 2019-05-14 08:27:03 UTC
I tried the latest available build

Version: 6.3.0.0.alpha0+
Build ID: 98630a0bd49bd80652145a21e4e0d0ded792b36b
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kde5; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-04_04:44:35
Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US
Calc: threaded

The behavior from Comment#0 is reproduced.
Comment 5 Julien Nabet 2019-05-14 08:38:21 UTC
Michael: thought you might be interested in this one.
I don't understand why I can't reproduce this with vars I defined.
Is there another var I don't know and that should be defined?

If someone may provide a stacktrace (if possible with symbols included), it may help.
Comment 6 Katarina Behrens (Inactive) 2019-05-14 08:41:09 UTC
Yep this is annoying
Comment 7 Katarina Behrens (Inactive) 2019-05-15 17:51:52 UTC
This is a tough bug

In filepicker opened in this scenario, there are two file filters that match .odb extension -- "Database Documents" and "ODF Database", with "ODF Database" filter pre-selected. 

Now if the user changes nothing, every other filepicker when asked "what is currently selected file filter?" returns "ODF Database". Plasma filepicker returns "Database Documents" (it's almost as if it's returning the first filter that matches the extension of the selected file -- .odb in this case). IDK why is this happening and it looks like KIO bug but whatever, it means I can do only very little to fix it. 

BUT 
you can replicate the SAME BUGGY BEHAVIOUR with any other filepicker on any platform. It is enough to change file filter to anything else than "ODF Database". For example "All Files" (valid use-case, right?) and boom, the annoying 'Please connect to an existing database' dialog appears

Therefore I suggest to fix this in Base instead. Relax the requirement and not care about selected file filter (as it's happening atm), but only check whether selected file has the right extension *.odb
Comment 8 Michael Weghorn 2019-05-15 19:00:19 UTC
(In reply to Katarina Behrens (CIB) from comment #7)
> Now if the user changes nothing, every other filepicker when asked "what is
> currently selected file filter?" returns "ODF Database". Plasma filepicker
> returns "Database Documents" (it's almost as if it's returning the first
> filter that matches the extension of the selected file -- .odb in this
> case). IDK why is this happening and it looks like KIO bug but whatever, it
> means I can do only very little to fix it. 

This sounds like bug 120950, which I had a look at a while ago and my conclusion was also that this is a kio/plasma-integration bug.
Comment 9 Drew Jensen 2019-05-15 19:06:59 UTC
That is interesting and perhaps has something to do here, but there is also this open issue https://bugs.documentfoundation.org/show_bug.cgi?id=124951 about the dialog box not functioning properly and given that, at least here, when the error happens there is a change in which option button is selected I would not be surprised if this is more specific to the code behind the dialog.
Comment 10 Julien Nabet 2019-05-15 19:08:22 UTC
Katarina: Following your advice, I gave it a try and indeed I could reproduce this with my default rendering gtk3 + changing filter to all files.

The related code is there:
711 OUString sPath = aFileDlg.GetPath();
712 if ( aFileDlg.GetCurrentFilter() != pFilter->GetUIName() || !pFilter->GetWildcard().Matches(sPath) )
713 {
714     OUString sMessage(DBA_RES(STR_ERR_USE_CONNECT_TO));
715     std::unique_ptr<weld::MessageDialog> xInfoBox(Application::CreateMessageDialog(GetFrameWeld(),
716      VclMessageType::Info, VclButtonsType::Ok,
717               sMessage));
See https://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/dlg/generalpage.cxx?r=1e268223#712


I added some debug traces:
- when it's ok, I got:
sPath=file:///tmp/test.odb
aFileDlg.GetCurrentFilter()=ODF Database (*.odb)
pFilter->GetUIName() =ODF Database

- when it's ko, I got:
sPath=file:///tmp/test.odb
aFileDlg.GetCurrentFilter()=ODF Database (*.odb)
pFilter->GetUIName() =ODF Database

So with this patch:
diff --git a/dbaccess/source/ui/dlg/generalpage.cxx b/dbaccess/source/ui/dlg/generalpage.cxx
index 829333294d05..33db50950aeb 100644
--- a/dbaccess/source/ui/dlg/generalpage.cxx
+++ b/dbaccess/source/ui/dlg/generalpage.cxx
@@ -709,7 +709,7 @@ namespace dbaui
         if ( aFileDlg.Execute() == ERRCODE_NONE )
         {
             OUString sPath = aFileDlg.GetPath();
-            if ( aFileDlg.GetCurrentFilter() != pFilter->GetUIName() || !pFilter->GetWildcard().Matches(sPath) )
+            if ( !pFilter->GetWildcard().Matches(sPath) )
             {
                 OUString sMessage(DBA_RES(STR_ERR_USE_CONNECT_TO));
                 std::unique_ptr<weld::MessageDialog> xInfoBox(Application::CreateMessageDialog(GetFrameWeld(),

I don't reproduce this.
Is it what you have in mind?
If yes, do you think about wrong side-effect or it should be ok in every situation?
Comment 11 Katarina Behrens (Inactive) 2019-05-15 21:16:47 UTC
> So with this patch:
> diff --git a/dbaccess/source/ui/dlg/generalpage.cxx
> b/dbaccess/source/ui/dlg/generalpage.cxx
> index 829333294d05..33db50950aeb 100644
> --- a/dbaccess/source/ui/dlg/generalpage.cxx
> +++ b/dbaccess/source/ui/dlg/generalpage.cxx
> @@ -709,7 +709,7 @@ namespace dbaui
>          if ( aFileDlg.Execute() == ERRCODE_NONE )
>          {
>              OUString sPath = aFileDlg.GetPath();
> -            if ( aFileDlg.GetCurrentFilter() != pFilter->GetUIName() ||
> !pFilter->GetWildcard().Matches(sPath) )
> +            if ( !pFilter->GetWildcard().Matches(sPath) )
>              {
>                  OUString sMessage(DBA_RES(STR_ERR_USE_CONNECT_TO));
>                  std::unique_ptr<weld::MessageDialog>
> xInfoBox(Application::CreateMessageDialog(GetFrameWeld(),
> 
> I don't reproduce this.
> Is it what you have in mind?
> If yes, do you think about wrong side-effect or it should be ok in every
> situation?

Yep this is exactly what I did here: https://gerrit.libreoffice.org/#/c/72377/
I consider it safe enough for all applicable use-cases, the important bit here is the path to database file and not how the user got to it (which filter they've selected)
Comment 12 Commit Notification 2019-05-17 08:52:36 UTC
Katarina Behrens committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/dc17f247daeb281dda531ff335873d563db5b653%5E%21

tdf#125267: relax the requirement of fixed value of current filter

It will be available in 6.3.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.
Comment 13 Commit Notification 2019-05-17 22:27:13 UTC
Katarina Behrens committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/21e1aa9d6b13b39b87435f8998c7ea6123a069fd%5E%21

tdf#125267: relax the requirement of fixed value of current filter

It will be available in 6.2.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.