Etcher: App unresponsive

[jscheel]

• Etcher version: 1.4.9
• Operating system and architecture: MacOS 10.12.5
• Image flashed:
• Do you see any meaningful error information in the DevTools?
  When I profile the app, the raven-js npm package appears to be making the app almost completely unresponsive. I can click a button, and will have to wait 5+ seconds for it to respond.

[thundron]

Mmmh, @jscheel could you try running it without connectivity? Do you have some restrictions in the network that might affect the opt-out analytics? You can also try to deactivate them in the settings and see how it goes

[jscheel]

@thundron I was getting the same result not matter what. Interestingly, even with the analytics opt-out it was running poorly. Now, though, after restarting the app, it runs fine. Really odd.

[jscheel]

I wonder... is it possible that the analytics are synchronous, and something was timing out?

[thundron]

@jscheel Nope, we just send the request and that's it... So even if it was a slow network, it doesn't justify the app unresponsiveness

[lurch]

@jscheel Are you still able to reproduce the problem, or was it a one-off occurrence?

[jscheel]

@lurch nope, it's back. Here's a profile of me clicking "select image":

Profile-20190108T115601.json.zip

[marcelogaio]

Same here. Previous version worked fine.
Now, every action takes like 5 seconds to process...

[thundron]

We're looking into this issue, we weren't able to reproduce yet though so it'll take some more time

[working-name]

Same here on 1.5.51. I blocked outgoing connections with a firewall, no idea if that's a factor.

[hulleyrob]

Yeah this is almost unusable nowadays.

[hulleyrob]

Luckily I still have a copy of the 2017 Etcher app installed and that works fine without any problems.

[thundron]

@working-name Did it speed-up after blocking outgoing connections? Also, @hulleyrob we recently (as in the latest days/weeks) updated our external content (success-banner and featured-project webviews) so that they should be way lighter than before, in terms of connections made at least. It would be nice if you could take the time to look into it again, as so far none of us have been able to reproduce and we've been trying to understand what is going on for a long time :/ also, on OSX sometimes rebooting/updating the OS seems to help, although I would stay away from Catalina (next macOS version) until we're done with notarising Etcher dmg

[lurch]

we recently (as in the latest days/weeks) updated our external content (success-banner and featured-project webviews) so that they should be way lighter than before

@thundron FYI I see that https://github.com/balena-io/etcher/blob/master/lib/gui/app/components/featured-project/featured-project.jsx#L37 has:

const endpoint = settings.get('featuredProjectEndpoint') || 'https://assets.balena.io/etcher-featured/index.html'

And when I look at the source-code of https://assets.balena.io/etcher-featured/index.html I see that it still has GoogleAnalytics and MixPanel in there? :confused: Should they have been removed? @petrosagg
(P.S. deliberately keeping this comment away from "the other issue" where this was discussed :wink: :joy: )

[thundron]

@lurch Yes it still loads those libraries for now, we're still changing things but as of now with the optOutAnalytics=true URL param, no API calls are made to those services (and this won't change of course :P)

[hulleyrob]

The new version does seem much improved I was able to choose an image and drive straight away unlike the previous version and did not see some of the connections I had previously blocked in little snitch try to make an outbound connection.

[lurch]

@thundron I notice that the success-banner gets loaded from https://www.balena.io/etcher/success-banner/ whilst the featured-project gets loaded from https://assets.balena.io/etcher-featured/index.html.
_Perhaps_ it'd make sense to move them both to the same subdomain? :man_shrugging:

[thundron]

@lurch Yeah and it would probably solve some inconsistencies we noticed while removing all those side-connections, but we'll first have to refactor the success-banner and then move it, to avoid other inconsistencies