Attempts to lookup `.eth` addresses on ENS.
Is currently failing.
I've written an isolation example of the problem here:
https://github.com/flyswatter/ens-test
These external modules now have their own test coverage and build enforcement. This allowed me to somewhat more easily add good tests around our personalSign strategy (held now in [eth-sig-util](https://github.com/flyswatter/eth-sig-util), and allow each of the keyrings to import that, etc.
Provider egine bump
Remove presence of message manger in keyring controller
Change the status wording fom conf to approved
make Message manager a class
fix messages not being apart of the badge
re write message manger to better reflect controller pattern
Doesn't work on any JSON file I have, it's a very naieve strategy provided by ethereumjs-wallet. Will need to raise its sophistication before deploying to production.
Implement generation of markdown for notice files.
Create npm command. Enhance notice generation.
Add test files to test multiple notices.
Add basic markdown support to notices.
Interval checks for updates.
Add extensionizer and linker
Add terms and conditions state file
Add link support to disclaimer.
Changelog addition.
Mostly Fixes#893
A couple methods cache callbacks, and will require a larger refactor to fully denodeify.
Specifically, our methods involving web3 requests to sign a tx, sign a message, and approve or cancel either of those.
I think we should postpone those until the TxManager refactor, since it will likely handle this response caching itself.
Added new Qunit build process that will browserify the contents of `test/integration/lib` into the QUnit browser, allowing much more modular testing, including unit testing of our modules in our target browsers.
Made a basic unit test file of this form for the new encryptor module, which fails miserably because I've only just begun to work with it.
I've started with this blog post as a starting point, and will be adjusting it to our needs from there:
http://qnimate.com/passphrase-based-encryption-using-web-cryptography-api/
I always keep writing up this same announcement message whenever I publish a new version.
I've now written a script to automate my announcement formatting, it looks like this:
```
**MetaMask 2.13.2** now published to the Chrome Store! It should be available over the next hour!
2016-10-4
- Fix bug where chosen FIAT exchange rate does no persist when switching networks
- Fix additional parameters that made MetaMask sometimes receive errors from Parity.
- Fix bug where invalid transactions would still open the MetaMask popup.
```
The new lightweight svg logo was not following text quite right.
The new `lookAt` method was not using the same logic the module was using internally on mouse movement.
I simply used that logic and exposed it via the old (expected) API, and got it behaving the way I like.
Fixed logo deallocation related bugs, had to patch the logo repo itself to add a stopAnimating method.
Also tuned up the logo to more closely resemble the old behavior.
- Overlaps the title text
- Points nose at cursor, not just front of eyes
- Cursor is more "distant" from fox, to avoid extreme angles on edges.
- No longer need to check for webGL compliance (svg rendered!)
- logo.canvas has been replaced with logo.container, since svg doesn't render to canvas but to an element.
Otherwise, worked with very little effort!!
Fixes#624
* Add platform specific folders to dist folder
* Remove gulp hacks
* Add platform specific bundling
dev and dist tasks now build into platform-specific folders within the `dist` folder.
Added tasks `gulp zip` and `gulp dist`.
`zip` builds the platform-specific folders into platform-specific bundles within the `dist` folder.
`dist` builds and then zips all at once.
* Fix chrome bundle zipping
* Fix broken reference in eth warning
* Fix but where web3.eth.accounts are not available in firefox.
* Bump changelog
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.
Dev mode now reloads on file changes (although it seems to sometimes reload too soon, not getting the update... we can tune the timeout interval in development/index.html)
Dev mode now reloads on all non-`node_modules` file changes, so the `ui` and `app` folders are both being watched for live reloading.
Currently experiencing a few problems:
1. Tons of errors on app start. It's as if Jazzicon is getting called many times at start with some object as its diameter.
2. Weird visual glitches. When leaving a view with a jazzicon, it flashes off its border radius.
3. Messy transitions. Might want to just re-do the transitions. They just look awful, it's barely worthwhile.
New version of provider-engine includes etherscan-subprovider features required to let Metamask use it.
Hard coded the new version of `web3-provider-engine` even though it is not live on `npm` yet, because it is a dependency of this branch.
I'll deploy to the Chrome store but not merge on Github until that provider-engine is published, because it could break others' dev environments.
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.
