Change-Id: I8879560850b4cf94984e3b3657800273b276fcdb

Commit f8a76d21 (tdf#108524 sw: split
section frames inside table cells, non-split text frames, 2017-07-06)
added support for moving text frame masters to a next page inside
section-in-table frames. But the code in SwFrame::GetNextSctLeaf()
responsible for this is not up to nested tables, so don't try to split
sections in this case.

Otherwise we'll end up with frames which are marked as "in table", but
don't actually have have table frame parents, so we crash in
SwFrame::IsFootnoteAllowed() which assumes being in a table means a
table frame parent.

Change-Id: Iff19a4eda21a4dbfb9562dea7af8ec6767d47873
Reviewed-on: https://gerrit.libreoffice.org/41748Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Catch the exception, since that isn't even invalid input, editengine
just can't do it.

Change-Id: I362923889add4f1a1d3f8f18b0795993119d54b1

...when ScDocShell::GetViewData() returns nullptr. This is needed
when a macro is run from the macro editor window instead of running
the macro from Tools menu in the Calc window.

Change-Id: I89c23c2ec08e8e9907f02eb1389236111530058b
Reviewed-on: https://gerrit.libreoffice.org/41733Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Dennis Francis <dennis.francis@collabora.co.uk>

Change-Id: I1dd57031f8c83241ef4cfa5b22db7a34657ab0bd

Change-Id: Ifd00962ed607166b5521a3977a3021fb7b24957e
Reviewed-on: https://gerrit.libreoffice.org/41747Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: If6d7c8f3223a45803a05d4950abe27bd90ac6dc6

Project: help  d32748eb92d52f1163ff560529ac488dfb25a3b7

tdf#105606: Clarify access to X509 certificate storage

* hint to MSIE on Windows, it's perhaps the easiest
* MacOSX uses TB/FF storage
* point to Tools > Options way to choose which TB/FF profile to use
* env. variables are so 90ties

Change-Id: I6aef05d1f71f98c71cfcc0278b0e5d373959f0ca
Reviewed-on: https://gerrit.libreoffice.org/41743Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
Tested-by: Gabor Kelemen <kelemeng@ubuntu.com>

(Well, actually there wwre a minor difference, "sc ScModule IdleTimer"
vs. "sc::ScModule aIdleTimer", and ditto for "SpellIdle", but that is
hardly essential if even intentional?)

Change-Id: I18a2af0d25c40404a41b1461664feda73183881e

no need to extract the (huge) nativve lib to the device's filesystem on
newer android versions (Marshmallow and later) - can access the .so from
within the apk if it is uncompressed.
While the standalone apk will be larger, the delta-update mechanism of
playstore can be more efficient, so you get:
* faster installation (since the file doesn't need to be extracted)
* less disk usage on device (for same reason)
* smaller delta-updates for playstore

drawbacks
* larger standalone apk
* on older android version more storage needed (the increased size of
the standalone apk), as those will still extract the native-lib

Unfortunately uncompressed it exceeds the current maximum size for
single apk files in playstore (100MB), so cannot use for release-builds

also revive installLocation attribute to allow installation on external
storage and move from manifestPlaceholders from defaultConfig to release
buildType (as otherwise gradle complains about having "Multiple entries
with same key")

Change-Id: Id07ac9c144886bb89abaf7b5b4bc7bd548f27247

Change-Id: I11dbf24b38c08b4dfd3cc64dbacbcd949a37b833

Change-Id: I2eeb265b101b126f6bf268c9c5fa0195a44b0ce7

Change-Id: I21c7a0fb447b5ba0a7aa0ddc690b969b156a91f3

Change-Id: If79b5c1bfdecc8e40247e9f1b2ba314f06ebbe84

Change-Id: Ic668c1ee6c2dac70642480bc584f962921b428b2

Change-Id: Iabcbb6e09616a28c0d8927d11af3da47e48cbd90

Change-Id: Iddeb46c10046a83708ccff82e7125c36ed27c34d

Change-Id: I24c79c1a66ce2dc4cbb1736993643a8f4c14120c

Change-Id: I7ffe60d53f4c4b7690efc8bec9d29a4959740d9a

Change-Id: I36331a6caf560c7622f72c2fafa968522f44f5e9

Change-Id: I2daf0b0868d4bdfb412575b25dbe644e76607342

Change-Id: I1665228a622b18757951b725467933699f9871ae

Change-Id: I6faa8df32e57a846968423cfbe026ce96f6ca7e8

Change-Id: Ic6616f432178fe1f972c5f819302a4fb6b4154fd

Change-Id: I0a965f6957b74ff5db3aab54bef1fa05f3b594c7

Change-Id: If41080debabff46d849dbd6e7f29a941f294c6ad

Change-Id: I6dc7939f42aa1d1d62f8c71f5a5529becdffa704

Change-Id: I892498d323acd72757a05bac05d19c62f11f7cd3

Change-Id: Ia84473360333cb4905692a4d9d0358c93acebff8

and remove some dead ones

Change-Id: I6946d717d3c15dc5207489ed3d56d985dd953d59
Reviewed-on: https://gerrit.libreoffice.org/41746Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Idba9ad7a821cb33070cf5e5a0f79ae55db99b276
Reviewed-on: https://gerrit.libreoffice.org/41504Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Tested-by: Katarina Behrens <Katarina.Behrens@cib.de>

For one, drop a spurious target="1.5" so that ant instead uses the passed-in
JAVA_TARGET_VER (which needs to be 1.6 for Java 9).

For another, the deprecated java.awt.Component.getPeer method finally got
removed, so bsh.util.AWTConsole would no longer compile.  But it looks like that
class is not used by us anyway, so just remove the problematic code.
(workdir/UnpackedTarball/beanshell/docs/manual/bshmanual.html: "Web Browser
Access:  After starting the server you can connect your web browser to the port
you specified.   BeanShell will respond by sending an HTML page offering you a
choice of the Swing based JConsole or the older AWTConsole.  You may choose
whichever is appropriate for your web browser.  [...]  The bsh.util.AWTConsole
is a legacy implementation of the GUI Console using AWT instead of Swing.  This
console does work, but it is not as slick or pretty as the JConsole.  The
primary reason it is still here is to support remote access from generic web
browsers using only Java 1.1.")

Change-Id: I9f1112caebae9a55e4eec7f9baa0114b2254ccda

Change-Id: I3c4d4f99b423f46136a79f3b06c5f0e1492872f1

...in 0660a30d "Avoid loplugin:constparam when
param is subject of cast to non-const pointer"

But turns out this whole avoidance is ill-advised and should eventually be
reverted:

Aug 31 09:09:26 <sberg> noelgrandin, the way you originally handled CastExpr in
 constparam's checkIfCanBeConst, your intent was if there's code like
 static_cast<T*>(p) and param p is found it can be made const, one would also
 need to change that cast to static_cast<T const *>(p) when fixing the loplugin
 warning, right?
Aug 31 09:09:43 <noelgrandin> sberg, correct
Aug 31 09:10:10 <sberg> noelgrandin, I messed the up with
 0660a30d
Aug 31 09:10:12 <IZBot> core - Avoid loplugin:constparam when param is subject
 of cast to non-const pointer -
 http://cgit.freedesktop.org/libreoffice/core/commit/?id=0660a30d54eb6762302cf1afd43de01e137f6393
Aug 31 09:10:24 <noelgrandin> sberg, I probably should have had a test for that
Aug 31 09:10:41 <noelgrandin> tests are better at expressing intent
Aug 31 09:10:56 <sberg> I ran across it in a function that needed to have the
 param non-const for API reasons (callback fn), and it looked like the "obvious"
 fix there, not needing to add the fn to the blacklist
Aug 31 09:11:26 <sberg> I'll eventually get that fixed again (but want to first
 get the Mac and Windows builds to succeed)
Aug 31 09:11:44 <noelgrandin> fair enough

Change-Id: Idef0cfc417ec0597a26a29c8720e3e4051a68e00

and finds loplugin:constparams adapted to ObjCIvarRefExpr also

Change-Id: Ib803cd80b01ad7a0fa07bddb77a873bb323a50c0

Change-Id: I993ab0021d0a0bee8e78975bba180355d2bfb19c

Change-Id: I2d14eeea20d2622e06c7c34a1fa7e84439b3d224

Change-Id: I346a9760c0692449ce5301f5075b3de0271fdadf

Change-Id: I76f5702aad9b57f3031bc35b5271a5dde8ed4f28

since

    commit 990691b1
    Date:   Mon Nov 23 09:58:38 2015 +0200
    loplugin:unusedfields in sdext/

Change-Id: I89b7e59d37af8ba4093ca2e941219b29fd7bd726