Only on macOS, the SDK used to expect javac etc. in a Commands sub-dir (which
Apple's JDK 1.6.0 has but Oracle's JDK 1.8.x don't). However, at least both
Apple's latest JDK 1.6.0 (as available via <https://support.apple.com/kb/DL1572>
"Download Java for OS X 2015-001") and any recent Oracle JDK 1.8.x (like
jdk1.8.0_121.jdk) have a Home sub-dir that contains a "standard" sub-tree with
bin sub-dir etc., like on other platforms. So consistently make the SDK use
that instead.
This removes the JAVABIN Make variable from settings.mk. It is assumed to not
be used by client code.
Change-Id: Ie0ad647f489528444dfd399c2f00500b772d3288
The problem in callnk.cxx was that when selecting 1 char to the right
using keyboard, and exiting field boundary, nCmp pointed to previous
position (inside field), and then compared to position to the left
(which also may be inside field), thus missing call change link (and
read-only state change). Seems that this was a mistake in commit
740efbb1da.
In pam.cxx, if cursor was to the left of field, and then selected
1 char to the right to cross field's boundary, then both PaM's point
and mark had same fieldmark, but point was outside, and mark inside,
and as code didn't check this condition, so read-only state wasn't
properly set.
Unit test is augmented to check the second problem.
Change-Id: I7323e53eeb261b4ccdc0f9e36cc0956b373f104d
Reviewed-on: https://gerrit.libreoffice.org/33790
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The #include was introduced in
96c1ae1d8e with an #if on
HAVE_FEATURE_OPENGL, but that #if was later removed.
Change-Id: I70f839d5224e0a77a1640a5e23cbe64656c9cb1b
This reverts commit 4739b31daf.
Apparently, passing a param of type css::uno::Exception to Any
will record precisely a css::uno::Exception in that Any, losing
any subtype information, which this commit changed.
So add to them instead of just assigning. In the bugdoc the initial
values were zero, but maybe in some other cases they aren't.
Change-Id: I3d399fe4aab9260817f171d4e69388a19eb85d21
just the simple and obvious case for now, of a local var being allocated
and deleted inside a single local block, and the delete happening at the
end of the block
Change-Id: I3a7a094da543debdcd2374737c2ecff91d644625
Reviewed-on: https://gerrit.libreoffice.org/33749
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Text portion level background in Writer text was working already, as
Writer paints its background explicitly, and then uses no text fill
color in the metafile (that is turned into a PDF later).
However, text fill color is used for Writer shape text and also in
Impress. The rectangle is not just the text itself, but also the ascent
/ descent region, this matches the desktop rendering result.
Change-Id: I644007ade43a8b9e663890643b826ae12c427ea5
Reviewed-on: https://gerrit.libreoffice.org/33781
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
...as is the case for external/breakpad's
google_breakpad::ExceptionHandler::SignalHandler (though that one appears to be
careful to check that its additional arguments are not garbage, cf. the
"Sometime, Breakpad runs inside a process where some other buggy code..."
comment in
workdir/UnpackedTarball/breakpad/src/client/linux/handler/exception_handler.cc).
Seen when JunitTest_framework_complex run under ASan/UBSan happened to trigger
an assert,
> soffice.bin: vcl/source/app/dbggui.cxx:47: void ImplDbgTestSolarMutex(): Assertion `ImplGetSVData()->mpDefInst->CheckYieldMutex() && "SolarMutex not locked"' failed.
> sal/osl/unx/signal.cxx:349:13: runtime error: call to function google_breakpad::ExceptionHandler::SignalHandler(int, siginfo_t*, void*) through pointer to incorrect function type 'void (*)(int)'
> (instdir/program/libsofficeapp.so+0xb7eab0): note: google_breakpad::ExceptionHandler::SignalHandler(int, siginfo_t*, void*) defined here
> #0 0x7f6cefc21693 in (anonymous namespace)::callSystemHandler(int) sal/osl/unx/signal.cxx:349:13
> #1 0x7f6cefc1f3e1 in (anonymous namespace)::signalHandlerFunction(int) sal/osl/unx/signal.cxx:422:9
> #2 0x7f6cedbc95bf (/lib64/libpthread.so.0+0x115bf)
> #3 0x7f6ced20491e in __libc_signal_restore_set /usr/src/debug/glibc-2.24-33-ge9e69e4/signal/../sysdeps/unix/sysv/linux/nptl-signals.h:79
> #4 0x7f6ced20491e in __GI_raise /usr/src/debug/glibc-2.24-33-ge9e69e4/signal/../sysdeps/unix/sysv/linux/raise.c:55
> #5 0x7f6ced206519 in __GI_abort /usr/src/debug/glibc-2.24-33-ge9e69e4/stdlib/abort.c:89
> #6 0x7f6ced1fcda6 in __assert_fail_base /usr/src/debug/glibc-2.24-33-ge9e69e4/assert/assert.c:92
> #7 0x7f6ced1fce51 in __GI___assert_fail /usr/src/debug/glibc-2.24-33-ge9e69e4/assert/assert.c:101
> #8 0x7f6cb60cdad5 in ImplDbgTestSolarMutex() vcl/source/app/dbggui.cxx:47:5
> #9 0x7f6cbd337fb9 in DbgTestSolarMutex() tools/source/debug/debug.cxx:74:9
> #10 0x7f6cb3c98abf in vcl::Window::ReleaseGraphics(bool) vcl/source/window/window.cxx:900:5
...
Change-Id: I2625541e0b9e50f9723e61e0cbff0e6c77d0fb9f
lets just leave the toolbar active the whole time, seems
to make more sense anyway wrt being allowed to keyboard
into it to paste/insert special character
Change-Id: I174fb707c4c7fd21d95461cc93323eb6d8970818
because root entries have UserData of type SwContentType while children have
UserData of type SwContent (both inherit from SwTypeNumber)
Change-Id: Iab7a4caaca5dfdae16aa4f6ede565e26aa4c73c9
