Allow signing via Qr

[jacogr]

Required Native Signer app (recent commit >= 28 Mar)

External account creation -

• Allow the creation of external accounts (via normal create account)
• Scan account QR via camera, create entry, mark as external
• Display account in accounts list
• Allow editing inside account view (meta + forget)

Transaction sending -

• Allow account to be utilised as normal account, available when sending
• Detect external account in signer, allow
  • Display of unsigned transaction to external app (display QR)
  • Scan of signer r, s, v values from external app (read QR)
  • Construction & submission of signed transaction

Todo (follow-up PRs) -

• Seeing this a functionality-complete MVP (round 1) so can can continue playing/tweaking on both sides and it doesn't get out of hand
• UI is not 100% optimal with the display of the QR codes (sizing) and the display of the camera/reading viewer. (As MVP ok, but needs to be moved, not convinced about yet another modal though, so layout?)
• Signer displays - columns adjust based on camera/QR (related to above)
• CreateAccount modal needs rework, especially on the final details screens across account types (already had "unrelated" store naming changes in here)

[jacogr]

Updated to solve the QR sizing issue, including the new full transaction or hash-only signing (this is not activated atm, hence the in-progress, will flip the switch when the mobile client is ready)

EDIT: Until the app is updated with allowing for hashes and the feature enabled here, things like contract deployments still won't show up (any unsigned rlp over around 2.7k will not show the QR), however the confirmation case now will show the QR.

[gavofyork]

any reason we force the user to click a button in order to input the signed transaction?

[jacogr]

Seriously running out of space of the pop-up screen, with both the large QR codes & camera visible at the same time, it is not really optimal or quite usable (scrolling in some cases). Click is basically the state change from "show unsigned" to "read signed".

Having said all that, I have been "playing" with some ideas here to try and get both on the same view, nothing that sticks yet without some other drawbacks.

[tomusdrw]

I think you can request permissions to access the camera only as a response to user interaction (so clicking something). Although if the permissions are already granted it should work fine.

[gavofyork]

ok so maybe fire up the camera in the background if the permissions are there. if no permissions or the user wants an image if what the camera is seeing, then they click the button like now.

[gavofyork]

also, this no longer builds properly when using npm start:

Unhandled rejection Error: Duplicate message id: status.debug.title
    at /Users/gav/Core/parity/js/node_modules/react-intl-aggregate-webpack-plugin/index.js:44:17
    at Array.forEach (native)
    at /Users/gav/Core/parity/js/node_modules/react-intl-aggregate-webpack-plugin/index.js:38:19
    at Array.reduce (native)
    at Compiler.<anonymous> (/Users/gav/Core/parity/js/node_modules/react-intl-aggregate-webpack-plugin/index.js:37:8)
    at next (/Users/gav/Core/parity/js/node_modules/webpack/node_modules/tapable/lib/Tapable.js:140:14)
    at callback (/Users/gav/Core/parity/js/node_modules/copy-webpack-plugin/dist/index.js:71:17)
    at Object.finallyHandler (/Users/gav/Core/parity/js/node_modules/bluebird/js/main/finally.js:39:23)
    at Object.tryCatcher (/Users/gav/Core/parity/js/node_modules/bluebird/js/main/util.js:26:23)
    at Promise._settlePromiseFromHandler (/Users/gav/Core/parity/js/node_modules/bluebird/js/main/promise.js:510:31)
    at Promise._settlePromiseAt (/Users/gav/Core/parity/js/node_modules/bluebird/js/main/promise.js:584:18)
    at Promise._settlePromises (/Users/gav/Core/parity/js/node_modules/bluebird/js/main/promise.js:700:14)
    at Async._drainQueue (/Users/gav/Core/parity/js/node_modules/bluebird/js/main/async.js:123:16)
    at Async._drainQueues (/Users/gav/Core/parity/js/node_modules/bluebird/js/main/async.js:133:10)
    at Immediate.Async.drainQueues (/Users/gav/Core/parity/js/node_modules/bluebird/js/main/async.js:15:14)
    at runCallback (timers.js:637:20)
    at tryOnImmediate (timers.js:610:5)
    at processImmediate [as _immediateCallback] (timers.js:582:5)

[jacogr]

Just merged in the latest master into this branch. Just run npm clean before npm start - those errors are due to i18n id moves as part of the status page cleanup PR.

[jacogr]

As for the camera + QR display at once - apart from the sizing issues, it opens the following rabbit hole:

Each external signed tx will have the camera view (one for each external tx), each will see the same and scan at the same time. With the current nested layouts, there is no way to elegantly solve this since each tx is not aware of anything outside its sandbox and info,
i.e. showing them one at a time is not quite feasible

The same issue is to be solved in #5322 - which is effectively a complete rework of how the view fits together, managing account/recipient/origin state at a higher level. My suggestion would be to tackle that annoyance in there.

[gavofyork]

ok - so is this good to go otherwise?

[jacogr]

No show-stoppers I'm aware of.