From websockify/websocketproxy.py , python http.server module is imported. This module loads a do_GET() -->>send_head() method from SimpleHTTPRequestHandler class https://docs.python.org/3.10/library/http.server.html#http.server.SimpleHTTPRequestHandler.do_GET which eventually results in the directory listing of all items in the current directory from which its original caller was run ( if no index.html or index,htm file exists in that directory ). Otherwise it serves a http 404 response on listdirectory failure.
A possible but unclear fix to bypassing current directory item listing is to run websockify directly https://github.com/novnc/noVNC/issues/294 . Another but not encouraged solution is commenting the "else" block in send_head() method in python http.server.SimpleHTTPRequestHandler class to ignore "index.html" or "index.htm" file to force a http 404 response.
Code:
....def send_head(self):
....
....if not parts.path.endswith('/'):
....
....for index in "index.html", "index.htm":
....
....#else:
# return self.list_directory(path)
The more better solution would be to include an "index.html" file in the parent folder "~/noVNC". This makes customization endless and creates more possibilities for user preferred landing pages.
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.
Kozuki