There has been a lot of development in upstream noVNC lately. ThinLinc's HTML5 client uses old noVNC code from 2016-09-05. Among the changes are fixes for the following: * Horizontal scroll (bug 5480) * Double buffering (bug 5611) * Incorrect position after panning (bug 5605) * No update after panning (bug 5610) * Can't use mouse and touch at the same time (bug 5983) * On-screen keyboard closed when using tool bar (bug 6007) * Can't move the control bar (bug 6126) * Can't hear the bell/beep (bug 6129)
Doing a vendordrop would also fix tearing issues: bug 6138
As part of this bug, we also need to: * disable the translation system in place in upstream code since it isn't up to our standards yet. * test keyboards after https://github.com/novnc/noVNC/issues/734 has been fixed
(In reply to comment #3) > As part of this bug, we also need to: > > * disable the translation system in place in upstream code since it isn't up to > our standards yet. Disabled in the big vendor drop commit r32157 > * test keyboards after https://github.com/novnc/noVNC/issues/734 has been fixed The change that broke this was reverted in commit r32158
The "The HTML5 client is loading" message does not go away even after the session started.
Hopefully all regressions are now ironed out. Resolving.
All done, closing this. The remaining testing is done on other bugs.
I was having a look at the Chrome developer tools when making a login. A successful login with 4.7.0 initiated about 577 KB worth of data transfer to load noVNC and friends. Javascript was the biggest part of that, consuming 411KB. With 4.7.0post_5377, the total request size has more than doubled to a whopping 1.3 MB. We now load almost 700KB of icons. 416K of those are a SINGLE icon! > $ du -h www/images/tlclient_512.png > 416K www/images/tlclient_512.png
Apparently loading all icons is a known issue with Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=324820 It apparently also was an issue with Firefox at one point: https://bugzilla.mozilla.org/show_bug.cgi?id=751712 I checked the logs though and Firefox is no longer suffering from this issue (although it still has the issue of not showing the requests in the debug tools :/). The bug reports also mention that none of the other major browsers suffer from this, so it seems to be only Chrome left[1]. On the positive side, it loads the icons after everything else. IOW it doesn't delay getting the session up and running. [1] Possibly also Opera, since they're also using Blink now.
More issues. The icons aren't loaded properly for the login page, and the 404 status code isn't sent properly to the browser.
512x512 icon removed, and the others severely reduced in size via bug 6175. Resolving again.
A successful login does now correspond to 816 KB. 420 KB javascript and 182 KB icons. Good enough.
The vendordrop in commit 32157 brought in improved handling of uncaught errors. This includes a traceback along with the error message. A side effect of this is that bug 5651 now prevents users from going back to the login page.
Created attachment 800 [details] Screenshot of the old error message (In reply to comment #22) This is how bug 5651 looked like before the changes brought in by this vendordrop.
Created attachment 801 [details] Screenshot of the new error message (In reply to comment #22) This is how bug 5651 looks like now.
(In reply to comment #22) > The vendordrop in commit 32157 brought in improved handling of uncaught errors. > This includes a traceback along with the error message. A side effect of this > is that bug 5651 now prevents users from going back to the login page. One possible workaround could be to add an exception for this specific error and ignore it.
favicons no longer work on Firefox on Android. Seen on the Pixel tablet. They work fine with 4.7.0.
(In reply to comment #26) > favicons no longer work on Firefox on Android. Seen on the Pixel tablet. They > work fine with 4.7.0. Scratch that. Not a regression. Apparently Firefox no longer shows favicons when you've added a security exception for a site. Not sure it's something we need to track, but I reported it upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1358101
The common NS_ERROR_NOT_CONNECTED error is hidden for now. Tester should verify that following the instructions on bug 5651 does not cause an error message to obscure the login-page-button. The error should still be printed to the browser console however.
(In reply to comment #29) > The common NS_ERROR_NOT_CONNECTED error is hidden for now. Tester should verify > that following the instructions on bug 5651 does not cause an error message to > obscure the login-page-button. The error should still be printed to the browser > console however. A bit difficult to provoke for some reason, but I managed to get one instance at least. And it did indeed only show up in the console, not on the screen.
