As per ESC & Design Team decisions.

It has become unusable anyway after major changes
on the Mozilla side.

Long live Libreoffice Themes! :)

Change-Id: I2893fbc5e4f5637ee9715fa426b92ca58534f126
Reviewed-on: https://gerrit.libreoffice.org/72811
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>

Which allows not hardcoding true for LOK.

Change-Id: I644763ba052b148fc34283e361aa02f9bba2c5ee
Reviewed-on: https://gerrit.libreoffice.org/72832Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>

Change-Id: I3ecaea025fda7a4808f76a9ccda218225ddd38bd
Reviewed-on: https://gerrit.libreoffice.org/72808
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>

Change-Id: I363a02d7115ea54bb4aedb38071a249e145ee471
Reviewed-on: https://gerrit.libreoffice.org/72742
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>

sooner or later someone is going to need more than 65535 redlines

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

and move the auto-format embedded flag to a separate field

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

Its PCHs are always different even if the source is the same (timestamps
somewhere?). But if the output of gcc -E for that precompiled header
source is the same, then technically the .gch should be without a change.
So this makes ccache get hits even if the .gch gets rebuilt, as long
as ccache is new enough to support CCACHE_PCH_EXTSUM (3.5+).

Change-Id: I447bb4840047f23deed55e25de1794047a0a9998
Reviewed-on: https://gerrit.libreoffice.org/72705
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

It's ridiculously un-cooperative, and if you accidentally run the script
from a static IP you won't be able to look at that bugzilla for a while,
which is tragic because it holds important historical info hostage.

Change-Id: I55887baceac82ad0a3bcedc3de9c9b3d0e02f9c3
Reviewed-on: https://gerrit.libreoffice.org/72220
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

The remaining problem is that with the previous commit, the layout stops
at some point and everything is crammed into the next-to-last page, with
the following symptom:

warn:legacy.osl:7667:7667:sw/source/core/layout/tabfrm.cxx:2642: debug assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by fix i44910

This is apparently because of some very funny recursion that goes in
circles until it formats some part of the "outer" table again.

0  SwTabFrame::MakeAll(OutputDevice*) (this=0x82b0280) at tabfrm.cxx:2642
^ mpUpper -> 928 - top-level SwTabFrame and m_pFollow of 905
1  SwFrame::PrepareMake(OutputDevice*) (this=0x82b0280) at calcmove.cxx:372
2  SwFrame::Calc(OutputDevice*) const (this=0x82b0280) at trvlfrm.cxx:1790
3  SwFrame::PrepareMake(OutputDevice*) (this=0x6c06ba0) at calcmove.cxx:247
4  SwFrame::Calc(OutputDevice*) const (this=0x6c06ba0) at trvlfrm.cxx:1790
5  SwFrame::PrepareMake(OutputDevice*) (this=0x82aebf0) at calcmove.cxx:247
6  SwFrame::Calc(OutputDevice*) const (this=0x82aebf0) at trvlfrm.cxx:1790
7  SwFrame::PrepareMake(OutputDevice*) (this=0x6d674e0) at calcmove.cxx:247
8  SwFrame::Calc(OutputDevice*) const (this=0x6d674e0) at trvlfrm.cxx:1790
^ m_pFollow->mpNext -> 332 - again! it's now m_pFollow->mpNext
9  SwTabFrame::MakeAll(OutputDevice*) (this=0x6d64570) at tabfrm.cxx:2544
^ 303 - nested SwTabFrame, used to precede 332 but has now split and its m_pFollow precedes 332
10 SwFrame::PrepareMake(OutputDevice*) (this=0x6d674e0) at calcmove.cxx:313
11 SwFrame::Calc(OutputDevice*) const (this=0x6d674e0) at trvlfrm.cxx:1790
^ 332 - SwTextFrame originally inside 991, but moved under top-level SwTabFrame 928 at this point
12 SwContentFrame::CalcLowers(SwLayoutFrame*, SwLayoutFrame const*, long, bool) (pLay=0x6dccbf0, pDontLeave=0x6ed6e30, nBottom=9223372036854775807, bSkipRowSpanCells=true) at tabfrm.cxx:1479
^ m_pLower -> 991 - SwRowFrame
13 lcl_RecalcRow(SwRowFrame*, long) (pRow=0x6dccbf0, nBottom=9223372036854775807) at tabfrm.cxx:1614
14 lcl_RecalcTable(SwTabFrame&, SwLayoutFrame*, SwLayNotify&) (rTab=..., pFirstRow=0x6dccbf0, rNotify=...) at tabfrm.cxx:1691
15 SwTabFrame::MakeAll(OutputDevice*) (this=0x6ed6e30) at tabfrm.cxx:2082
^ m_pFollow -> 905 - top-level SwTabFrame
16 SwTabFrame::MakeAll(OutputDevice*) (this=0x381d3e0) at tabfrm.cxx:2504
17 SwFrame::PrepareMake(OutputDevice*) (this=0x381d3e0) at calcmove.cxx:372
18 SwFrame::Calc(OutputDevice*) const (this=0x381d3e0) at trvlfrm.cxx:1790
^ 866 - top-level SwTabFrame
19 SwLayAction::FormatLayoutTab(SwTabFrame*, bool) (this=0x7fff95aa3f20, pTab=0x381d3e0, bAddRect=true) at layact.cxx:1483
20 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7fff95aa3f20, pLay=0x6cfedc0, bAddRect=true) at layact.cxx:1375
21 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7fff95aa3f20, pLay=0x6e23fd0, bAddRect=true) at layact.cxx:1380

The first attempt was to add a TextFrameLockGuard around the
pFrame->MakeAll() call in PrepareMake(), with corresponding test in
SwTabFrame::MakeAll() ... but a similar problem still occurred, just now
on page 18 instead of page 12.

Another idea is to prevent PrepareMake() from formatting the
SwTableFrame's follow *again*; it was already formatted by
SwTabFrame::MakeAll() anyway, just before it calls pNxt->Calc().

With this, we get 23 pages for the bugdoc, same as before that commit:
(regression from 18765b9f)

Change-Id: I71e3f92b5f19b800626a008527fa75d08641e8de
Reviewed-on: https://gerrit.libreoffice.org/72799Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Michael Stahl <Michael.Stahl@cib.de>

This is some copypasta, apply the same fix.

Change-Id: I096594f6d54fef68e63c982c2963499d24af6d15
Reviewed-on: https://gerrit.libreoffice.org/72798
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

The problem is that with the change in SwFlowFrame::MoveBwd(), a
SwTextFrame in a table may move backwards during MakeAll(); if the next
frame of the moved frame, and the "this" frame in PrepareMake(), is a
SwTabFrame, then the pFrame->FindNext() will return not this SwTabFrame,
but the first SwTextFrame *inside* the SwTabFrame - hence the iteration
will never meet the "pFrame == this" termination condition and the
SwTabFrame remains unformatted; this warning is printed:

warn:legacy.osl:6874:6874:sw/source/core/layout/calcmove.cxx:296: :-( Layout unstable (this not found).

(regression from 18765b9f)

Change-Id: I68207ba9cf68cd5abe51d647cb757176261eda40
Reviewed-on: https://gerrit.libreoffice.org/72797
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

Change-Id: I898fb0830a9f53da4a7917cb5900f082e3a9d6b7
Reviewed-on: https://gerrit.libreoffice.org/71944
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

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

Change-Id: I67b76b65105e5020ea396ab68d41999c80368c41
Reviewed-on: https://gerrit.libreoffice.org/72812
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

Change-Id: I6d44335ab51c92dc605ee341efaaa4bf6f7bd42f
Reviewed-on: https://gerrit.libreoffice.org/72587
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.

Change-Id: I23a6d485ee1ca0bc3801bcc1a6d748b8ed2b490c
Reviewed-on: https://gerrit.libreoffice.org/72634
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Change-Id: I677c3b184e225c3bac1c56efd5ea46aaa2497d69
Reviewed-on: https://gerrit.libreoffice.org/72810
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Property "PickListEntry" is available since LO 5.1 but not
mentioned in css.document.MediaDescriptor.
original change has been committed with tdf#95095.

Change-Id: I684e4c76f79c9646af3cac9670790d2b2c3eca97
Reviewed-on: https://gerrit.libreoffice.org/72553
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

This is for COLEAT's internal use.

Change-Id: If1ac2a5b251129e4431d3c0bde82529d6bdc7ccc
Reviewed-on: https://gerrit.libreoffice.org/72809
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>

The page handling implementation is a little bit tricky, because
the elemnt list is not handled like a grid but a list. Normally
one would keep the horizontal cell and just scroll vertically.
Instead this implements a kind of circle.

Vertical offset is consistet, so you have the same amount of
steps for up and down, but up runs left and down runs right.

Change-Id: I296a46e98f7e00a59fd0a0ba358c981b49ac86cd
Reviewed-on: https://gerrit.libreoffice.org/72793
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

This adds arrows + home + end key navigation.

The grid is handled like a list. For convenience Left + Up
and Right + Down keys work in the same way.

Change-Id: I757184e5161f2c7ac9b241294a5edc304c882497
Reviewed-on: https://gerrit.libreoffice.org/72792
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

Just implements Move the same way then Resize. More importantly
the patch correctly resets the Thumb and Page rectangles to
position (0,0) instead of just Empty, which ImplCalc is based on.

Otherwise this results in broken scroll bars, when the StarMath
elements window is docked in in the bottom or top area and
switches the scrolling orientation on undock.

Change-Id: I32b0507cdd6551cc7f42655a730faf8ef25b747b
Reviewed-on: https://gerrit.libreoffice.org/72794
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

Switches the ScrollBar to horizontal in vertical mode and
adapts the scrolling.

Change-Id: I35370d74175ccd1f117b17f7d7ffa25119f2e612
Reviewed-on: https://gerrit.libreoffice.org/72791
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

Moves duplicate code from ImplInitSettings and ApplySettings into
their own functions.

Change-Id: I65b5a052b171a661ee22762e373745c28779a9e9
Reviewed-on: https://gerrit.libreoffice.org/72790
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

Replaces some code with calls to ApplyControlForeground and
ApplyControlFont.

Change-Id: I16837ad7c48ed46fa48b1f2a33a84c7e94f63482
Reviewed-on: https://gerrit.libreoffice.org/72789
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

TextEngine::SetFont copies the font parameter and then modifies
its color, transparency, fill color and alignment, so passing the
same font again will not be detected as the same font.

Therefore this patch stores the original font in addition to the
modified one and also returns that one on the GetFont call.

This allows us to merge the font setup in VclMultiLineEdit's
ImplInitSettings and ApplySettings into a common function.

Change-Id: I618d283ecd0ae14faf9b87a3aceec6ca1c37b526
Reviewed-on: https://gerrit.libreoffice.org/72788
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

Change-Id: I221b7ae202d6dbd08d0496561652b2471b093b46
Reviewed-on: https://gerrit.libreoffice.org/72783Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>

Regression from commit 458a827e (further
refactor Menu to use RenderContext, 2015-05-15), the problem was that
this highlight on the menu bar on mouse move was only part of the
incremental paint, never the full paint.

So when that commit removed incremental paint, we lost highlight on
mouse move (move only, click is there).

Later commit 843b9d5d (VCL add support
for rollover menubars, 2016-09-22) added this code back, conditionally
for the case when there is not enough space for the menu bar
horizontally.

So fix the lack of highlight on plain mouse move by unconditionally
highlighting the rolled over item, even if there is enough horizontal
space.

Change-Id: I357001f2e65f843444ed0ffbe470667dfc5d5aa3
Reviewed-on: https://gerrit.libreoffice.org/72774Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins

Change-Id: I2080f3c04a04cea626d4969b59e54612cbefe03b
Reviewed-on: https://gerrit.libreoffice.org/72780Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>

Change-Id: I3ea246c84bb81e4eca9fe569edb957bed3c788ee
Reviewed-on: https://gerrit.libreoffice.org/72674
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

...following up on 1453c2c8 "prefer vector::data
to &vector[0]"

Change-Id: I7c113747d92d144a521d49b89384dd8bf1215c01
Reviewed-on: https://gerrit.libreoffice.org/72765
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

...to avoid the upcoming loplugin:data asking to replace just each initial
&aAttrs[0] with aAttrs.begin() and leave the remaining &aAttrs[N] alone, which
would make the results look odd.

Change-Id: I7d5c76e9d4fc6c7fa13cb28fca5ea65ea2d0f77e
Reviewed-on: https://gerrit.libreoffice.org/72764
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

...to avoid the upcoming loplugin:data asking to replace just the initial
&aStrs[0] with aStrs.begin() and leave the rest alone, which would make the
result look odd.

Change-Id: I37a86fc494c47afc56de041f3d803356fb97317d
Reviewed-on: https://gerrit.libreoffice.org/72762
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: If7a5e779716e9423e94c22d11fc0f029fb89401f
Reviewed-on: https://gerrit.libreoffice.org/72754
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

Regression from
https://cgit.freedesktop.org/libreoffice/core/commit/?id=3208fcb3a36d75d6290d9c548430682f153b09db

Change-Id: I8f85f0a5838df87671ecb9bdb5751b7ec43c09ea
Reviewed-on: https://gerrit.libreoffice.org/72701
Tested-by: Jenkins
Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>

Fixes CVE-2019-5435. It looks like this is not a problem on 32-bit
Windows because fortunately we don't use /LARGEADDRESSAWARE flag
to set IMAGE_FILE_LARGE_ADDRESS_AWARE... but on 32-bit Linux
the user-space VM is 3GB so an exploit might be possible.

Apparently there's no code in LO that uses the CURLU_URLENCODE flag.

The other one, CVE-2019-5436, doesn't matter because we disable tftp.

Change-Id: I0d4f087befa5a3c4fb21ec36761dad68932425d9
Reviewed-on: https://gerrit.libreoffice.org/72732
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

...which causes asserts to fire since <https://github.com/llvm/llvm-project/
commit/04323c24a1ac9464471331d9f6499d3cb95d1ccd> "Added an assertion to constant
evaluation enty points that prohibits …"

Change-Id: Iafbf1cea85d15a38a71275d4cea8303bab500f6a
Reviewed-on: https://gerrit.libreoffice.org/72723
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

It doesn't correctly make a dependency on the .gch or anything
the .gch is made from, so there would be stale cache hits even
if anything included from the .gch changed. Disable CCACHE_DEPEND.
https://github.com/ccache/ccache/pull/427

Change-Id: I6929ff6ec1f1e50498033cdf95b56c94522166eb
Reviewed-on: https://gerrit.libreoffice.org/72704
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

With just -include a.hxx ccache checks only for presence of a.hxx.gch
and it doesn't search the path given by -I, so it didn't detect the usage
of the .gch and thus didn't include it in the checksum, possibly leading
to false positives. Icecream similarly doesn't search paths given by -I
and may fail to properly handle the .gch usage.

Change-Id: I40ba2d5089e77cd5e8da670c7e030f9e90ebc8ac
Reviewed-on: https://gerrit.libreoffice.org/72703
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

Enable the gtk3_kde5 and kde5 VCL plugins as discussed
in ESC all of 2019-05-02.
Also drop the "--disable-gtk3" switch so gtk3 is built
as well (which is enabled by default).

Change-Id: I65230255f8db6a7de992c6f5e9f9892a72436349
Reviewed-on: https://gerrit.libreoffice.org/71865
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>