window.PointerEvent is available even on non-touch devices in
chrome and Edge (and maybe others too, firefox doesn't have it).
So it results in L.Browser.pointer resulting in true on Chrome,
Edge while false in firefox which leads to click event not
working on these browsers.
Fallout from a0036f24ba
Change-Id: I73b5824882e1cc1f87cdfbc9e7e31f22320367b1
MS Edge seems to be very problematic when one tries to load the
pdf blob into the print iframe and issue a print command to it.
Lets fallback to print prompt as we have in firefox
Change-Id: I97fc394d0053030231c524efb6bf808d32a9aa07
Removing this._printIframe may still cause leakage here as
this._printIframe is overwritten everytime user issues a print
command.
Change-Id: I06f45604940380b809bc262f07b9b6a8aa7d9a87
To avoid degrading performance for everyone
because of a single slow/bad connection, we
send data to clients each in its own thread.
Change-Id: I6f980c25a404c4d05bcdb1979849ea3d2776c7b9
Reviewed-on: https://gerrit.libreoffice.org/31984
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
The call to the setRaw() virtual function during construction will not
dispatch to derived class, so the ctor is correct only in case there are
no subclasses.
Change-Id: I484d276dd05e53211b513373100b70586a5857c0
using these WOPI protocol extensions: DisablePrint,
DisableExport, DisableCopy. All assumed to be false if not
provided.
Change-Id: I415597d710107f9d8cbb8757f361365cc2a88eb1
We want document owners (sessions with their WOPI UserId =
OwnerId) close the document (for all sessions) only if
EnableOwnerTermination property is specified. Note that
EnableOwnerTermination is an extension to WOPI, and not part of
original WOPI standard.
Change-Id: I7237d172c4c54477572bc132336910250af075a3
If the socket is in error, SELECT_READ returns
immediatly as failure. In this case we sit
in a tight loop polling read over and over.
We now check for SELECT_ERROR when SElECT_READ
fails to properly close the socket and break.
When receiveFrame returns -1, we should first
check the flags for socket close, as that
is a legitimate case of returning -ve.
Change-Id: I7bbc948638a8395d28990ba92eddb9a1a9f1e6f2
Reviewed-on: https://gerrit.libreoffice.org/31932
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Top level make would now build loleaflet too if necessary.
Respect value of ENABLE_DEBUG and if present add debug-info to
generated js bundles too.
Add new rule, clean-local in loleaflet.
Change-Id: I3a9b727824f2877fc72719a8bfdeebed5448cb7d
This always takes ~2 seconds irrespective of whether node_modules
needs updating or not. Lets add appropriate dependencies and save
these precious 2 seconds.
Change-Id: Ided4ff334316c16521e5ea7a69d15736a1cc170f
Use events, 'hidebusy', 'showbusy' to interact with toolbar.
In some cases, it may happen that w2ui usage in loleaflet happens
before browser loads w2ui.js (as it is in <script> tag after the
one which loads loleaflet).
Change-Id: I9b1b249ede72ed01f97cf31fd3f93780312530bc
The pool is checked for expansion before processing
items from the queue. By tracking the number of idle
thread (i.e. not currently sending data) we ensure
that there is at least one idle thread before
we invoke the socket.
If there is not enough idle threads at that point,
a new thread is spawned, so long as we're below the
limit. This guarantees that even if all the active
threads block on the socket, we'd always have one
more to process new data (until we reach the limit,
which is as many client connections as we have).
Technically, a single slow connection could
still monopolize all connections if there are
many messages to be sent to it. For that we'd
need to track and assign one thread per connection,
something we don't currently do.
Change-Id: Ic8b5e064da068b37bcfa773005495b198763c31d
Reviewed-on: https://gerrit.libreoffice.org/31886
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This adds SenderQueue and a wrapper of messages to
send back to clients.
Currently no threading takes place, but the messages
are pumped through the queue nonetheless.
Change-Id: Id9997539c0a2a351cbf406f649c268dd3643e88e
Reviewed-on: https://gerrit.libreoffice.org/31883
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
