Determine the current block height directly from the lnd log output and
pass the data into the app as soon as we have it. Do not call out to
block explorers if we don't need to.
Fix a race condition that could cause the app to think that it is still
syncing even after it has completed and as a result being stuck
reporting 100% syncing during the onboarding process.
`startGrpc` can take some time to fully establish and verify that th
connection is set up as we wait for a successful result from a call to
`getInfo`.
Previously, we would send the `lndSyncing` message to the app only after
`startGrpc` was complete. However, if the syncing process had actually
completed before `startGrpc` then we would first notify that syncing had
completed, only to then notify that it had started after it had already
completed.
In this fix, we notify the app of `lndSyncing` immediately after the
wallet has been unlocked.
Fix#525
`main.dev.js` was hard to follow and understand the code flow. It housed
code to handle quite a few distinct things. This is a fairly substantial
refactor of the application startup code in which we:
A new `Neutrino` class has been created with 2 public methods. `start`
and `stop`. `start` will launch a new `lnd` process whilst `stop` will
stop it. This class extends the `EventEmitter` class and emits the
following events based on activity detected from the lnd log output.
- `grpc-proxy-started` - gRPC started
- `wallet-opened` Wallet opened
- `fully-synced` - lnd is all caught up to the blockchain
- `got-block-height` - got updated block height
A new `ZapController` class has been created which houses all of the
logic for intraprocess communication between the main and renderer
processes.
Previously we had several `setInterval` loops that were checking every
second to see if the application status has changed and trigging the
appropriate action if so. This was pretty hard to follow has been
replaced here with more extensive use of promises. This enables us to
act instantly to relevant changes rather than waiting up to 1 second
for the next interval to fire.
Now, the only stuff that lives in `main.dev.js` now is the top level
`app` listeners, which calls out the other parts mentioned above to
bootstrap the application.
Wait until the `dom-ready` event has fired before opening up the
devtools window. This prevents the following error message showing up
multiple times when the app starts in dev mode:
> Extension server error: Operation failed: : has no execution context
See https://github.com/electron/electron/issues/12438Fix#499
Previously, if the user pushed the back button after supplying a seed word,
then returned and entered the required three, the seed check would fail due to
there being more words supplied than required.
Use `CspHtmlWebpackPlugin` to generate our content security policy
using code rather than hard coding meta tags on our html index page.
This provides us a more flexible means to configure our CSP dynamically.
Use `HtmlWebpackPlugin` to generate our final html file so that we can
remove our inline scripts and insert them dynamically based on our
webpack config.
If we catch these errors and resolve to the error itself, then `await` for that
function resolves to the error value rather than throw. Because no api currently
handles the associated errors, it is better to be noisy about these errors, by
throwing rather than returning the error object.
Tom Kirkpatrick
odb366
Jack Mallers
Ben Woosley