If we increase the remote screen size from the server in such a way that
it no longer fits the browser window, the browser will probably want to
show scrollbars. The same happens if you enable 'clipping' while the
remote is larger than the browser window. These scrollbars do, in turn,
decrease the available space in the browser window. This causes our
ResizeObserver to trigger.
If the resize observation triggers a requestRemoteResize() we will
overwrite the size and request a new one just because scrollbars have
appeared. We don't want that.
We can save the expected client size after resizing, and then compare
the current client size with the expected one. If there is no change
compared to the expected size, we shouldn't send the request.
Fixes issue #1616.
This was missed in commit 375f36c575,
probably because these unit tests still passed (due to the expectancy
was for the code to not act on the resize events).
This is no longer an issue on Google Chrome, tested on Chrome 96 on
Fedora 34, Windows 10, macOS 12 and Android 12. It is however an issue
on Safari on macOS 12.
Without this workaround we get scrollbars when making the browser
window smaller, despite remote resize being enabled.
"Fullscreen", or more correctly "Full-screen", refers to the
adjective. In this case, we want the tooltip of the full-screen button
to refer to the noun "Full Screen" as this seems to be the convention.
Fixed eslint warnings
Improved memory usage of zrle decoding. Added unit tests for zrle decoding.
Added support for ZRLE encoding
Fixed eslint warnings
Reverted allowIncomplete changes to Inflator
Fixed failing tests for zrle decoder.
It seems that Firefox has a bug where these are fired incorrectly when
we are in an <iframe>. The events also contain no useful details, so we
can't really do anything useful with them anyway.
Chrome scrolls the view to show as much as possible of the canvas when
we call focus(), which is likely not the desired behaviour.
This also exposes the ability to pass on future options when focusing
the RFB object manually.
You can't include dependencies if you use the "stage:" or "prime:"
filters as they will also filter the files from your dependencies. This
is apparently per design and not a bug...
Apparently the new eslint version doesn't work with the older version of
node that we were using. Asking for '@v2' seems to help. It's unclear
what version of node we get now though since v2 isn't as verbose in its
output.
The way we work with these translation files means that we only care
about one step at a time, we don't want to update the .po files when
building the 'update-js' target.
Also, always force rebuilds of the .po and .json files.
These are used via CSS, which means the browser doesn't load them until
an element actually gets those CSS rules. There can be some delay to
this loading which causes visual glitches. By preloading we can make
sure those images are cached and ready when the status bar appears.
