Huge thanks to the Firefox team, for their help on the issue of our long-standing inpage script race condition.
http://stackoverflow.com/questions/38577656/how-can-i-make-a-firefox-add-on-contentscript-inject-and-run-a-script-before-oth
The problem is that we were injecting a `script` tag and assigning its `src` attribute, which triggers an asynchronous fetch request, and does not guarantee execution order! (That was news to me!)
Instead, I'm now assigning the `script` tag a `textContent` value of the script to inject, and it seems to fix the problem!
There is also a Firefox-only API that could solve this whole problem in an even more elegant way, so we might want to expose a code path for that solution later on:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Language_Bindings/Components.utils.exportFunction
Allows you to expose an object from one scope to another. There was even talk of creating a polyfill for it that does virtually what we do, message passing between contexts.
* WIP: Buy button link
* Add buy eth and the buy eth warning message
* Add css
* Move the opening of coinbase page to background
and send to faucet if on test net
* Create a Warning about storeing eth
* Finish Buy button and Eth store warning screen
* Add to CHANGELOG
* fix frankies deletion and change chrome to extension
* Add mozilla plugin key to manifest
* Move all chrome references into platform-checking module
Addresses #453
* Add chrome global back to linter blacklist
* Add tests
Replace config-manager-singleton with one that is instantiated within the `background-controller`, and takes its persistence callbacks from its instantiated options.
Replaced class getters with more familiar get___() functions.
Signing now always takes a 64 digit hex string, and returns a message signature which appropriately pads r, s, and v with zeroes.
Need to verify with Denis that this is the behavior he requires.
Scrolling to the bottom of the accounts page now reveals a downward-facing chevron button.
Pressing this button shows loading indication, adds a new account to the identity vault, displays it in the list, and scrolls the list to the bottom of the page.
Any number of accounts can be generated in this way, and the UX feels intuitive without having to overly explain how HD paths work.
Fixes#122
Had used multiple actions for some transitions, which would lead to brief intermediary states.
Now making a few actions much more explicit about what they route to, so there is less intermediary logic, and we can transition confidently to the correct view.
No longer do our `mainnet` and `testnet` buttons set specific RPC urls. Now they set `provider.type`, which gets interpreted with code.
Currently the provider types of `mainnet` and `testnet` point to our new scalable backends, but these could be re-interpreted to use any other provider, be it etherscan, peer to peer, or otherwise.
Makes it easier for us to upgrade our infrastructure without incorporating migration logic into the program.
Calls to `eth.sign` are now transiently persisted in memory, and displayed in a chronological stack with pending transactions (which are still persisted to disk).
This allows the user a method to sign/cancel transactions even if they miss the Chrome notification.
Improved a lot of the view routing, to avoid cases where routes would show an empty account view, or transition to the accounts list when it shouldn't.
Broke the transaction approval view into a couple components so messages and transactions could have their own templates.
When starting up, we now create a `web3` inside the `background.js` process, which we pass to the `idStore` and ask for the current `network`.
We include the `network` on `app.metamask.network` in the state object.
We re-request the network when changing provider.
We filter the transaction list for transactions that match the current network.
When selecting an account, we now persist the selection to the `configManager`, so the selection can be restored when re-unlocking Metamask.
Also found the bug where `rawtestrpc` was still being used as a default, and fixed it!
- When unlocking, the first account is now selected by default and displayed as the main view.
- There is now a "CHANGE ACCT" button on the detail view to show the accounts list.
- Clicking an account from the accounts list now navigates to the detail view and selects that account.
- Config/Info screen "back" buttons now fire a new action, `GO_HOME`, which is configured to navigate to the accountDetail view, putting that logic in one place.
- When locking and unlocking again, the first account is always displayed, eventually we should persist the selection.
This migration will move users who have their clients configured to point at `rawtestrpc.metamask.io` to point at our new test-net RPC, `testrpc.metamask.io`.
Transactions are now stored, and are never deleted, they only have their status updated.
We can add deleting later if we'd like.
I've hacked on emitting the new unconfirmedTx key to the UI in the format it received before, I want Aaron's opinion on where I should actually do that.
This boolean is computed from these requirements:
- The user is on the testnet rpc
- The account is index 0
The UI is responsible for checking the account balancing and indicating if fauceting is indeed pending or not.
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
Also added the hdPath that Christian had told me to our calls to the LightWallet, but this does not seem to have made us generate the same accounts as `testrpc` yet.
Added initial test just to verify we can recover the accounts we generate in this way.
Still need to add compliance test to make sure this interoperates with testrpc's new mnemonic flag.
In order to persist the seed word page until the user clicks the confirmation button, we need to store the seed words in localStorage.
To simplify this process I've also reorganized some of the account manager code, broken up one large function into many smaller functions, and created a new class for the IdMgmt object.
Again, sorry such a big refactor in one commit, but I really had to break it down to work through it.
