Bug:
When a parent and a child comments are removed then user reverts the action respectively:
* Child comment is revived first and it cannot find its parent.
* Add a possibleParentCommentId to use in case also the parent comment is revived.
* Consider the child comment as a parent until parent appears.
Other changes:
* Remove duplicate call to updateIdIndexMap.
* Remove duplicate call to unselect.
* Remove duplicate call to adjustParentAdd.
* Reorder the 'remove' operation's rows: To avoid unselecting the comment after it is removed.
Signed-off-by: Gökay Şatır <gokaysatir@gmail.com>
Change-Id: I2247b23c710236c578b5b5c78d2b7bb45f7a51b4
problem:
while resizing row/column it would select all the rows and column user hovers over
regression from: 87a55af
Signed-off-by: Pranam Lashkari <lpranam@collabora.com>
Change-Id: If786c57222b9bb89ac3faa1e645acc223a8dcd7e
disable this with VCL_NO_THREAD_SCALE for wasm
"Yacht.odt" document with lots or large images fails to
render:
Tried to spawn a new thread, but the thread pool is exhausted. This
might result in a deadlock unless some threads eventually exit or the
code explicitly breaks out to the event loop. If you want to increase
the pool size, use setting `-sPTHREAD_POOL_SIZE=...`. If you want to
throw an explicit error instead of the risk of deadlocking in those
cases, use setting `-sPTHREAD_POOL_SIZE_STRICT=2`.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I8b2f994d2d3d23f8a0043f0c7fefa4d5e250b8bc
ClientSession::handleTileInvalidation returns early with _tileWidthPixel
(etc) of 0 because _tileWidthPixel (etc) never get set
These are supposed to get set from 'clientzoom' which the javascript
side sends. clientzoom arrives, but the attempt is made to dispatch via
a thread and during startup there are enough messages dispatched via
threads to overwhelm wasm
bundle.js:56376 ================ handle_cool_message(): 'clientvisiblearea x=-3915 y=0 width=20640 height=7980 splitx=0 splity=0'
bundle.js:56377 Tried to spawn a new thread, but the thread pool is exhausted.
This might result in a deadlock unless some threads eventually exit or the code explicitly breaks out to the event loop.
If you want to increase the pool size, use setting `-sPTHREAD_POOL_SIZE=...`.
If you want to throw an explicit error instead of the risk of deadlocking in those cases, use setting `-sPTHREAD_POOL_SIZE_STRICT=2`.
bundle.js:56376 ================ handle_cool_message(): 'clientzoom tilepixelwidth=256 tilepixelheight=256 tiletwipwidth=1536 tiletwipheight=1536'
bundle.js:56377 Tried to spawn a new thread, but the thread pool is exhausted.
This might result in a deadlock unless some threads eventually exit or the code explicitly breaks out to the event loop.
If you want to increase the pool size, use setting `-sPTHREAD_POOL_SIZE=...`.
If you want to throw an explicit error instead of the risk of deadlocking in those cases, use setting `-sPTHREAD_POOL_SIZE_STRICT=2`.
bundle.js:56376 ================ handle_cool_message(): 'tilecombine...'
The 'clientzoom' never get processed and so
ClientSession::handleTileInvalidation returns early with _tileWidthPixel
(etc) of 0 because _tileWidthPixel (etc) never get set.
this std::thread dispatching of messages is similar to seen in
gtk/mobile.cpp in similar code, and also existed in
android/lib/src/main/cpp/androidapp.cpp before getting replaced
in:
commit 155718796e
Date: Fri Jul 19 16:43:44 2019 +0200
android: Fix a threading / ordering issue.
follow the same simpler android model here.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I3b5e57b3d91bb80fbae90b269300581825518d7f
- We should fire `active` state call back for selected color value in filter by color
- it will directly apply filter to columns
- this change is consistent with LO
Signed-off-by: Darshan-upadhyay1110 <darshan.upadhyay@collabora.com>
Change-Id: I90977cff67cda1bca78c7d60c132bd0685cadbaa
We were using old cursor data after recovering the
view from idle state. For the user there was impression
that view jumped at some point - caused by other user
action. But it was just an update to real cursor position
which scrolled view to it, because previously we were showing
some other place in the spreadsheet.
Steps to reproduce bug:
1. Open spreadsheet with 2 views
2. B should have cursor in the bottom part of sheet, let's say row 600
3. Wait for idle in both sessions
4. Open the same spreadsheet with some other user C
5. C does some action on row 300 and goes away (closes tab)
6. User B activates view and selects row 600
7. User A activates view (he should be at the top still)
8. User B changes font size using dropdown in notebookbar, or double
clicks on any row header
Result: view A jumps to other place
When we initially connect to the spreadsheet then
requestCellCursor is called in onAdd. Also
_gotFirstCellCursor is not set.
Let's do the same on reconnect so we will have similar
effect to clean startup.
Signed-off-by: Szymon Kłos <szymon.klos@collabora.com>
Change-Id: I84c6ab705bc83d5c0d5c80325ec67c3f55aa19d8
Since core commit 690d4eb71509649ad147cfe60f5b97e2cfaaa519 (tdf#43100
tdf#104683 tdf#120715 sw: cursor on spaces over margin, 2022-07-04)
the cursor travels outside of text body area in Writer. Desktop view
doesn't follow the cursor in that case; the problem in Online was
that its view did follow the cursor. This resulted in the following
scenario:
1. Have a document with a thousand of trailing spaces in some line,
before a word that would appear on a next line;
2. Put cursor to the beginning of that following line;
3. Press backspace (or left arrow key)
This resulted in the view jumping far to the right, with the page
being completely out of the view; the user only saw an empty screen
without any text, which was highly confusing.
Fix this by limiting the coordinates in _onUpdateCursor; use known
document size for that. This could still be problematic in case the
document has different-sized pages: the current page bound could be
narrower than document width. Yet, this seems to not be a big deal:
the view will likely still include part of a document, giving the
user a clue. An alternative would be to pass current page size with
invalidatecursor message from core.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I4d6cba7105d5aa2d1847bcb3994f93248b3f5ec6
Adjust height values of the slide sorter content element
Change-Id: I04fdb5f89f70b703385e61253bf8ea8a387a65ea
Signed-off-by: Henry Castro <hcastro@collabora.com>
There was a bug in Writer not allowing to successfully reconnect
after idle state if we were not a first view in the initial document.
Let's update view id even if document size wasn't changed.
Added also additional error logging to be sure we never use -1 viewId which is
a default "bad value" when we enter some unwanted state in the core.
Steps to reproduce:
1. set per_document.idle_timeout_secs to something small, eg. 30, so sessions time out quickly,
2. Open a document with 2 sessions (remember which one was loaded first - A, important!)
3. wait for it to idle out in both sessions
4. activate SECOND session (B) by click on the document area
Result:
in the browser console you can see an exception:
Exception TypeError: this.map._viewInfo[this.map._docLayer._viewId] is undefined emitting event viewinfo: [{"id":0,"userid":"2","username":"LocalUser#2","readonly":"0","color":411298}] cool.html:359:37
Signed-off-by: Szymon Kłos <szymon.klos@collabora.com>
Change-Id: I23775230e169f61cb816b819f2dea56e293b20e1
To manage latency, we need to keep the amount of data-in-flight
manageable, this was previously done per-tile - however this is
less useful in the era of small deltas, and seems over-complicated.
Instead track processed tiles by their wire-id to save time,
space & bandwidth.
Change-Id: I1039d8d4ca96fb172278a824fe1ffd55d9fff23e
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Accurate per client tracking of wire-id and avoidance of duplicates
is vital for good delta application, and is done precisely by the
ClientDeltaTracker class.
The inaccurate, _oldWireId tracker imperfectly tracked wireids of
the last tile per session, and used this integer for the boolean
oldWireId used to determine whether to create a delta; in an
un-necessarily complex way.
Instead we more accurately use the TileCache to determine if we
already have a key-frame, and if so use this to encourage Kit to
generate a delta if possible. there seems to be a potential race
though between the Kit's delta-cache size, and what keyframes
we have in the TileCache requiring further investigation, but
this is not a new issue.
Change-Id: If6cec4c1da31f7b715336c60d1dd6f358e1ef6a4
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Instead throttle rendering only based on the number of tiles on
the fly down the coolwsd <-> browser socket.
It is almost certainly better to let the Kit process sort and
prioritize rendering with a more holistic view of all rendering
requests, and to elide duplicates - rather than to stack-up some
requests in coolwsd.
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Change-Id: I566959306815ddc2742a0fe2694df6a1371c6852
This is in line with MOBILEAPP and GTKAPP and
is independent of __EMSCRIPTEN__.
Replace all application-specific cases, leaving
only toolchain-specific ones (such as include
protection).
Change-Id: Ic44288aa5ace51e0a8b54566170c19120f7bf0dd
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
We now have at least one C TU and enabling rtti for
the sanitized build breaks things. So we don't enable
rtti for C sources, which was done in error.
Change-Id: If7624993ceb9e7af7aa8ffe3df69069ea4dd153a
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
There's a bit of a mobile/wasm munge with wasm considered a subset
of mobile in some places which should be unwound a bit, but for the
purposes of usable wasm by default, don't assume that wasm has an
onscreen keyboard so we don't lose keystrokes on assuming that
there will be an onscreen keyboard appearing when we lose and regain
focus.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I0baae0d414ce9aafd1c27d74bcdad2276d104ee5
the default suggestion uses --enable-qt5 which isn't needed for
LOKit and breaks finding custom notebookbar widgets so online
notebookbar doesn't work with it.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I644924a0f8cdb01d4ec20d70ff7aedb27a2c899f
- previously, when document was getting idle, it was
showing a snackbar "The server is disconnected" which
unnecessary plus the snackbar was persistent even
after reconnection.
- There are two scenarios to be tested,
1. It shouldn't show snackbar on idle
- Set per_document / idle_timeout_secs to something small, eg. 30,
- Open a document, and wait until it idles out.
- make sure it doesn't show "The server is disconnected" snackbar
2. It should show "The server is disconnected" snackbar when you shutdown
the server, when you start the server again snackbar should disappear
Change-Id: I4ccc93dabb4dd260338d5a941b18ebaf8e42b1ad
Signed-off-by: Rash419 <rashesh.padia@collabora.com>
it was previously required to handle comment scrolling separately but not anymore
it was introduced in a3e59d1
current problem:
when a comment is very long that it overflows and has a scroll bar,
it is only possible to scroll using the scroll bar and mouse wheel didn't work
fixes#7735
Signed-off-by: Pranam Lashkari <lpranam@collabora.com>
Change-Id: I6d9f85c61b837f86e021a795e8af43b375a318d1
Original approach before comment autosave:
When we save a new comment, original DOM element which user was editing
is removed from the DOM and new comment DOM element is created from the data and message sent by core.
Previous comment autosave approach:
When we save a new comment, original DOM element which user was editing
is not removed but kept in editing mode. We register the comment message sent by the core
but react and create new comment DOM element only after user clicks on save or cancel.
This lazy initialization caused many regression due to juggling of the new and old comment DOM element.
All these problems were in JS side only, reloading doc would bring comment in correct state.
This approach gave smoother transition between different comment states without any flickers.
New comment autosave approach:
Simple as the original approach, when comment loses focus we save it as normal comment.
When new DOM element created via core comment message, we immidietly set it to edit mode.
This approach may have a little flicker when we replace old comment DOM element with new comment DOM element.
Overall this approach requires less condition checking which makes it easy to maintain and hopefully reduces any regression from previous method.
Signed-off-by: Pranam Lashkari <lpranam@collabora.com>
Change-Id: I4098085825ede65cdbf2e2243fc4d2bb1f63c716
