ucbGet needs a non-null interaction handler after all

In db6c7a486395304f38e9ea52951f576f34749cbc "Use UCB instead of cURL to download
https files", I had not further investigated why using the (GUI) interaction
handler within utl::UcbStreamHelper::CreateStream would lead to deadlock during
UITest_sw_options
(UITEST_TEST_NAME=optionsDialog.optionsDialog.test_moreIconsDialog).  Instead,
I had passed a null XInteractionHandler into utl::UcbStreamHelper::CreateStream,
assuming that would solve whatever the issue was (and it did make the UITest
pass).

However, that caused the AdditionsDialog to not be populated at all,
with

> warn:cui.dialogs:26878:26950:cui/source/dialogs/AdditionsDialog.cxx:95: Reading <https://yusufketen.com/api/Templates.json> failed with 0x20d(Error Area:Io Class:General Code:13)

(see comment at <https://bugs.documentfoundation.org/show_bug.cgi?id=137922#c1>
"Extensions button in Template choose does not show anything"), because
interaction requests like com.sun.star.ucb.CertificateValidationRequest were not
handled properly.

As it turns out, the real reason for the deadlock was that the UITest quickly
closes the dialog, causing the main thread to block at

  m_pSearchThread->join();

in ~AdditionsDialog waiting for the SearchAndParseThread to finish, while
SearchAndParseThread::execute encountered a CertificateValidationRequest that
needs to be handled and thus blocks in UUIInteractionHelper::handleRequest
(uui/source/iahndl.cxx) waiting for the main thread to process the
PostUserEvent.

In an ideal world, the UCB would allow to cancel the download request issued
from ucbGet while that download is waiting for the CertificateValidationRequest
to be handled, and the AdditionsDialog CloseButtonHdl would initiate such
cancellation.  Lacking that, just keep the Close button disabled until the
SearchAndParseThread has finished downloading.  (Pressing the Close button
earlier, ~AdditionsDialog would have blocked the main thread anyway until
SearchAndParseThread had finished downloading, so this should not actually
worsen the user experience.  And the UITest now blocks waiting for the Close
button to become enabled before pressing it; there would already be
UITest.wait_until_property_is_updated available, but it has a hard-coded timeout
which might or might not be relevant in existing uses of that function, so leave
it alone and repeat the relevant code without an unhelpful timeout here.)

This means that the additional utl::UcbStreamHelper::CreateStream overload
introduced in db6c7a486395304f38e9ea52951f576f34749cbc "Use UCB instead of cURL
to download https files" is not necessary after all, so remove it again.

Two further items that should be looked into:
* Should ucbGet pass the AdditionsDialog into utl::UcbStreamHelper::CreateStream
  as css::uno::Reference<css::awt::XWindow> xParentWin argument (which defaults
  to null)?
* There might be similar deadlock issues involving ucbDownload, which can also
  be called (indirectly) from SearchAndParseThread::execute.

Change-Id: I8d549066940fa4f259a814a31ec7c62960e0db8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105169
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins

1 files changed, 4 insertions, 2 deletions

diff --git a/cui/source/dialogs/AdditionsDialog.cxx b/cui/source/dialogs/AdditionsDialog.cxx
index 45a2ffadd72b..ab91e47cd21b 100644
--- a/cui/source/dialogs/AdditionsDialog.cxx
+++ b/cui/source/dialogs/AdditionsDialog.cxx
@@ -70,8 +70,7 @@ std::string ucbGet(const OUString& rURL)
 {
     try
     {
-        auto const s = utl::UcbStreamHelper::CreateStream(
-            rURL, StreamMode::STD_READ, css::uno::Reference<css::task::XInteractionHandler>());
+        auto const s = utl::UcbStreamHelper::CreateStream(rURL, StreamMode::STD_READ);
         if (!s)
         {
             SAL_WARN("cui.dialogs", "CreateStream <" << rURL << "> failed");
@@ -522,7 +521,10 @@ AdditionsDialog::getInstalledExtensions()
 void AdditionsDialog::SetProgress(const OUString& rProgress)
 {
     if (rProgress.isEmpty())
+    {
         m_xLabelProgress->hide();
+        m_xButtonClose->set_sensitive(true);
+    }
     else
     {
         SolarMutexGuard aGuard;