Age | Commit message (Collapse) | Author |
|
Remove code in ucb/source/ucp/webdav-neon, and now unused external
neon.
The --with-webdav=no option is retained for now.
Change-Id: I4ce429587e3991fa82009da2f8e4a068abe36435
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126839
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I3b2e01b482f7f4dbceea090b9586cdb4eee4e703
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125869
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I16f3de8398323a308e20d04643a11dd9c3ec59f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124404
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I4b03ab81a17efc125bc5e3b159cf212198c43d22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123707
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
The code in the branches used to do different things before commit
26e6d4b05ab444e6a7529ffcac7fbe592fc94833, which technically made
aProperties a copy of rProperties in both cases, only in one case
there were some checks that didn't affect the end result. This was
progressively cleaned up in commits e06afb0c9546ddcde1cedd75f59001396ac6fdf2
and 39bbfa61653ba7c3cca0aed739559914c78edc89, and this one drops
the last redundant bit.
The only question that remains is: did the initial change
actually intend this result?
Change-Id: Id26d50f7f7bdfed3bfb436e0c8bbbf6b3a0dbf98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123524
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The scenarios are:
1. Calling sequence's begin() and end() in pairs to pass to algorithms
(both calls use getArray(), which does the COW checks)
2. In addition to #1, calling end() again when checking result of find
algorithms, and/or begin() to calculate result's distance
3. Using non-const sequences in range-based for loops, which internally
do #1
4. Assigning sequence to another sequence variable, and then modifying
one of them
In many cases, the sequences could be made const, or treated as const
for the purposes of the algorithms (using std::as_const, std::cbegin,
and std::cend). Where algorithm modifies the sequence, it was changed
to only call getArray() once. For that, css::uno::toNonConstRange was
introduced, which returns a struct (sublclass of std::pair) with two
iterators [begin, end], that are calculated using one call to begin()
and one call to getLength().
To handle #4, css::uno::Sequence::swap was introduced, that swaps the
internal pointer to uno_Sequence. So when a local Sequence variable
should be assigned to another variable, and the latter will be modified
further, it's now possible to use swap instead, so the two sequences
are kept independent.
The modified places were found by temporarily removing non-const end().
Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I61a7910f3ef15b251b1763b7c56848ccbb22fe91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123352
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7d15e9a8c37c29cd6d51c2000f72d1961cd6ff62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123029
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I3ed657c5c5e6840e38e3c8505505b4b372125df0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122910
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I086d02ec4a2ea6d4b439ec34665d8271a67c63dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122472
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I8590d67f064dd74da42c0e3bf543f2aadbd2b893
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121693
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1fa55f09e3a9d398a61856986cb0a91e225c7b79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120087
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I985f9174ea1c6b88e02298f030a81a021c0b1ae3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120008
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I333100fda7e181f68f36b03279b3fbb8cb768310
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117615
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I076f16d0536b534abf0ced4d76051eadb4c0e033
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114949
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I36d82423b5f75010552696a66cec7e53ee265ce4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114395
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to O[U]String from char array literals, we can convert the char literals
to O[U]StringLiteral and avoid a runtime allocation
Change-Id: I15d8dddb2cd428b90740e39f20daf98e0941aa6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
ucb, uno*, uui
Change-Id: Ic4b6d541eb0df8bf7bceddf178ebb5177ad2b87b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112046
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: I7531ea30e8d141dce1d1bc27ffbca3fcf28d0ef5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110892
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Extending this:
https://gerrit.libreoffice.org/c/core/+/110512
Change-Id: I9e7cf757a346d603d0acb818be0c9bc488c8d5c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110516
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
and update the stringview loplugin to detect cases where we can
use these new methods.
Change-Id: I998efe02e35c8efcb3abfb4d7186165bbe6dfb2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110046
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I30ce1b5bd8fb168da7067c1967c5af2569df2653
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108512
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...of treating nullptr like an empty string
Change-Id: I41b8b88f27ed3d3c404781f897952b7d1e0e01e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107279
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I8ba1214500dddaf413c506a4b82f43d63cda804b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106559
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I645c81c1454d3eeea6083387f1d343985b4b6d96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105722
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
...partially reverting 4fbd63860500b2db76df4d5aedbe5e3aa31fac69 "switching long
to a 64-bit type on 64-bit windows"
Change-Id: I858630e5de76942a001ba619085ee07183df6ff6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104994
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(*) create a rewriting plugin to do most of the work, heavily
based on the fakebool plugin
(*) but there are still a number of "long"s in the codebase
that will need to be done by hand
(*) the plugin needs lots of handholding, due to needing to
add #include and update macros
Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I439b9f456ac0bfaa3eb9bf17472053bd4787e828
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103840
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8b5cde993c13e0b7c8c830b1ff698933a6b7cfd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103863
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...from which an OUString can cheaply be instantiated. This is the OUString
equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into
a consteval'ed, static-refcound rtl_String". Most remarks about that commit
apply here too (this commit is just substantially bigger and a bit more
complicated because there were so much more uses of OUStringLiteral than of
OStringLiteral):
The one downside is that OUStringLiteral now needs to be a template abstracting
over the string length. But any uses for which that is a problem (e.g., as the
element type of a container that would no longer be homogeneous, or in the
signature of a function that shall not be turned into a template for one reason
or another) can be replaced with std::u16string_view, without loss of efficiency
compared to the original OUStringLiteral, and without loss of expressivity.
The new OUStringLiteral ctor code would probably not be very efficient if it
were ever executed at runtime, but it is intended to be only executed at compile
time. Where available, C++20 "consteval" is used to statically ensure that.
The intended use of the new OUStringLiteral is in all cases where an
object that shall itself not be an OUString (e.g., because it shall be a
global static variable for which the OUString ctor/dtor would be detrimental at
library load/unload) must be converted to an OUString instance in at least one
place. Other string literal abstractions could use std::u16string_view (or just
plain char16_t const[N]), but interestingly OUStringLiteral might be more
efficient than constexpr std::u16string_view even for such cases, as it should
not need any relocations at library load time. For now, no existing uses of
OUStringLiteral have been changed to some other abstraction (unless technically
necessary as discussed above), and no additional places that would benefit from
OUStringLiteral have been changed to use it.
Global constexpr OUStringLiteral variables defined in an included file would be
somewhat suboptimal, as each translation unit that uses them would create its
own, unshared instance. The envisioned solution is to turn them into static
data members of some class (and there may be a loplugin coming to find and fix
affected places). Another approach that has been taken here in a few cases
where such variables were only used in one .cxx anyway is to move their
definitions from the .hxx into that one .cxx (in turn causing some files to
become empty and get removed completely)---which also silenced some GCC
-Werror=unused-variable if a variable from a .hxx was not used in some .cxx
including it.
To keep individual commits reasonably manageable, some consumers of
OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat
odd state for now, where they don't take advantage of OUStringLiteral's
equivalence to rtl_uString, but just keep extracting its contents and copy it
elsewhere. In follow-up commits, those consumers should be changed
appropriately, making them treat OUStringLiteral like an rtl_uString or
dropping the OUStringLiteral overload in favor of an existing (and cheap to use
now) OUString overload, etc.
In a similar vein, comparison operators between OUString and std::u16string_view
have been added to the existing plethora of comparison operator overloads. It
would be nice to eventually consolidate them, esp. with the overloads taking
OUStringLiteral and/or char16_t const[N] string literals, but that appears
tricky to get right without introducing new ambiguities. Also, a handful of
places across the code base use comparisons between OUString and OUStringNumber,
which are now ambiguous (converting the OUStringNumber to either OUString or
std::u16string_view). For simplicity, those few places have manually been fixed
for now by adding explicit conversion to std::u16string_view.
Also some compilerplugins code needed to be adapted, and some of the
compilerplugins/test cases have become irrelevant (and have been removed), as
the tested code would no longer compile in the first place.
sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". That place, as well
as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and
i18npool/source/localedata/localedata.cxx, which have been replaced with
OUString::Concat (and which is arguably a better choice, anyway), also caused
failures with at least Clang 5.0.2 (but would not have caused failures with at
least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile
been fixed).
Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I473956d570feac508e52a3e52cc26cc154f4dc56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101627
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
This is a prerequisite for making conversion from OUStringLiteral to OUString
more efficient at least for C++20 (by replacing its internals with a constexpr-
generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount,
conditionally for C++20 for now).
For a configure-wise bare-bones build on Linux, size reported by `du -bs
instdir` grew by 118792 bytes from 1155636636 to 1155755428.
In most places just a u"..." string literal prefix had to be added. In some
places
char const a[] = "...";
variables have been changed to char16_t, and a few places required even further
changes to code (which prompted the addition of include/o3tl/string_view.hxx
helper function o3tl::equalsIgnoreAsciiCase and the additional
OUString::createFromAscii overload).
For all uses of macros expanding to string literals, the relevant uses have been
rewritten as
u"" MACRO
instead of changing the macro definitions. It should be possible to change at
least some of those macro definitions (and drop the u"" from their call sites)
in follow-up commits.
Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2dd10873be73256a3689233c7b1e37bde8f685ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100820
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Add some API to O*StringLiteral, to make it easier
to use in some places that were using O*String
Change-Id: I1fb93bd47ac2065c9220d509aad3f4320326d99e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100270
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ica7e5d3b5a5cec065f35f99d62b3b6604323601a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100009
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: Ia86a4cc06819ce5820ab44d293790f7bd9a03711
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99224
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to make the ongoing convert-to-UNO-constructor work easier
Change-Id: I99596561832b10538505cf4dfdabaf11d6e4d7cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98664
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id9301e65bea34c0edd9aadab85b848117e05075e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97710
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
NeonSession::NeonAuth requires an AuthListener to be set in the
RequestEnvironment (RE). After a HTTP 401, the Negotiate challenge should be
handled. The whole RE however is reset in HandleError, which is called after
every request. Usually, this is not a problem because the RE is re-set at the
beginning of almost all requests (PUT, GET, PROPFIND, ...).
But when refreshing locks this is not the case, as the LockStore does not know
any RequestEnvironment.
NeonSession::NeonAuth is then called in a post-send hook after a HTTP 401, the
AuthListener is null and in consequence Neon's ah_post_send does not return
NE_RETRY. So there will be no retry with the correct authorization header.
This patch removes the reset of the RequestEnvironment in HandleError, thus
keeping it in the session for further use.
Change-Id: Ib1a5eff08072f9ef003e760c5f40d9ad26c6cad1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96191
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
With commit 58b84caca87c893ac04f0b1399aeadc839a2f075, the NeonSession.LOCK
returns "theRetVal" from ne_lock_refresh when successful. But when there
is no error, theRetVal will be NE_OK, which is 0, so the method returns false
instead of true.
This results in lock refresh being stopped after the first refresh,
so WebDAV servers will unlock the file after the lock timeouts. Users will
see error messages regarding lock timeouts and lost updates are possible.
Fix this by adding a return statement when theRetVal == NE_OK.
Change-Id: Ie43131fca96e1cfbe932444906b742958a719b26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96023
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Drops some of the LO patches upstreamed since 0.31.0.
Version 0.31.0 introduced an new session flag for MS SharePoint
compatibility, NE_SESSFLAG_SHAREPOINT, which enables a few
workarounds, where SharePoint breaks the WebDAV RFCs.
In 0.31.1 a compiler warning and the MD5 ABI break introduced in
0.31.0 are fixed, so LO can now update neon.
Change-Id: Ia79ce530271664c0e6bab30a5e2516319da328d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91070
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I644d5e418028b4b4e66cf67b20a1155a689acab0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93906
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Prevent a feedback-loop, where LibreOffice would request a shorter timeout on
each refresh.
WebDAV servers do not return the lock-timeout the lock was set up with; they
have to return the remaining time. There are WebDAV servers that return a lower
timeout. Two examples [2] [3]. Other servers probably reuse the same timestamp
for the whole request and are therefore not subject to that problem. (This might
even be incorrect if the request takes very long.)
Updating the lock-timeout with the value returned by the server decreases the
timeout until it reaches zero.
LibreOffice request SERVER response
LOCK(180) -> LOCK(60)
LOCK(60) -> LOCK(59)
LOCK(59) -> LOCK(58)
...
0: no LOCK header -> FAIL
If we do not update the timeout in NeonSession::LOCK() only the initial setup
updates the timeout.
LibreOffice request SERVER response
LOCK(180) -> LOCK(60)
LOCK(60) -> LOCK(59)
LOCK(60) -> LOCK(59)
...
It is essential that lastChanceToSendRefreshRequest uses the timeout returned by
the server; after it calculated the deadline, we reset the timeout.
The maintainer of neon confirmed that the timeout should stay the same after the
initial setup. [4].
[1] https://tools.ietf.org/html/rfc4918#section-6.6
[2] https://www.alfresco.com/
[3] https://github.com/mar10/wsgidav
[4] https://github.com/notroj/neon/issues/12
Change-Id: Ie76338f7a88f41f47569a62ea6efec8c6f646f50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92981
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
E.g., it happened to be this string with Cyrillic characters in my testing:
SSL handshake failed: Удаленный хост принудительно разорвал существующее подключение.
Change-Id: I4721560412ab6543206cd13c8729dc8cc851eefd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91905
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...following up on afad46c4e891359aad7a829e704e627e1039fc33 "crashtesting:
assert on loading fdo102527-1.html" (and partially reverting it).
Loading that fdo102527-1.html as of today causes LO to send a HTTP GET request
for <http://aplikasikita.com:80/styles/style.css%E2%80%9D> that is answered by
> HTTP/1.1 301 Moved Permanently
> Connection: Keep-Alive
> Date: Fri, 03 Apr 2020 06:59:55 GMT
> Server: LiteSpeed
> Location: https://aplikasikita.com/styles/style.css”
> Vary: User-Agent
(i.e., the "Location" header value containing the three octets %xE2 %x80 %x9D).
Change-Id: I14a3e94013d584e793fad24196f1f01cd411be55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91610
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3978a2570f61c68fe080c6143924fcacee0784fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91530
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I02fe3f93edf94829b4456df2e8a7740698cf5263
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91066
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This reverts commit d8f8b4375998b62431c8605004e7c7d5c921ccc9.
Change-Id: Iece88b16cfb2e4ff18dd82bbf6624dc64a33cebf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90519
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|