Bug 6132 - Web Access is out of sync with noVNC
Summary: Web Access is out of sync with noVNC
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Web Access (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.8.0
Assignee: Samuel Mannehed
URL:
Keywords: derfian_tester, prosaic, samuel_tester, upstream
Depends on: 6129 5480 5605 5610 5611 5983 6007 6126 6135 6138 6175
Blocks: 5652 5882 6163
  Show dependency treegraph
 
Reported: 2017-01-10 16:59 CET by Samuel Mannehed
Modified: 2019-10-09 16:19 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments
Screenshot of the old error message (54.13 KB, image/png)
2017-04-20 11:15 CEST, Samuel Mannehed
Details
Screenshot of the new error message (68.18 KB, image/png)
2017-04-20 11:16 CEST, Samuel Mannehed
Details

Description Samuel Mannehed cendio 2017-01-10 16:59:57 CET
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)
Comment 2 Samuel Mannehed cendio 2017-01-16 16:50:08 CET
Doing a vendordrop would also fix tearing issues: bug 6138
Comment 3 Samuel Mannehed cendio 2017-01-23 09:57:50 CET
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
Comment 9 Samuel Mannehed cendio 2017-02-02 15:53:00 CET
(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
Comment 11 Karl Mikaelsson cendio 2017-02-06 11:15:47 CET
The "The HTML5 client is loading" message does not go away even after the session started.
Comment 13 Pierre Ossman cendio 2017-02-06 14:06:38 CET
Hopefully all regressions are now ironed out. Resolving.
Comment 14 Samuel Mannehed cendio 2017-02-10 15:07:40 CET
All done, closing this. The remaining testing is done on other bugs.
Comment 15 Karl Mikaelsson cendio 2017-02-20 16:13:01 CET
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
Comment 16 Pierre Ossman cendio 2017-02-21 11:11:11 CET
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.
Comment 17 Pierre Ossman cendio 2017-02-21 12:25:23 CET
More issues. The icons aren't loaded properly for the login page, and the 404 status code isn't sent properly to the browser.
Comment 20 Pierre Ossman cendio 2017-02-23 17:30:34 CET
512x512 icon removed, and the others severely reduced in size via bug 6175. Resolving again.
Comment 21 Samuel Mannehed cendio 2017-02-28 08:43:10 CET
A successful login does now correspond to 816 KB. 420 KB javascript and 182 KB icons. Good enough.
Comment 22 Samuel Mannehed cendio 2017-04-20 11:13:18 CEST
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.
Comment 23 Samuel Mannehed cendio 2017-04-20 11:15:24 CEST
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.
Comment 24 Samuel Mannehed cendio 2017-04-20 11:16:12 CEST
Created attachment 801 [details]
Screenshot of the new error message

(In reply to comment #22)

This is how bug 5651 looks like now.
Comment 25 Samuel Mannehed cendio 2017-04-20 11:22:32 CEST
(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.
Comment 26 Pierre Ossman cendio 2017-04-20 13:33:02 CEST
favicons no longer work on Firefox on Android. Seen on the Pixel tablet. They work fine with 4.7.0.
Comment 27 Pierre Ossman cendio 2017-04-20 14:14:47 CEST
(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
Comment 29 Samuel Mannehed cendio 2017-04-21 16:02:31 CEST
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.
Comment 30 Pierre Ossman cendio 2017-04-24 14:47:46 CEST
(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.

Note You need to log in before you can comment on or make changes to this bug.