Bug 7368 - noVNC takes a long time to load on Internet Explorer
Summary: noVNC takes a long time to load on Internet Explorer
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Web Access (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.11.0
Assignee: Pierre Ossman
Keywords: ossman_tester, prosaic
Depends on: 7365 7366
  Show dependency treegraph
Reported: 2019-08-15 11:05 CEST by Pierre Ossman
Modified: 2019-11-14 15:02 CET (History)
1 user (show)

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2019-08-15 11:05:44 CEST
noVNC now uses JavaScript's standardised modules. Unfortunately Internet Explorer doesn't support these and instead we have to convert them in runtime there. But this takes a long time, and means we have to ship a bunch of conversion code.

We should try to pre-convert things for these legacy browsers and ship that instead. It will load faster and will give us a more sane structure when debugging is needed as it will map better to the normal code.
Comment 1 Pierre Ossman cendio 2019-11-08 12:16:50 CET
We did a quick test to get a better idea of what the issue is. These are the load times we could see after pressing login:

          Empty cache       Filled Cache
IE         18 seconds         3 seconds
Edge        2 seconds         1 second
Firefox     2 seconds         1 second

So having something pre converted seems worthwhile.

We did a quick test with noVNC and a CommonJS pre-conversion. That got the load time down to around 1 second for IE.

Note that there are some upstream bugs we need to fix first:

 * There is a type in the HTML generation which messes up the include of app.js
 * We now use promises in the main code and not just the conversion, so the promise polyfill needs to be loaded even when doing pre-conversion

We tried to get babel to sort out the polyfill, but we couldn't really make sense out of how it was supposed to work.
Comment 4 Pierre Ossman cendio 2019-11-12 15:48:38 CET
Apparently the latest version of browserify isn't compatible with the latest versions of its dependencies (specifically readable-stream). So it looks like we'll have to use the AMD format instead of CommonJS when converting.

We also discovered that when babel looks up plugins it doesn't use nodejs' normal search algorithm. It forgets to check the global directories. Fortunately we can work around it by doing symlinking a local "node_modules" to the global "/usr/lib/node".
Comment 10 Samuel Mannehed cendio 2019-11-13 16:34:55 CET
The conversion is now done in the Makefile for Web Access. Seems to work great, tested in IE 11 on Windows 10 and in Firefox and Chrome on Fedora 31.

Loading is just as fast on IE now compared to the other browsers.
Comment 14 Samuel Mannehed cendio 2019-11-13 17:10:20 CET
The new require.js file has to be added to the Open Source bundle and be listed in the open source licenses.
Comment 18 Samuel Mannehed cendio 2019-11-14 10:39:19 CET
Should all be fixed now.
Comment 19 Pierre Ossman cendio 2019-11-14 13:01:19 CET
Seems to work well. Tested with Firefox and Chrome on Linux, and IE and Edge on Windows.

Load time is now down to under 2 seconds in IE, which is very nice. All functionality also seem to work without any noise in the browser console.

(Side note, IE loads the normal "ui.js" but doesn't execute it, and Edge loads the legacy "promise.js", "require.js" and "app.js" but doesn't execute them)

I checked the open source documentation and packaging and it looked complete.

One packaging glitch though, in that require.js is packaged twice:

Comment 22 Samuel Mannehed cendio 2019-11-14 13:15:59 CET
(In reply to comment #19)
> One packaging glitch though, in that require.js is packaged twice:
> /opt/thinlinc/share/tlwebaccess/www/js/require.js
> /opt/thinlinc/share/tlwebaccess/www/legacy/require.js

Fixed now.
Comment 23 Pierre Ossman cendio 2019-11-14 15:02:38 CET
Looks good, and still works in Firefox and IE.

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