1. 03 Haz, 2019 1 kayıt (commit)
  2. 21 May, 2019 1 kayıt (commit)
  3. 09 May, 2019 2 kayıt (commit)
    • Stephan Bergmann's avatar
      tdf#124962: Reduce risk of g_main_loop_run from within gio MountOperation · 8a443fe0
      Stephan Bergmann yazdı
      Using g_main_loop_run here appears to be inherently necessary for the
      g_file_mount_enclosing_volume/g_file_mount_enclosing_volume_finish protocol, but
      has at least two problems:  For one, it temporarily drops the SolarMutex (if it
      was held by the current thread), causing the usual integrity issues caused by an
      inner stack frame temporarily releasing the SolarMutex that is held by some
      unsuspecting caller.  This is an inherent problem of our broken SolarMutex
      design, and this change can't do much about it.
      
      But for another, at least with GTK-based VCL backends, it also means that the
      current thread can start to execute VCL events at "unexpected" times from within
      this g_main_loop_run (e.g., paint events, as in the backtraces linked from
      tdf#124962).  While handling of VCL events is necessary when a callback to
      ooo_mount_operation_ask_password happens and it actually pops up a dialog
      prompting the user for credentials, such handling of VCL events is completely
      unwanted when no such dialog is popped up (e.g., when the given server is
      unreachable anyway, as is the case in tdf#124962).
      
      So, to shrink the problematic window of time in which VCL events may get handled
      from within the gio MountOperation, use a dedicated GMainContext for the gio
      GMainLoop (so that it only handles events related to the mount operation), and
      only temporarily put back in place the original GMainContext during
      ooo_mount_operation_ask_password (so that VCL events will get handled as
      necessary when a dialog is actually popped up).
      
      Change-Id: Ie410f23778045b1adf98579bb34ce38d0f8f3320
      Reviewed-on: https://gerrit.libreoffice.org/72026
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      8a443fe0
    • Stephan Bergmann's avatar
      Remove unhelpful "using namespace com::sun::star;" from ucb/source/ucp/gio/ · d36331d6
      Stephan Bergmann yazdı
      ...in preparation for another change using a top-level namespace ucb
      
      Change-Id: I3a92d64806bc570bdfd4fe06e672cb6ce2049e7e
      Reviewed-on: https://gerrit.libreoffice.org/71987
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      d36331d6
  4. 02 May, 2019 1 kayıt (commit)
  5. 29 Nis, 2019 1 kayıt (commit)
    • Stephan Bergmann's avatar
      tdf#123472: Propagate getGFileInfo failure less aggressively · 6d3dd643
      Stephan Bergmann yazdı
      ...from Content::getPropertyValues.  ca030879
      "tdf#121337: Fail on GIO error in GIO UCP getPropertyValue" had made
      Content::getPropertyValues fail for every getGFileInfo failure.  However, when
      saving to a not-yet exisiting file, SfxMedium::Transfer_Impl
      (sfx2/source/doc/docfile.cxx) requests the properties "Title" and "ObjectId"
      from the Content representing the not-yet existing file, and apparently expects
      those requests not to fail.  So restructure Content::getPropertyValues to only
      call getGFileInfo when actually needed (that covers not failing for the unknown-
      anyway "ObjecdtId" property), and handle "Title" specially by not failing for
      a non-existing file.  (The documentation at offapi/com/sun/star/ucb/Content.idl
      says for the "getPropertyValues" command that: "The execution will not be
      aborted, if there are properties requested, that are unknown to the content."
      But that leaves it somewhat unclear whether failure to obtain a known property
      should be propagated.  It apparently should be in the context of tfd#121337
      fixed previously, but apparently not for "Title" here.)
      
      Change-Id: I12a9a5bd93d661922ea3b7b19a84a7e73e7e4b50
      Reviewed-on: https://gerrit.libreoffice.org/71515
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      6d3dd643
  6. 23 Nis, 2019 1 kayıt (commit)
  7. 19 Nis, 2019 1 kayıt (commit)
  8. 15 Nis, 2019 2 kayıt (commit)
  9. 08 Nis, 2019 1 kayıt (commit)
  10. 07 Nis, 2019 1 kayıt (commit)
  11. 03 Nis, 2019 2 kayıt (commit)
  12. 31 Mar, 2019 1 kayıt (commit)
  13. 17 Mar, 2019 1 kayıt (commit)
  14. 07 Mar, 2019 1 kayıt (commit)
  15. 28 Şub, 2019 1 kayıt (commit)
  16. 27 Şub, 2019 1 kayıt (commit)
  17. 22 Şub, 2019 1 kayıt (commit)
  18. 20 Şub, 2019 1 kayıt (commit)
    • Michael Stahl's avatar
      tdf#123293 sfx2: fix metadata loss when loading from stream · 0a5ca576
      Michael Stahl yazdı
      The problem is that when loading from a stream, there is no BaseURL and
      also no storage for the document.
      
      Due to the lack of BaseURL, the sfx2::createBaseURI() throws and loading
      RDF metadata fails, which also pops up an annoying warning dialog.
      
      Try to handle this in a similar way than a newly created document (see
      GetDMA()), by using the vnd.sun.star.tdoc scheme URL for the document;
      this however currently requires that the document has a XStorage, which
      is also not the case here.
      
      So add another UNO method to tdoc UCP's tdoc_ucp::ContentProvider,
      to split out the creation of the tdoc schema URL from the creation of
      the ucb Content, to get rid of the XStorage requirement.
      
      Change-Id: Ica62743f9d21db0b1464b70db1a62ebc61989ef8
      Reviewed-on: https://gerrit.libreoffice.org/67882
      Tested-by: Jenkins
      Reviewed-by: 's avatarSamuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
      0a5ca576
  19. 12 Şub, 2019 1 kayıt (commit)
  20. 11 Şub, 2019 2 kayıt (commit)
  21. 08 Şub, 2019 1 kayıt (commit)
  22. 05 Şub, 2019 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Move dubious file: -> smb: conversion from INetURLObject to file UCP · 46c645bf
      Stephan Bergmann yazdı
      The Linux-only conversion of file URLs with a non-empty (other than "localhost")
      authority to smb URLs had been added in 2010 with
      0b9ef81b "tools-urlobj-smb-scheme-patch.diff:
      migrated" (applying a Go-oo patch?) but giving no rationale beyond "process
      relative SMB paths (in hyperlinks) correctly".  That makes it hard to tell
      whether that patch is (still) actively useful for anything, or was just a
      misguided hack from the beginning:
      
      * Why make this Linux only?  What about other non-Windows OSs?  (On Windows,
        such URLs can be resolved as UNC pathnames.)  If the reason for Linux-only was
        that it is the only OS where LO can handle smb URLs via GIO, why not make it
        conditional on ENABLE_GIO?
      
      * Why map to smb?  There are various remote file access protocols.  Hardcoding
        smb looks arbitrary here.
      
      Anyway, INetURLObject is arguably at a wrong level for such a patch.  To not
      drop the hack wholesale, reimplement it in the file UCP, forwarding to a
      potential other UCP that can handle smb URLs any file://<host>/... URLs
      (rewritten as smb URLs) that the file UCP cannot handle itself.
      (file://localhost/... URLs will already have been normalized to file:///... by
      INetURLObject when they reach the file UCP, and even if they were not, the
      osl/file.hxx functionality underlying fileaccess::TaskManager::getUnqFromUrl
      knows how to handle them, so they will not take the forward-to-smb code branch.)
      
      (The corresponding #ifdef WIN code from 0b9ef81b
      has already been removed with 82034b04
      "tdf#119326 crash when adding "Windows Share" File resource".)
      
      (I came across that 2010 patch while looking into
      <https://bugs.documentfoundation.org/show_bug.cgi?id=107461> "Does not support
      'file://' scheme with actual hostname".  A next step would be to make the file
      UCP actually handle any file://<host>/... URLs that denote the local host.)
      
      Change-Id: I77242705dc4c6c1e9cb3a4f32253224ac6cb13cb
      Reviewed-on: https://gerrit.libreoffice.org/67372
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      46c645bf
  23. 02 Şub, 2019 1 kayıt (commit)
  24. 24 Ock, 2019 1 kayıt (commit)
  25. 23 Ock, 2019 1 kayıt (commit)
    • Stephan Bergmann's avatar
      rhbz#1667364 Open doc as R/O for which open(...,O_RDWR) returns EOPNOTSUPP · bcb1969f
      Stephan Bergmann yazdı
      Map that EOPNOTSUPP to osl_File_E_NOSYS (and intercept it in
      StillReadWriteInteraction, as used by MediaDescriptor::impl_openStreamWithURL in
      unotools/source/misc/mediadescriptor.cxx, which will retry opening it read-only
      then), instead of to osl_File_E_invalidError (which lead to the "General
      input/output error" box).
      
      Instead of "silently" opening the doc as read-only, this still pops up a box
      claiming that the doc is locked by somebody else, asking whether to open it
      read-only or to open a copy.  That's probably because of the
      
        rDescriptor.erase( utl::MediaDescriptor::PROP_READONLY() );
      
      in TypeDetection::impl_openStream (filter/source/config/cache/typedetection.cxx)
      where the comment already hints at the confusion among the different read-only
      and locking concepts.  Changing that looks like it would easily cause
      regressions, so is left for a follow-up commit.  (And ultimately LO wouldn't
      need to treat the doc as read-only at all; it would just need to not attempt to
      open it O_RDWR upfront, and save it via copy+rename, like other apps appear to
      commonly do.)
      
      Change-Id: I56e18f1864084ba222acaf0e38a604082edaf4c6
      Reviewed-on: https://gerrit.libreoffice.org/66805
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      bcb1969f
  26. 15 Ock, 2019 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Upgrade external/boost to Boost 1.69.0 · 23a8d5ff
      Stephan Bergmann yazdı
      <https://dev-www.libreoffice.org/src/boost_1_69_0.tar.bz2> is a copy of
      <https://dl.bintray.com/boostorg/release/1.69.0/source/boost_1_69_0.tar.bz2>,
      SHA256 hash as given at <https://www.boost.org/users/download/>.
      
      * removed from external/boost/include/boost/ those files that are no longer
        present in workdir/UnpackedTarball/boost/boost/
      
      * the shrunk external/boost/rtti.patch.0 can probably be removed completely in a
        follow-up commit
      
      * the patch to libs/filesystem/src/operations.cpp in
        external/boost/boost-android-unified.patch.1 no longer applied, and appears to
        be no longer necessary anyway (seeing a working build without it of
        --with-distro=LibreOfficeAndroid and NDK r16b); but with the non-standard
        Clang 5.0.300080 from NDK r16b, the build now caused failures like
      
      > workdir/UnpackedTarball/boost/boost/type_traits/detail/is_function_cxx_11.hpp:36:11: error: class template partial specialization contains a template parameter that cannot be deduced; this partial specialization will never be used [-Wunusable-partial-specialization]
      >    struct is_function<Ret BOOST_TT_DEF_CALL(Args...)BOOST_TT_NOEXCEPT_DECL> : public true_type {};
      >           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      > workdir/UnpackedTarball/boost/boost/type_traits/detail/is_function_cxx_11.hpp:35:38: note: non-deducible template parameter 'NE'
      >    template <class Ret, class...Args BOOST_TT_NOEXCEPT_PARAM>
      >                                      ^
      > workdir/UnpackedTarball/boost/boost/type_traits/detail/is_function_cxx_11.hpp:22:40: note: expanded from macro 'BOOST_TT_NOEXCEPT_PARAM'
      > #define BOOST_TT_NOEXCEPT_PARAM , bool NE
      >                                        ^
      
        showing that that version of Clang has the same problem handling noexcept(b)
        as a deduced template parameter as MSVC has, as already supported by the code
      
      * new external/boost/sse.patch.0 needed on Windows x86 to silence errors like
      
      > C:\cygwin\home\tdf\lode\jenkins\workspace\gerrit_windows\workdir\UnpackedTarball\boost\boost/type_traits/detail/is_function_cxx_11.hpp(111): error C2215: '__vectorcall' cannot be used with '/arch:SSE'
      
        (<https://ci.libreoffice.org/job/gerrit_windows/26117/>); according to
        <https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros
        ?view=vs-2017>: "_M_IX86_FP Defined as an integer literal value that indicates
        the /arch compiler option that was set, or the default. This macro is always
        defined when the compilation target is an x86 processor. Otherwise, undefined.
        When defined, the value is: [...] 1 if the /arch:SSE compiler option was set."
        and we specify /arch:SSE explicitly for Windows x86 since
        8bd6bf93 "fdo#82430: configure: MSVC build:
        avoid using SSE2 instructions"
      
      * boost::logic::tribool conversion operator to bool is explicit now
      
      Change-Id: Iea49560d734f545539f062dce46740fbf812dd84
      Reviewed-on: https://gerrit.libreoffice.org/66189Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      Tested-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      23a8d5ff
  27. 11 Ock, 2019 1 kayıt (commit)
  28. 08 Ock, 2019 2 kayıt (commit)
    • Noel Grandin's avatar
      convert "*xxx.get()" to "*xxx" · 17dd2662
      Noel Grandin yazdı
      Change-Id: Ic307226591ff9702957ccdec486ccf70357eb6d9
      Reviewed-on: https://gerrit.libreoffice.org/65951
      Tested-by: Jenkins
      Reviewed-by: 's avatarNoel Grandin <noel.grandin@collabora.co.uk>
      17dd2662
    • Mike Kaganski's avatar
      Don't crash when accessing WebDAV resource after auth failed · 162a472d
      Mike Kaganski yazdı
      In my testing on Windows, the crashing scenario was this:
      1. FileDialogHelper_Impl::updateVersions() creates storage calling
         comphelper::OStorageHelper::GetStorageFromURL;
      2. Content::openStream() calls isDocument first;
      3. Content::isDocument() indirectly initiates WebDAV session,
         creating a NeonSession;
      4. All operations of NeonSession call Init() first; its first call
         initializes m_pHttpSession using ne_session_create, and then
         adds auth callbacks using ne_add_server_auth/ne_add_proxy_auth
      5. Then NeonSession performs the rest of PROPFIND task, calling
         ah_post_send and auth_challenge; the latter fails, then
         ah_post_send calls clean_session, which cleans m_pHttpSession's
         auth_session's sspi_host;
      6. NeonSession::HandleError throws DAVException for NE_AUTH error;
      7. Content::isDocument() returns true to Content::openStream(),
         which proceeds to execute the command, which in turn re-uses
         the NeonSession and its m_pHttpSession;
      8. NeonSession::OPTIONS then indirectly calls continue_sspi, which
         tries to dereference the m_pHttpSession's auth_session's
         sspi_host which is nullptr at this point.
      
      So in case NeonSession detects the NE_AUTH error condition, let's
      set a flag indicating that the next Init() should reinitialize its
      m_pHttpSession.
      
      Also fixed a case when xProps was used before initialization in
      Content::getPropertyValues.
      
      Change-Id: Ifc9eec4fe0333ff6be17c5089068441b4a6eb78c
      Reviewed-on: https://gerrit.libreoffice.org/65950
      Tested-by: Jenkins
      Reviewed-by: 's avatarMike Kaganski <mike.kaganski@collabora.com>
      162a472d
  29. 20 Ara, 2018 1 kayıt (commit)
  30. 08 Ara, 2018 1 kayıt (commit)
  31. 07 Ara, 2018 2 kayıt (commit)
  32. 06 Ara, 2018 1 kayıt (commit)
  33. 05 Ara, 2018 1 kayıt (commit)
  34. 29 Kas, 2018 1 kayıt (commit)