Util::createRandomDirectory now uses /dev/urandom
(and a complex pseudo-random generator where missing)
to generate 64-byte long, Base64-encoded, names.
This should provide ample security compared to 64-bit
pseudo-random numbers hex-encoded, as was the case.
Change-Id: I714810a9fb03b5dcdbad7a15305940bf7457149e
Reviewed-on: https://gerrit.libreoffice.org/25696
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Since rendering moved to centralized WSD<->Kit
processing, it runs on a different thread than
those processing the communication between
ClientSession and ChildSession. This introduces
a new race between events and tile rendering.
The shared ChildSession lock prevents this race
such that no events are processed while a tile
is rendered and, more importantly, response
is prepared and sent back. That preparation
could be lengthy due to png compression.
The typical race happens when two keystrokes
are entered in quick succession such that the
same tile is invalidated while it's rendered.
If the invalidation is processed in parallel
to rendering, it will find no cached image to
remove. It will reach the client, who will
request a new tile. Meanwhile, the first tile
is rendered and cached. By the time the second
request arrives we have a cache hit, albeit on
an outdated tile, missing the second character.
By locking until the tile response is sent we
ensure that the invalidate event will follow
it, and by then the image will have been cached.
The invalidation then removes the cached image
and the second tile request is forced to place
a new tile render request.
There is some inefficiency, it would seem, but
that is not really true, as Core is really
sequential anyway and we shouldn't process
events in parallel in the first place.
Change-Id: Id8170a41a7e69bca6ac8b520029b7cdb2d96c880
Reviewed-on: https://gerrit.libreoffice.org/25662
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
When conversion fails we still have to put
something in the save-as queue to avoid
hanging WSD forever.
Reviewed-on: https://gerrit.libreoffice.org/25618
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
(cherry picked from commit 0c6887c744fcd811728de43a971ee9c964d86e8e)
Change-Id: Ibc518bc922ee40f579a71e07571b21d9e633d998
Reviewed-on: https://gerrit.libreoffice.org/25623
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Such a huge confusing diff is mainly due to moving of functions from bottom
to top because a function should be defined before it is used.
Other changes include using single quotes for strings, and other
minor style fixes.
Change-Id: Ieb8e5054a9c8113ec211973e086111d91759f80b
Till now we have only been linting our src/ directory. toolbar.js
is the only file we edit directly in dist/. Lets keep a check on
it too.
Change-Id: I3e8a6e675a1d0c508339db1363600b5fe8f9c2cd
The top left corner of dropdown table widget is near to the mouse
position where the user clicks. If Insert table button is too close
to egde of screen, it cannot be drawn properly.
- Use css for highlight cells.
- Close insert-table dialog on mouse leave.
- Better GUI
- More jQuery
Change-Id: I35e25f4ff150e373e70e7b14aa434d1dc055746a
Set the min-width of window to 600px so that all select list
boxes remain in main toolbar, and not go in toolbar-more.
While resizing the toolbar, if the user tries to reduce the
window width past the min-width set, we would run into an
infinite loop causing spike in browser CPU usage and eventually
crash. This used to happen earlier also before setting this
min-width with very small browser window size.
Also simplify the toolbar resize algorithm. Rather than using raw
jquery methods to move items from one toolbar to another, use
library's (w2ui) methods to add/remove items from toolbar. This
also requires the need of proper initialization of few buttons
such as color picker, table picker because moving item from one
toolbar to another strips off the initialization corresponding to
these toolbar buttons and these need to be reinitialized. Moving
such initialization to onRefresh, hence, would keep them
initialized whenever toolbar is resized.
This also solves one major problem with enabled/disabled state of
toolbar buttons. Since, now, we are actually moving the items
from one toolbar to another, we can enable/disable them using
toolbar's methods ie. enable(), disable().
Change-Id: I64fb0a9d7761f66701bc0e020d1dbad9e4defe29
Use an object to keep track of enabled/disabled state of buttons.
This also prevents us looping all the format buttons everytime a
commandstatechanged is received, so better algorithmic
complexity.
For sessions in view-only mode, keep storing the state of these
buttons in this object, and use the stored states to
enable/disable buttons when edit lock is taken.
While enabling/disabling the toolbar buttons, also check in
toolbar-more.
Change-Id: I6555fde6669e1a8ba349c3213280a627a05d80b7
The gif spinner had a white background flashes in its frames, so
it always needed white background behind it. With this, we will
have no such restriction, can can have transparent background.
Change-Id: I1faffa326ae85114e52231cc4e33d84c7ac0675d
