And few other improvemnts inluding:
* use svg instead of png for the menu
* add title (caption) for the Accept / Reject change.
Change-Id: Ic7e781d7e93d319f766b387a8eddfa70c1920760
Some older browsers don't have meta tag support for CSP. Lets put all of
the CSP in response headers to be compatible with oldies.
Change-Id: I7f0d7c294e492b3c69ebea6fbd820d6558b9c3b3
This is actually not a displaced cursor, but displaced tiles map pane.
It happens when the user refreshes the the document page and
before the document finishes loading, switches to some other tab and
then get back to the document when the document load finishes. In such
circumstances, due to browsers not emitting the 'resize' event (probably
because it didn't have the focus when the map loaded) we return
incorrect/unexpected map center. Because 'resize' event sets this._initialCenter to
null, so map.getCenter() never returns this._initialCenter and instead
return this.layerPointToLatLng(this._getCenterLayerPoint()) which seems
to be the correct thing to return here.
The reason that the displaced cursor is not
observed when user doesn't switch to other tabs is because of the
browsers emitting the 'resize' event before we set the map transforms.
Nevertheless, in some circumstances it is quite possible that this
event, 'resize', is processed after we set the transforms even though
user hasn't switched the tabs but probability of this is very less which
justifies this bug's hard-to-reproduce nature when user doesn't change
the tabs.
Instead of making sure that 'resize' event is triggered before we set
the transforms, removing this block of code that returns unexpected
return value (which we never seem to use anywhere anyhow) seems more
sensible thing to do.
Change-Id: Iff532a902e6100be7f39c204cbf2f28f1a7f6a49
Reviewed-on: https://gerrit.libreoffice.org/36458
Reviewed-by: pranavk <pranavk@collabora.co.uk>
Tested-by: pranavk <pranavk@collabora.co.uk>
When we are just interested in equality. compare() is more meant for
sorting functions where negative/zero/positive return value is useful.
Change-Id: I11138a14dc08e23d33f3848aeb734d9f56f3e9f7
The number of outstanding child forks can
become negative if more children are
spawned than requested.
This prevents such a scenario from
permanently preventing WSD from spawning
new children, which happens when
OutstandingForks is negative.
Change-Id: Ief1e56d7b4a079e097ca2d18bd90a01d935f6b30
Reviewed-on: https://gerrit.libreoffice.org/36437
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Commit 1e1f23716c fixed this already by
introducing by-value parameters, but
8a1f321c84 broke it. Fix this again, this
time more explicitly.
Change-Id: If29250ac2e99855796935b5cc05ccb222f8a4ad5
Reviewed-on: https://gerrit.libreoffice.org/36436
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
I don't think we should leak our address
(which mostly is behind a WOPI host and end-user
has no idea of what host LibreOffice Online is running at) in the
Referer header. Lets be more strict here and don't leak our address
at all.
Change-Id: Ibc30e9b64e2e06e2e8d541c5f089320ecb11412b
Though this guard the user against MITM attacks, but enabling this also
has the potential to brick your websites. So, do not use it/enable it
without understanding what it actually is.
See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning
Though this should work, but I have not been able to test it because of
Firefox and Chrome's limitation/feature that key validation is not done
when certificate chain terminates at a user-defined trust anchor and I
couldn't find any way to temporarily enable the HPKP key validation for
such CA chains.
Change-Id: I64d4ff82b04c59642fa7b8bac2f8788a03950b28
Reviewed-on: https://gerrit.libreoffice.org/36357
Reviewed-by: pranavk <pranavk@collabora.co.uk>
Tested-by: pranavk <pranavk@collabora.co.uk>
This reverts commit de2bc17c04af088d9c7e18a97216b174494e1a9c.
Lets not introduce any cleanup commits while we are near a release, will
apply it again after the release. The cleanup is supposed to not handle
the custom file server root correctly, so don't forget to test it with
a custom file server root before re-reverting.
It changes the path where loleaflet.html is searched for from
/usr/share/loolwsd/loleaflet/... to /usr/share/loleaflet/...
and doesn't find it there.
Change-Id: I23940e9a3e06721f0a8b7493a526f42d2072cfa4
Don't show the "This is embarrassing" popup before
first trying to reconnect at least once.
In most cases reconnection is successful transparently.
However, if necessary, we could add some delay to
reconnecting to give the server time to recover,
but without good reason for this complication it's
unwarranted. Server-recycling reconnections have
such a delay.
Change-Id: Ic8e32c451429a24f8362431672057145a492a23f
Reviewed-on: https://gerrit.libreoffice.org/36328
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
There was an interesting race when we cleared the
inBuffer after the WS upgrade. Since during the
upgrade we also transfer the socket to the DocBroker,
which has its own poll thread, the DocBroker poll
could trigger a POLLIN event if data comes
while the handler (that is handling the WS upgrad
and transfer to DocBroker) hasn't got to the point
where it clears the inBuffer of the data we just
read (i.e. the HTTP GET request). Even if not
the case, after transfering a socket to another
poll thread the socket buffers should not be
touched.
Here we move the inBuffer clearing to be as soon
as we have successfully parsed the request and
are ready to process it.
Also, we don't clear the full buffer, in case
we had read into the buffer both the requst
and the first message, if the thread was switched
out right after getting the POLLIN but before
reading from the socket, giving enough time to
receive more data and reading it together with
first read (which is the request).
Change-Id: I9888d4c2b70d2e433824818bbe7f69f13742486c
Reviewed-on: https://gerrit.libreoffice.org/36326
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
So failing that first assert doesn't give bogus
test duration.
Change-Id: Iaad2e5654e1264bd126193205b5218fd0f6637ef
Reviewed-on: https://gerrit.libreoffice.org/36324
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Apparently pinging was enabled only when
_not_ WebSocket upgraded, which is wrong.
Removed sending ping immediately after
upgrading to WS as it's superfluous.
Change-Id: Ic8103bab063d87f58d371f0eab49f7b7530e2374
Reviewed-on: https://gerrit.libreoffice.org/36322
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Don't think it is necessary/useful to have this header at other places.
This is the most important and perhaps the only where presence of this
header is required and seems sensible to prevent potential attacks.
Change-Id: Iad318e4b83264ac83620b86a40a49e7384e4015e
No idea why it was here in the first place, but download requests are
only made from frames with same origin, so there should be no need to
specify such headers which allow anyone (with other origins) to make
download requests to us.
Change-Id: I314a7ad4c6df8664b1d191cb88ae42c4248ff517
We need to be able to create iframes sometimes with same origin as ours,
eg: when loading the 'loading' page during slideshow or downloading the
file (in different formats). The 'blob:' is only used for printing
purposes.
Change-Id: I93666ee45e707997969e151af5142efeeca0d177
insertfile post requests should be made only from our origin.
Mentioning a '*' against allow-access-allow-origin allows other origins
to be able to make requests to insertfile too provided the attacker
knows the doc key which is not very hard to guess/get.
Change-Id: If98351df48935cfcdc18d6879167c0ac6089796c
