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.
Also, still using the KDE5 (Plasma) desktop if I restart LO with SAL_USE_VCLPLUGIN=GTK ./soffice the problem goes away.
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
@bubli: thoughts ?
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.
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.
Yep this is annoying
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
(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.
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.
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?
> 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)
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.
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.