rhbz#915743: Avoid potentially blocking autocompletion for non file URLs

In theory, the logic of how SvtMatchContext_Impl threads are used to obtain
autocompletion information could probably be improved so that long-latency
scenarios would only block the ultimate closing of the dialog, if anything at
all.  In practice, this is probably not worth it, as users likely do not expect
an autocompletion feature for remote content, anyway.  (And previous commits
like 260afe56fd6b2f34de8290f3cdb7d1df5b88f8a8 "neon commands cannot be aborted"
make it questionable whether any remaining blocking upon closing of the dialog
could be bounded in a reasonable manner.)

Change-Id: Ie82b9a70285b30fe88cf4c40992710087e86815e

1 files changed, 8 insertions, 1 deletions

diff --git a/svtools/source/control/inettbc.cxx b/svtools/source/control/inettbc.cxx
index 374fa7dd3ab0..01e6d3d8701e 100644
--- a/svtools/source/control/inettbc.cxx
+++ b/svtools/source/control/inettbc.cxx
@@ -610,7 +610,14 @@ void SvtMatchContext_Impl::doExecute()
             {
                 INetURLObject aURLObject( aMatch );
                 String aMainURL( aURLObject.GetMainURL( INetURLObject::NO_DECODE ) );
-                if ( aMainURL.Len() )
+                // Disable autocompletion for anything but the (local) file
+                // system (for which access is hopefully fast), as the logic of
+                // how SvtMatchContext_Impl is used requires this code to run to
+                // completion before further user input is processed, and even
+                // SvtMatchContext_Impl::Stop does not guarantee a speedy
+                // return:
+                if ( aMainURL.Len()
+                     && aURLObject.GetProtocol() == INET_PROT_FILE )
                 {
                     // if text input is a directory, it must be part of the match list! Until then it is scanned
                     bool folder = false;