Also did some extensive reformat in this one as trailing whitespaces
and bad formatting prevented commiting because it gave the following
error:
*
* You have some suspicious patch lines:
*
* In scripting/source/pyprov/mailmerge.py
* indent with Tab (line 446)
scripting/source/pyprov/mailmerge.py:446: return PyMailSMTPService(self.ctx)
* indent with Tab (line 448)
scripting/source/pyprov/mailmerge.py:448: return PyMailPOP3Service(self.ctx)
* indent with Tab (line 450)
scripting/source/pyprov/mailmerge.py:450: return PyMailIMAPService(self.ctx)
Change-Id: Ie6a7a81dda851548a06057fb712cd3e094c9b97d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165498
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
where it was obsoleted by commits 2484de6728
(Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and
fb3c04bd19 (Drop non-const Sequence::operator[]
in internal code 2021-11-05).
Change-Id: I64683093afc48ddf2307dc1dee2302cf0b3cbecc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167110
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
where it was obsoleted by commits 2484de6728
(Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and
fb3c04bd19 (Drop non-const Sequence::operator[]
in internal code 2021-11-05).
Change-Id: I4ccc647bb794515c8c11f8dfd9a26563f4aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166819
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
...at the expense of losing, at least for now, the script editor for it (which
had been hacked into the old upstream sources in a hard-to-maintain way).
rhino-1.7.14.zip is taken from
<https://github.com/mozilla/rhino/releases/download/Rhino1_7_14_Release/rhino-1.7.14.zip>.
Building it would now use Gradle, but instead just hack together an invocation
of javac and jar in external/rhino/ExternalProject_rhino.mk that effectively
generates the same jar as the upstream-built jar available at
<https://github.com/mozilla/rhino/releases/download/Rhino1_7_14_Release/rhino-1.7.14.jar>.
All the various patches are no longer necessary:
* external/rhino/rhino1_5R5.patch and external/rhino/OfficeScriptInfo.java were
mostly for the hacked-in script editor, which has been abandoned at least for
now (see above).
* external/rhino/rhino1_5R5-find_swing.patch (originally from
0a7f934650 "ause109: #i106296# make build.xml
aware of TARFILE_LOCATION") appears to be obsolete.
* external/rhino/rhino1_5R5-updateToolTip.patch is covered by
<https://github.com/mozilla/rhino/commit/ab20a73b16f68daf715c7ac4808c119bb15d698c>
"Fix bug 414869: Rhino debugger fails to launch due to updates in mac os x
leopard".
* external/rhino/rhino-classpath.patch.1 from
bb58293296 "rhino: unbreak build on Fedora 34"
was only relevant when building with Ant.
Change-Id: I5fca5915d785716f7aaf313ff2469a20f55f707a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165190
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
SbxValue::SetType clears the original value. We need to use the Get/Put
cycle, asking for a specific type in Get, and then making sure that the
variable is not fixed on Put.
Change-Id: I0a6c106d511e8491c89a5a2153f47a708f83ee1e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162664
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The "ehlo" calls look redundant, smtplib will do these implicitly if
required (checked in Python 3.5.9); it will also check that the STARTTLS
is successful which very old versions of Python didn't do.
Change-Id: Ice8b24bc2c9773c1171e856f1aefb191b1e2e947
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159078
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
This reverts commit 7fc6063914.
sberg noticed that there is a difference now:
there's a subtle difference now, in that if y was null originally, it would have thrown a (caught) exception, whereas now it will crash in the y.query<X>() call.
Change-Id: Idbb5a08d635d15b5ca63f4822eddf05fb0a5afa0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156002
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...when dispose is called without a preceding call to initialize (as would
happen with an improved CppunitTest_services)
Change-Id: Ic632d736ecb27509b092ef526cf0dfc964023663
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150576
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
- Check the loop termination in readBytes() properly: currently it increments
totalBytesRead while also decrementing nBytesToRead, so when compared to
each other, the loop terminates when the buffer is half full. Only check
for nBytesToRead instead.
- Deal with the possibility of available() returning 0 in readSomeBytes().
Patch by: me
Cherry-picked from
https://github.com/apache/openoffice/commit/7e29bacc90c4b1b9788c3b71dfacd17daecde7a7
"Fix some errors in the scripting module's XInputStreamImpl:"
Change-Id: I951dc10565afa3519b0ddf98de559a7b585b1627
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149156
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
The vnd.sun.star.expand: payload must be URL-decoded prior to passing
it to expandMacros; the protocol must be checked case-insensitively.
Use startsWithIgnoreAsciiCase for that.
Change-Id: I2be993a0400a27cb7dc57207cd0824b4505afd2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146855
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Similar to what is done in bootstrap_expandUri, expandUnoRcUrl,
UrlReference::expand, JavaLoader.expand_url, and is documented
in XVndSunStarExpandUrl interface.
Change-Id: I65349b52734f212e6a04e615d39fa2563f62d472
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146840
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
SfxObjectShell::Current() can return null, it's based on the equally
vile SfxViewFrame::Current()
Change-Id: Ia5c7783680e9d8e5d3075078f16a2c15cb6f7a47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144339
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
As reported by the user, if you go to Tools - Macro - Run Macro and select the InsertText macro (under Application Macros), you'll get an error.
The reason for this is that the InsertText macro is not meant to be called from the Macro Selector since it requires 1 positional argument.
Therefore, this patch creates a simple callable Python macro that uses the InsertText funcion, so that this error message no longer happens.
Change-Id: I63f766795bda2d2ae1b95a7c0d8110f41f9fbea2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140384
Tested-by: Jenkins
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
Noel Grandin