if the part is not hidden. The member _selectedPart is already set
to the new part in Parts.js's setPart(), as a result the code inside
the if was never getting executed. There is no need to call
map.setPart() as this was also done in Parts.js setPart(), and finally
there are no handler for 'setpart' event as of now, so lets remove the
fire() call too. All of this was not a problem when the
'.uno:ViewRowColumnHeader' data source was used, because that data
was getting requested unintentionally as part of related scroll events
during a sheet switch.
Change-Id: I3ea3916ba738d9616e822659fc64903eda8f99cf
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97952
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
(more details in the comments)
This can help in a corner case (very improbable though) when we query
for the exact end-position of a span with trailing empty span. Lets do
the right thing, even if that does happen only extremely rarely.
Change-Id: Ib1370811c257e6ef3d52d29caf2963641bad8e40
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97951
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
as it was before 317afcecb4
This 'adjustment' was just meant for refreshViewData() or whatever it
was called before, to indicate that both column/row headers/gridlines
should be updated, no matter what the actual offset is (probably only
meant for zoom changes?). The offset passed to refreshViewData is only
going to be used as a boolean flag.
This patch fixes the row/col headers getting a off-by-one pixel when
changing zooms with the new data-source (.uno:SheetGeometryData). If
using the older source (.uno:ViewRowColumnHeader), this bug is hidden
because of the delay for fetching the JSON everytime before painting the
headers.
TODO: Refactor all calls of refreshViewData to get rid of the 'offset'
and this adjustment code and only send the boolean flags to
refreshViewData().
Change-Id: I4c30e8f06a6a2d58b9a9a89e283d7a214d00b99c
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97948
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
otherwise the header controls won't have the right position info
when refreshViewData causes an ~immediate header/gridline rendering
(.uno:SheetGeometryData source). This was not a problem in case of
.uno:ViewRowColumnHeader source, because of the roundtrip delay for
getting the msg from core.
Change-Id: I48298dbfb8d62acc64adbfd662a5304b856d702a
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97946
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
We may need to have a dedicated sheetgeometrychanged msg for geometry
changes like change of col/row sizes, hidden/filtered, groups/outline
states.
Change-Id: I45a8038546c66797aed4b58f11c6450cbe6e2965
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97945
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
And lets not unnecessarily extend the cellrange in the view as the
computation is accurate.
Change-Id: I62de80ce42430c62a399d4e39bafab7896217bf1
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97943
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
to parse, store the .uno:SheetGeometryData JSON efficiently although it
is optimized for fast querying. L.SheetGeometry is the external class
that exposes all necessary sheet query interfaces.
Change-Id: I24df8d85734a6cdf9c393fd2c3c5ed4de0ea29f3
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97940
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
from L.Control.Scroll to a new method requestViewRowColumnData() under
L.CalcTileLayer which is arguably a more appropriate place for it and
change all the places that calls map.fire() to emit
'updaterowcolumnheaders' to call the new method directly.
This helps to improve the code readability a bit by being more explicit
and also avoid an unnecessary indirection while code grepping.
This also makes it much easier to introduce the change in data source
from .uno:ViewRowColumnHeaders to .uno:SheetGeometryData by avoiding
lots of abrupt changes in one go.
Change-Id: Ia42d7586f06e28a5715fac278967a445089308af
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97939
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
On getting a .uno:ViewRowColumnHeaders message, the order of header
painting should be the headers elements first, then the cursor
indication on the header, then the selection area indication on the
header if any. More importantly none of these painting will be correct
if the data in the tickMap member of both headers is stale.
As of now all three of these are executed by three different events.
Lets avoid depending on the implicit ordering of execution of these and
do these synchronously as part of the main event
('viewrowcolumnheaders') handler.
Change-Id: I4da29ba893c408af45159073e4389481b2eaecc7
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97937
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
We can enable / disable autofiltering, but the
autofilter buttons are non functional on mobile.
Change-Id: I738a4565a8de1ec3c1f5ffe8b67c2edcacf7b324
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97866
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
It would open a tunneled dialog which is not supported on mobile.
Change-Id: I377adf5e5fbc2d52af52b373f9552c74cd9bd07a
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97865
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
with newer core version it changed a name
Change-Id: I3804f9f6e1acfc96123e4376aeb3b040deeebe4c
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97707
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
There is a race between the time we set the
renameFilename value and the uno:Save response
arrives. If renameFilename is not set by then
we miss the opportunity to rename and instead
simply end up saving the file.
Change-Id: I8d7acbc95cef264de4385d506bfa34458ba80283
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97189
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Tested-by: Jenkins
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
665b1629de was not correct, as it reported back
the save result of the internal save (which usually succeeds).
Instead we want to know the save result of the remote storage (WOPI/Webdav).
So report that back instead.
Change-Id: Iaaa42b8c817a19c2c77935a6f81c1951fdf2216c
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97637
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Current replacing url strings method works fine,
however, it does not cover all the rules
for cases like when @media or @import are used.
They have a subset of their own rules which must
be covered as well.
Change-Id: Ib10f7cc361aea5cd3b855f64e3a64566a6c51a12
Signed-off-by: mert <mert.tumer@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97071
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
This isn't a functional change, only making code more readable
and easiert to search.
Change-Id: I56c4b699782cfc997ae89b80add67c365e5b9009
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97334
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
When "perm:" message is sent, in case of PDF we send the payload
"perm: readonly", which is then parsed as " readonly" (with extra
space). If a proper "readonly" value would be parsed, JS would
get stuck, because the code assumes that "doclayer" is available,
which is not the case. So this fixes that the command is correctly
parsed and that it doesn't get stuck by not running the code that
assumes doclayer is available.
Change-Id: I35b6cc25209b4ed259f33f7fb77bc0be7a69033e
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97331
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
