This is so because we require this also when document is opened in
readonly mode and we don't have any toolbar in the readonly mode.
Change-Id: I085d1640f52843e01370d528d6eea656b743d908
Since during an edit conflict the undo/redo
buttons are dissabled (for the user who can't
undo/redo anymore) disabling the repair button
robs them of the ability to repair the document
to an earlier state (i.e. before the conflict).
This enables the repair button as soon as either
the undo or redo is enabled, whereupon it remains
enabled for the duration of the session.
Change-Id: Ibaf257155f721e2cef596e965d8812d381ab3a5b
Reviewed-on: https://gerrit.libreoffice.org/38942
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Seems to have no effect, so gone in
favor of RLIMIT_AS (virtual memeory).
Change-Id: I210879ec9285f420c9f9839cdabf45c42d865fb3
Reviewed-on: https://gerrit.libreoffice.org/38720
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Using it this way looks very fragile to me; let's just avoid this.
Change-Id: I7459f3b215f5f9930287566a1bd946a94e9b343b
Reviewed-on: https://gerrit.libreoffice.org/38512
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
... with no functionality attached to it except notifying the WOPI host
that button was clicked. Host is supposed to do the action thereafter
itself.
Also, notify the host when a save succeeds or fails.
Change-Id: I0daa2690af2259233840ea7ab4326b9b80d5fa87
In richdocuments, it was added in aa0a8f666ada8f1d1edae17b906089cc03ba473d
and then removed in 87f7720d12e130bd1c3cd9306ad1b1f4d784f9e6
It was added firstly way before WOPI was even there. But now since we
have WOPI, we wouldn't need it.
Change-Id: I786a3f7b2103a43995a70b53438d88a829d13265
When saving while editing a cell, the
document is saved with the new cell contents
(as the cell editing is interrupted and applied),
but the modified status is not published to the
client (loleaflet).
This has the unfortunate side-effect that the
EverModified flag is not set in this scenario.
To avoid this, this patch sets the EverModified
upon successful saving. This is easier than
forcing LO Core to emit ModifiedStatus=true
in the scenario above. Though it suffers from
the false-positive result when the user forces
a save. Although this is probably defensible,
since technically the document changes upon
saving (though not the content if there was
nothing new to save). On the other hand,
it's less harmful to signal modification
due to save than to ignore genuine
modification to the document.
Change-Id: I7ccba62731f534b69819f7924eeb9231d874c111
Reviewed-on: https://gerrit.libreoffice.org/38398
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Introduce a new header X-LOOL-WOPI-Timestamp
This is a WOPI header extension to detect any external document change. For
example, when the file that is already opened by LOOL is changed
in storage.
The WOPI host sends LastModifiedTime field (in WOPI specs) as part
of the CheckFileInfo response. It also expects wsd to send the
same timestamp in X-LOOL-WOPI-Timestamp header during WOPI::PutFile. If
this header is present, then WOPI host checks, before saving the
document, if the timestamp in the header is equal to the timestamp of
the file in its storage. Only upon meeting this condition, it saves the
file back to storage, otherwise it informs us about some change
to the document.
We are supposed to inform the user accordingly. If user is okay
with over-writing the document, then we can omit sending
X-LOOL-WOPI-Timestamp header, in which case, no check as mentioned above
would be performed while saving the file and document will be
overwritten.
Also, use a separate list of LOOL status codes to denote such a change.
It would be wrong to use HTTP_CONFLICT status code for denoting doc
changed in storage scenario. WOPI specs reserves that for WOPI locks
which are not yet implemented. Better to use a separate LOOL specific
status codes synced across WOPI hosts and us to denote scenario that we
expect and are not covered in WOPI specs.
Change-Id: I61539dfae672bc104b8008f030f96e90f9ff48a5
Instead, just disable the Help -> About choice if the 'about-dialog' div was
removed from loleaflet.html.
Change-Id: I997aa5489bcfbd02f56feb79bea14e92d3666bf2
The request was meant the other way around; let's just not present "About" in
the menu when there is no element with "about-dialog" id.
This reverts commit b9305d17ce.
UNDO_CONFLICT was intented to notify views, but
the constant value changed with latest patch upstream
Change-Id: I09062725539df3d974a47d89374d822d1d852770
When WOPI's CheckFileInfo or GetFile responds with status code other
than HTTP 200, show a message to the user indicating some problem in the
storage.
Currently, we open an empty document if storage doesn't return a
document which surely is not correct.
Mention the storage server address when asking user to contact the
server administrator to be more friendly.
Change-Id: I15f0489f36db8689b43d42f6b691fdd21815e4fa
Document broker needs to know when the save request is sent and when the
save finished. It uses these parameters to avoid shutting down document,
in the document broker main polling loop, if save is already going on.
But direct .uno:Save commands issued from
loleaflet precludes document broker to keep track of it - in this case a
.uno:Save command issued from loleaflet followed by closing the
session will prevent saving the document to storage, if document is huge
enough and LO core takes a bit of time to save it. A save wrapper
command, 'save', ensures that document broker is aware of all such save
requests (_saveRequestTime member variable) and doesn't close the
document until we completely save it (to storage and other cleanups).
Change-Id: I5ec73d45adff23b2e7543e93dfd0624a5e5af46d
Timeouts to dimming the doc in the browser
are now configurable from WSD and is relayed
to loleflet as expected.
Out of focus timeout is now 60 seconds.
Change-Id: I8452e30976f6a81b0c3bb3ba5774daa244c1640c
Reviewed-on: https://gerrit.libreoffice.org/37489
Reviewed-by: pranavk <pranavk@collabora.co.uk>
Tested-by: pranavk <pranavk@collabora.co.uk>
Bin the internal command state recorder to Menubar and use the global
state recorder available in the map.
Change-Id: I32e81700e38c2d544b2d874e6a30fbe58e8d43bd
... instead of having this logic in our toolbar. All the elements like
menubar or toolbar can then use the map store to see the value of last
state change event for any particular uno command. We will be using it
when menubar starts using this store.
The frivolous logic in toolbar of reading the value of last uno command
should be removed. We don't expect loleaflet to change the permission
dynamically after loading the document anymore. But for now, just change
it accordingly and defer the task of removing it when we refactor
loleaflet codebase to trim our permission model (remove the 'view'
mode).
Change-Id: I1be54a62e96179b7db3f61470a92e3ddc745f52d
The localization.json file contains path like 'l10n/lang.json' which
means path relative the html file being accessed. This works when we
access .../loleaflet.html but not so when we access .../admin/admin.html because
then it tries to access .../admin/l10n/lang.json while it should look for
this file one directory up. One could think to change the paths in
localization.json file to something like '/loleaflet/dist/l10n/lang.json' so
that same path is accessed always for loleaflet UI as well as admin, but
it has repercussions that we access l10n data always using 'dist' prefix
and not using git hash, so browser caching the l10n data across multiple
versions.
Ideal would be to split the admin localization completely from the
loleaflet-ui localization. No point in fetching whole of the loleaflet
localizations strings when we are only accessing the admin console. This
would also solve problem mentioned previously.
For now, just split the admin localization file only while still
allowing admin console to fetch the same l10n files.
Change-Id: I0824fb05b9b4123b58d6fd8edafb374ee7128229
No need as core renders its in-tile annotation marker now, if comment
indicator setting is on in the document.
Change-Id: I213827fc089790398e02b0fd9cba464ab62b0d8d
overflow-break property is enough for us which still allows inserting
line breaks arbitrarily anywhere but only if there is no otherwise
acceptable break points in the line.
Change-Id: I8ea94daba258b00caa259c97597cf1206a89fa64
