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

We need to do rView->GrabFocus() , before calling any other function.

Change-Id: I95a64f44c40070caa0064c3e73fb5d7b04b3bf4b
Reviewed-on: https://gerrit.libreoffice.org/65437
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>

* Update helpcontent2 from branch 'master'
  - Fix menu paths Help pages after translators review
    
    Change-Id: I4afa7097d47b186c0f9732f68abadcbd73633042
    Reviewed-on: https://gerrit.libreoffice.org/65487
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

* Update helpcontent2 from branch 'master'
  - 2 typos corrected
    
    Change-Id: Ic3e2524861d91480da0cdb53400f22ca46d10e45
    Reviewed-on: https://gerrit.libreoffice.org/65499
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

Change-Id: I5fb590745b733e2bfb934d946276857b65caf680
Reviewed-on: https://gerrit.libreoffice.org/65278
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

The anchor position of a fly frame can be on an empty node after the
last non-deleted text, and SwAnchoredObject::CheckCharRect()
needs to get a valid frame index for that.

This can be reproduced with ooo69593-1.odt.

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

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

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

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

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

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

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

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

To not increase the size of the main org.libreoffice.LibreOffice app further,
the plan was to realize this as an org.libreoffice.LibreOffice.Help extension.
Ideally, this would be a localized extension, so that, by default, only a
relevant subset of the extension would be downloaded and installed.  (But see
below.)

There are multiple technical problems, as discussed at <https://github.com/
flathub/org.libreoffice.LibreOffice/issues/35#issuecomment-447295308> "Add
integrated LibreOffice Help offline":

* LO can't pass a file URL with query part to xdg-open, so uses a temporary
  wrapper .html file that redirects to the target URL.  But for the flatpak case
  this wrapper can't be in /tmp (which isn't visible from outside the flatpak
  sandbox), but is instead stored in a new temp dir under $XDG_CACHE_HOME (which
  is always set for flatpaks and /is/ visible form the outside) that is
  removed on LO exit.

* The file URL stored in the temp file must be rewritten from the internal path
  (/app/libreoffice/help/...) to the path as seen outside the flatpak sandbox.
  While the path for the org.libreoffice.LibreOffice /app is stored in
  /.flatpak-info, the external path for the org.libreoffice.LibreOffice.Help
  extension is different and not stored there.  So use a hack trying to
  construct that path from what information is available in /.flatpak-info.

* But the help content consists of locale-specific and shared files, and those
  reference each other with relative links.  But a localized flatpak extension
  cannot contain shared files, it can only contain per-language sub-dirs.  And
  if the shared help files were kept out of the extension, as part of the app
  itself, the relative paths among these files inside the flatpak sandbox would
  differ from those outside of it, so would be broken when viewing the content
  in the external browser.  A solution would either (a) need to somehow rewrite
  the content of all the help files being served from LO to the external
  browser, or (b) replicate the shared help files in all the extension's per-
  language sub-dirs (and if some localization uses en-US content as a fallback
  for only part of its translated content, e.g., in the case of media files,
  would need to also replicate that en-US content), or (c) use a non-localized
  extension that always contains the content for all localizations.

For now, I chose the third approach.  This makes the
org.libreoffice.LibreOffice.Help extension relatively large (the current
/app/libreoffice/help tree has a size of ca. 100MB), so that I decided to not
have it downloaded and installed automatically ("no-autodownload": true in
solenv/flatpak-manifest.in).  (I checked with Flatpak 1.0.6 that if the
extension should be changed to a localized one with the same name in the future,
updating from an older version would work.  If the old extension was not
installed, just the relevant localizations of the new version will be downloaded
and installed.  If the old extension was installed, the full set of
localizations of the new version will be downloaded and installed.)

(As also mentioned at <https://github.com/flathub/org.libreoffice.LibreOffice/
issues/35#issuecomment-447295308>:  "A second, minor, nuisance is that, for
security reasons, an `xdg-open file:///...html` call from a flatpak leads to an
intermediate popup dialog letting the user chose which application to use to
open the URI, while e.g. an `xdg-open http:///...html` is allowed to go directly
to the user's preferred browser.  So accessing help content from LO flatpak
would present that popup dialog first, forcing the user to select a browser to
proceed.")

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

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

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

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

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

Commit f3ce30ec changed this to return
after first non-throwing XNameContainer::hasByName, regardless if it
returned true or false.

This changes it back, to iterate over all the providers again.

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

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

It passed "make check" on Linux

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

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

It passed "make check" on Linux

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

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

Use range-based loop or replace with STL functions

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

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

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

Change-Id: I2be36438ca1ab0646aa8f89dfcb317d6a162b072
Reviewed-on: https://gerrit.libreoffice.org/65266
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>

* Update helpcontent2 from branch 'master'
  - Dissolve contraction, don't -> do not
    
    This was already fixed for 6-2 with commit
    d08d1c486558d6c113863d579f89e1faf8d89572
    
    Change-Id: I00e67478ae41cd5724d2df8abe105faef4343c21
    

OLE objects by exporting their VisibleArea settings

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

* Update helpcontent2 from branch 'master'
  - Fix code formatting in validity help pages
    
    Change-Id: I9b0558bb805512c98223eaf2305d37861e10c82c
    Reviewed-on: https://gerrit.libreoffice.org/65458
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

seems menubar gets set to dirty due to some menu activity that needs
a refresh, but then the hierarchy changes and as its already dirty
the maUpdateMenuBarIdle doesn't get launched

the placement of the mbMenuBar test inside the loop through parents
shows some confusion as to what which mbMenuBar might be met, the
one belonging to this, or that of the parent being traversed, but
it does seem to be the one belonging to this.

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

The user-visible problem was that embedded (OLE) objects contained in a
document that was loaded on a thread were not editable.

This works in the loaded-with-UI case because the Windows version of the
SalData constructor in vcl calls CoInitialize() (which sets the
concurrency model of the main thread to STA) and then later the
OleComponent constructor in embeddedobj calls OleInitialize(), which
just realizes that the concurrency model is already set, and OLE editing
works.

However, if the document is loaded on a thread, things are different.
The concurrency model of the thread is set to MTA in
oslWorkerWrapperFunction() in sal, so the later OleInitialize() will
fail with RPC_E_CHANGED_MODE, as it's not possible to set the
concurrency model of a thread once it's set.

Solve the problem by providing in opt-in way to execute the actual
import on the main thread, since remote UNO clients always invoke
Desktop::loadComponentFromURL() on a thread.

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

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

Change-Id: I9ebf0c3664c56f99a4e423c409c5d1621b8ea082
Reviewed-on: https://gerrit.libreoffice.org/65402
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

Change-Id: I866611929f75dd322ce81ec54a63ec08002f55cc
Reviewed-on: https://gerrit.libreoffice.org/65401
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Jens Carl <j.carl43@gmx.de>

Move XTableRows Java tests to C++ for ScTableRowsObj.

Change-Id: I765d213e0a3e95a3925f1fc179a8a3f6c6611739
Reviewed-on: https://gerrit.libreoffice.org/65398
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

* Update helpcontent2 from branch 'master'
  - http -> https
    
    Turns out the https://www.oasis-open.org/standards#opendocumentv1.2
    page has linked them badly with http ...
    
    Change-Id: I64d26f79f4503a6b795c4990cf92327d20fbb08a
    Reviewed-on: https://gerrit.libreoffice.org/65459Reviewed-by: Eike Rathke <erack@redhat.com>
    Tested-by: Jenkins
    

* Update helpcontent2 from branch 'master'
  - Point to the OASIS Standards page at #opendocumentv1.2
    
    Change-Id: Idb6c0839694337855b42b22d0ab1d98c8ae30892
    Reviewed-on: https://gerrit.libreoffice.org/65455Reviewed-by: Eike Rathke <erack@redhat.com>
    Tested-by: Jenkins
    

* Update helpcontent2 from branch 'master'
  - Point to the correct ODFF 1.2 specification download link
    
    The previously pointed to office-formula page is the collection of
    working drafts.
    
    Change-Id: Id8bc75e2192ce8da26ca1af1d8779560ace14b6b
    Reviewed-on: https://gerrit.libreoffice.org/65454Reviewed-by: Eike Rathke <erack@redhat.com>
    Tested-by: Jenkins
    

Change-Id: Id1ae1c7cd7beb88c0dcb9ec9c36fc3a06920def1