UX : avoid freezing on decompressing files

[vhemery]

During the "Decompressing files" stage or scanning, the UI can easily freeze. (enhancement)

Steps to reproduce with SCANOSS Audit Workbench Setup 1.4.0 (no particular version of NPM installed) :

1. Work on an already built workspace, which has lot of jar/zip files loaded.
2. Check "Decompress archives and scan inner files".
3. Launch the audit.
4. The "Decompressing files" stage can take quite some time, and when we try and click anywhere the UI freezes.

There are two complementary ways to improve the situation.

• On one hand, it would be nice not to freeze on the "Decompressing files" stage. (probably decompression is currently not using async methods and Promises)
• On the other hand, the workbench is probably not intended to be launched on an already built workspace, but rather on the source code only (correct me if I'm wrong). So if the"Decompress archives and scan inner files" option is checked and we detect too much archives volume, it would be nice to display a warning to the user before proceeding to the actual scan and decompressing. Something like "It looks like this project contains a big volume of achive files. SCANOSS is intended to be launched on the source code only, and not on the built project. Please, check your project has not been already built. Are you sure you want to actually proceed?".

[francostramana]

Hi @vhemery

Thank you for your contribution. We have analyzed this issue and have come to several conclusions. Indeed, the UI freezes when the workload in the decompression process is high. Unfortunately this is not a javascript promises issue. In a Electron App, the UI (renderer) runs in separate process from the Main Thread, where the pipeline of the new project is executed. However, to our surprise, it seems that these processes are not as independent as they claim to be. If the main thread gets blocked, it can freeze all the rendering threads initiated by it. This post discussing the issue is very interesting: https://medium.com/actualbudget/the-horror-of-blocking-electrons-main-process-351bf11a763c.

So what we have decided is to start migrating some computationally expensive processes that were running directly on the main process to secondary threads in order to avoid blocking the main process, regardless of whether we needed concurrency or not. The decompression stage is the first one we have moved, and it is already integrated. The official release with this improvement will be available in a few days.

Nevertheless, we have plans in our backlog to improve the progress reporting and provide users with estimated times for each stage.

Once again, we appreciate your contribution as it has helped us better understand the architecture of Electron in these cases