https://bugs.documentfoundation.org/show_bug.cgi?id=150982
--- Comment #4 from Stephan Bergmann <[email protected]> --- (In reply to Mike Kaganski from comment #1) > The problem is different encoding of the path sent from soffice.bin to > uno.exe. The preparation of the path happens in > PackageManagerImpl::addPackage, where title_enc (pystringtest%20(2).oxt) is > an URL-encoded version of title (pystringtest (2).oxt), and destFolder is > "vnd.sun.star.expand:$TMP_EXTENSIONS/extensions/lu233889xtt2.tmp_" created > in insertToActivationLayer (using makeURL). > > Then these two are joined using another call to makeURL; the latter has a > special processing of 'baseURL.match( "vnd.sun.star.expand:" )' case, which > incidentally was also true for destFolder; and that processing uses > encodeForRcFile and rtl::Uri::encode of the relative part; and the resulting > URL is > > vnd.sun.star.expand:$TMP_EXTENSIONS/extensions/lu233889xtt2.tmp_/ > pystringtest%2520(2).oxt > > Now it's sent to uno.exe, which passes the URL to Loader.getModuleFromUrl > (pyuno/source/loader/pythonloader.py). The latter processes > '"vnd.sun.star.expand" == protocol' case, using expandMacros - but that's > all. That Python code must URL-decode the vnd.sun.star.expand:... payload prior to passing it to expandMacros (cf. e.g. what bootstrap_expandUri in cppuhelper/source/bootstrap.cxx does). -- You are receiving this mail because: You are the assignee for the bug.
