Bug 46885 - LibO crash when creating chart with no cells selected

Change-Id: Iebe582863c2330579087d3d2743bca5d2d1676f6
Reviewed-on: https://gerrit.libreoffice.org/67472
Tested-by: Jenkins
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

Bug 62349 - Calc crashes when a newly created chart copied to clipboard

Change-Id: I0627e2c86a7ce54ff0e84f8ebb3cdef1fce218c0
Reviewed-on: https://gerrit.libreoffice.org/67469
Tested-by: Jenkins
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

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

...to f90e26b6 "tdf#107461: For Unix-like OS,
support file://<hostname>/... URLs" calling osl_getLocalHostname from
sal/osl/unx/file_url.cxx.

Change-Id: I2d9d3f8f7a1c7a1505dfafff0e60633b89f2de27

Change-Id: Ia74c43372b12eb71a8cc443de15458b374ee6b85
Reviewed-on: https://gerrit.libreoffice.org/67446
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>

cause the outer if is...

if ( pAny && ( *pAny >>= seqCoordinates ) && ( seqCoordinates.getLength() >= 4 ) )
{
	... nNumElemVert = seqCoordinates.getLength();
}

so this check is always true

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

Change-Id: I3f8fa4bafd5b3ff5eb549076db16cb73a5dde7e0
Reviewed-on: https://gerrit.libreoffice.org/67458
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

Which was skipped before.

Change-Id: I7fcd5608a8cdbeea9ea15c9c9aa32c9020154750

Such that screenreaders don't announce them. To make this happen,
pass them as NonStructElement to PDF writer.

Change-Id: I94d52ee0207cd6362edabfb9b891faa7fe341543

implemented as described in
https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf#G21.1021281

Change-Id: I943c35cb8ee833ff46ff594e6b6c1025450b9ca4

pptx import seems little flaky in this regard, EE_PARA_OUTLLEVEL
isn't always set (no such problem with odp). Instead, we'll query
paragraph's depth and visibility of bullets/numbering.

Change-Id: Ia8cf6b7bb0e065a1378875442a99d79b006e2d77

The current tagged PDF export does not well support
quite some internal structures. This includes all
apps (Draw/Impress/Writer/Calc) and some areas.

-= AlternativeText ('/Alt'):

Only writer currently at least adds Title information,
but we also have Description (MS does add) and Name.
Target is to add this information when available to
content frames.
Writer did that by manually adding that tag using
PDFExtOutDevData::SetAlternateText, but only used
Title so far.
To make this work as broad as possible, better add
this to primitives. There is already a primitive called
ObjectInfoPrimitive2D that encapsulates any content
adding Name/Title/Description using GroupPrimitive
functionality.
Changed Writer to use that way. Draw/Impress already
uses it, all apps now use graphic paint using primitives,
so we have a natural target to encapsulate. Add support
to VclMetafileProcessor2D to interpret it and add
- if mpPDFExtOutDevData->GetIsExportTaggedPDF() - that
data using a combination of Name/Title/Description and
add using mpPDFExtOutDevData->SetAlternateText.
This works for Draw/Impress/Writer, but not for Calc
because Calc does not create more complex data structures,
so SetAlternateText does not work (see
PDFWriterImpl::setAlternateText for more infos).

-= Area tagged ListContent (use 'L', 'LI', 'LBody' PDF tags):

To support this in Draw/Impress, we can also use a similar
way to support in primitives. For this I evaluated how to
add needed OutlineLevel information to the existing (and
already used to write 'P') TextHierarchyParagraphPrimitive2D.
Added this and now ready to use in VclMetafileProcessor2D
::processTextHierarchyParagraphPrimitive2D.
Added now using the OutlineLevel information at the
TextHierarchyParagraphPrimitive2D. Made sure there are
fallbacks to unchanged old behaviour when no PDF export
or no Tagged-PDF used. Creating now '/L', '/LI' and '/LBody'
statements as tagged PDF wants us to do.
Exported PDF still works well while additionally a verifier
as 'PAC 3' shows the expected and wanted structure.
This will work now for any text in Draw/Impress and for
Draw-Objects using Lists in Calc. Need to check for direct
text in Calc cells and Writer - and guess how big the
effort would be for these to make it work there, too.

-= Area '/Artifact':

Target is to avoid too much ScreenReader hassle when
Impress uses Pictures/FillPatterns etc. in Background
- what means on MasterPage in Impress.
Experimented with different possibilities. Decided to use
existing StructureTagPrimitive2D and extend for info if
encapsulated data is 'Background' data -> on MasterPage.
Can be created in ImplRenderPaintProc in method
createRedirectedPrimitive2DSeque as needed by checking
for MasterPage member (remember: primitives need to be
as independent from model data as possible, never include
e.g. a SdrObject reference in any way).
Tried different ways to use this in VclMetafileProcessor2D
processStructureTagPrimitive2D, see comments there. Current
best solution is to just *not* create StuctureTag information
for these objects.

Change-Id: Ib2a578b02c1256758cda6d15ce37799803d8205c

... somewhere in a previous shared formula group, so for the new groups
after split the column is added to sc::RefUpdateContext::maRegroupCols
in ScColumn::UpdateReference() to setup new listeners later, and true
returned there, which also results in ScTable::SetStreamValid(false) at
the end, which in this constellation wasn't the case.

It may have been a reason that some documents have individual
unrecalculated results stored (i.e. values moved within ranges that a
shared formula group pointed to) that can be corrected by recalculating
after load.

Said to be a regression from

    commit 2f6a0685
    CommitDate: Fri Jun 5 16:22:38 2015 +0200

        tdf#90694 reset group area listeners when splitting group

but that only uncovered this misbehaviour.

Change-Id: I6b04b71898c3f1774452dd19790c208f3167d8eb
Reviewed-on: https://gerrit.libreoffice.org/67461Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins

I imagine it should have been seqPos-(idPos+2)

seems to be like this since the initial commit of

commit 091fe76b
Date:   Tue Jun 30 12:55:18 2015 +0300

    tdf#87348 implement mso-next-textbox vml-style textbox chaining import

Change-Id: Ic2f527ede2102c01c8589d58d8c705d59b0a6ffe
Reviewed-on: https://gerrit.libreoffice.org/67450Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

60db3d2c "dbu: Set Firebird to default in
wizard.." had done so only "..in case experimental feature is checked in", but
Firebird has been made non-experimental meanwhile as documented at <https://
wiki.documentfoundation.org/index.php?title=ReleaseNotes/6.2&oldid=169290#Base>.

<https://bugs.documentfoundation.org/show_bug.cgi?id=123099> "Creating new
'HSQLDB Embedded' database immediately brings up migration-to-Firebird dialog"
discusses that changing the default to Firebird may be beneficial, so lets do
that unconditionally now.

But 60db3d2c had apparently made a mistake,
setting the value returned from OGeneralPageWizard::getDatasourceName to
"sdbc:embedded:firebird" even though the corresponding "Connect to an exisiting
database" list in the new database wizard doesn't even support that (instead of
"sdbc:firebird:", which matches "Firebird File" in that list).  Fixed that now.

(Curiously, ODsnTypeCollection::getEmbeddedDatabase would read a
DefaultEmbeddedDatabase value from the configuration before resorting to the
hardcoded default, but `git log -SDefaultEmbeddedDatabase` makes it look like
there has never been any code to actually write that setting.)

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

one RemoveDrawObjFromPage is already null-deref protected,
do the same for the other

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

Now it is "Word 2007-2019 Template" and not "Office Open XML
Text Template". Export implementation is focused more on
MS variant, rather than OOXML.

This is follow-up fix for 0932e4bb

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

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

Probably helps VB6 clients.

Change-Id: I3a1072e6ededbd0322c4b0dcd0ef4b16ace215d1

Change-Id: Ia9e78c331d2cb711653ee3e64597ebf2824e0eeb

Change-Id: I14379c5732c1921b8f52293045d01acf99e0b840

Change-Id: I972f9446560cc8ac51031dbc36fc05d438d150e7

Change-Id: I4606e5a3717c3717d105dd2e63c9fd7d2e1abf83

* Update helpcontent2 from branch 'master'
  - Improve scripts legibility for Python newbies
    
    Change-Id: I6adee2c58d4030c433a9fdf0c070069264564742
    Reviewed-on: https://gerrit.libreoffice.org/67439
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

fixes CVE-2018-16890 and CVE-2019-3822

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

The userformscontainers is required property to pass checks in
getter/setter, but returning true instead of actual type is
not a best idea. So let's return actually expected dummy empty
container.

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

...where <hostname> matches whatever osl_getLocalHostname reports.  (And, for
simplicity, don't support variations where e.g. one of the two FQDNs has an
optional final dot while the other has not.)

(It is not clear to me whether a similar change should also be done for the
Windows-specific code in sal/osl/w32/file_url.cxx.  On Windows, file URLs with a
host component are generally interpreted as UNC pathnames, and in some local
test on a Windows 8 machine whose hostname is reported as "win8", passing a URL
like <file://win8/Users/me/Documents/...> (i.e., without a C: drive letter) to
LO already worked to access files on the default drive C: at least.)

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

Change-Id: I61c2ee1e8363a022239d5572e3506df9da0d5e1d
Reviewed-on: https://gerrit.libreoffice.org/67433Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins

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

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

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

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

Change-Id: I7e2fd41f8c4359374af143aaf7544bb61a8878c7
Reviewed-on: https://gerrit.libreoffice.org/67189Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>

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

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

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

settings to keep interoperability, use only cell
properties, as MSO.

Change-Id: I167eb0e8732fa7dc7f890c2a21d59a15299be8ba
Reviewed-on: https://gerrit.libreoffice.org/67429
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>

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

Follow-up of a7da5945

Change-Id: I7e252f9a881b2ac1098bc21bd193f66d32404056
Reviewed-on: https://gerrit.libreoffice.org/67423
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>

The Linux-only conversion of file URLs with a non-empty (other than "localhost")
authority to smb URLs had been added in 2010 with
0b9ef81b "tools-urlobj-smb-scheme-patch.diff:
migrated" (applying a Go-oo patch?) but giving no rationale beyond "process
relative SMB paths (in hyperlinks) correctly".  That makes it hard to tell
whether that patch is (still) actively useful for anything, or was just a
misguided hack from the beginning:

* Why make this Linux only?  What about other non-Windows OSs?  (On Windows,
  such URLs can be resolved as UNC pathnames.)  If the reason for Linux-only was
  that it is the only OS where LO can handle smb URLs via GIO, why not make it
  conditional on ENABLE_GIO?

* Why map to smb?  There are various remote file access protocols.  Hardcoding
  smb looks arbitrary here.

Anyway, INetURLObject is arguably at a wrong level for such a patch.  To not
drop the hack wholesale, reimplement it in the file UCP, forwarding to a
potential other UCP that can handle smb URLs any file://<host>/... URLs
(rewritten as smb URLs) that the file UCP cannot handle itself.
(file://localhost/... URLs will already have been normalized to file:///... by
INetURLObject when they reach the file UCP, and even if they were not, the
osl/file.hxx functionality underlying fileaccess::TaskManager::getUnqFromUrl
knows how to handle them, so they will not take the forward-to-smb code branch.)

(The corresponding #ifdef WIN code from 0b9ef81b
has already been removed with 82034b04
"tdf#119326 crash when adding "Windows Share" File resource".)

(I came across that 2010 patch while looking into
<https://bugs.documentfoundation.org/show_bug.cgi?id=107461> "Does not support
'file://' scheme with actual hostname".  A next step would be to make the file
UCP actually handle any file://<host>/... URLs that denote the local host.)

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