Steps for reproducing the problem:
1) try to select some multi-line text
2) still holding the mouse button pressed move the mouse pointer
outside the browser window
3) release the mouse button
4) move the cursor back over the map.
Expected result: the selection should not change any more after the
mouse button has been released.
Real result: the selection changes when you move the mouse.
The same happens when you move the mouse pointer out of the tiles
covering, even if we are still inside the html document element area
where the map is embedded.
A similar issue occurs in view only mode when you drag the document: in
this case the problem occurs only when you move the mouse pointer out of
the tiles covering, but still inside the html document element area
where the map is embedded.
The behaviour described above is due to the fact that the map container
receives mouse events only when the mouse pointer is over the map.
The implemented fix checks for mouseout events which occur between a
tile element and a non-tile element (such as the the resize-detector
iframe, the scroll-bar container, the selection cursor marker). When
such an event occurs handlers for mousemove and mouseup events are
attached to the HTML document element and to the resize-detector iframe.
In the same way when a mouseover event occurs between a tile element and
a non-tile element such handlers are removed.
It was needed to attach handlers to the resize-detector iframe too since
the HTML document element seems to not be able to receive mouse events
that occur inside the iframe area.
A side effect of this fix is that now the text selection goes on
changing as far as the mouse button is not released even when the mouse
pointer is moved out of the tiles covering.
Since for an iframe the coordinates embedded in a mouse event are
relative to the iframe area, it was needed to implement a workaround in
order to avoid sudden changes in the current selection or in the
document position when the mouse pointer moves out of the map.
Improved search behavior for text documents:now when a normal search is
performed with the same search string utilized by a previous searchAll
action, search results highlighting is not removed.
does not affect regular searches since it caches results only if
(this._docType === 'presentation' && count > 1) and clears cache on
mousedown
Change-Id: I5569424df6e463da0c63166eef36842fa7d32f0e
So we insert the image (close to or even exactly) at the drop position,
instead of the last cursor position, which may be far away.
With this, we're closer to the desktop image drop behavior in the
browser.
LibreOffice may trigger invalidation of a part that is not current (eg. during
the part switch). But as we don't need the old data, discard such requests.
We iterate over an array provided by the browser, let's always use HTML
and not plain text, even if the array contains plain text first, and
only then HTML.
It usually happens that we get more "invalidateTiles" requests
from LO for one change. To avoid unnecessary tile rerenders we
remember (in transientInvalidationKeys) all tile keys which we
send to the server for rerendering and don't send the request
for the same tile. This is effective until we get back a
rerendered tile from the server (transientInvalidationKeys is
cleared).
(cherry picked from commit fdd76332db6b9c3b59864132578dc01ce19f0214)
