Hi,
I’ll find a better way to handle that, maybe by showing “Not a valid alias !” into the “Alias of” input instead of alerts.
When you sign it does not remove the bottom bar and the red message ?
Will be in next update 
That’s right.
Since this phenomenon has experienced multiple times not only once, it has reproducibility.
When a sign request arrives, I guess that you are probably able to actually sign on the first sign.
However, on the screen, I will be able to sign again in order to become the same screen as before signature even after signing.
It is a multisig configuration of 6 of 12 in the production environment of main net.
Finally, although it is a little away from the subject, I will introduce an example where the signer can not easily sign the multi-sig’s signature request.
If a signature request occurs, there are times when it takes time or signature request does not arrive at all (even if the required number of signatures has not been reache), even if the signer invokes the signature to sign the NanoWallet.
I am thinking that the signature request is a push send.
And the signer who does not receive the signature request is a bit confused.
As a temporary countermeasure at present, signing request may be sent by NIS node change now, so we are dealing with that (even if it does not come yet).
I almost depend on automatic translation, so I think that it is hard to read, but thank you.
1.2.12 < 1.2.2
What browser are your using ? When the issue occurs can you open the browser console and see if any errors are shown ?
Yes sometimes cosignatories do not receive the transaction to sign and changing node can fix the problem. This issue is here since the first version of the app, not sure why. I suspected NIS but I don’t remember the reason, maybe it was also in lightwallet.
1 Like
No, it looks confusing but 1.2.2 < 1.2.12
2 is less than 12.
For the case where I can sign many times, try checking the console log next time. Currently I’m using the latest version of Google Chrome (MacOS).
And, as for the case where the signature request does not arrive, I understood it as a problem that existed before.
Problems occurred only when using Chrome V.56 (latest version) in NanoWallet β1.2.12 (Ver. 2016 Nov and Ver. 2017 Jan).
There is no problem with Chrome V.55.
When updating from V.55 to V.56, localStrage will be deleted once, regardless of whether it is checked or not.
From Chrome V 56, if the checkbox of “Block third-party cookies and site data” is checked, it seems that the localStrage has turned into a design that can not be seen.
So, when using Chrome V.56, we need to uncheck it.
By the way, in Chrome V.55 localStrage was visible even if checked.
I found a new bug that only happens when using the latest Google Chrome (V.56).
At the Apostille notarization creation menu, the fee will be remitted but the Zip file can not be downloaded.
Looking at the console log, it seems that I am trying to access the cettificate.png file and it is a CORS policy violation.
Here is the screen at that time.
Hi,
Indeed, this issue was also in Safari. It has been fixed a couple days ago by fetching the certificate from Github repository if using those browsers.
1 Like
Thanks for the report. As QM said, the next release will have this fixed.
1 Like
Hi,
I’m using the english language.
If I go from
Services
Delegated Harvesting
clic on "Manage delegated account"
In the harvesting panel on the bottom,
there is a combo box,
"Select a node to harvest on"
on the right of this combobox, there are three buttons from left to right:
1 - "use custom node"
2 - "use node from list"
3 - “start delegated harvesting”
well, the description of 1 should go to button 2
and the description of button 2 should go to button 1
I have logged two issues on GitHub:
#13 - In Microsoft Edge after upgrade of NCC wallet you are not prompted to download the upgraded wallet and manually trying to download the wallet from Account does work either.
#15 - Microsoft IE 11 rendering on pages is broken. Probably down to IE 11 but might want to include supported / recommended browsers on the initial splash screen
KC
@quasarblue, Will be fixed in upcoming 1.3.0
@KingCole, I’ll probably lock the app and show a splash screen with recommended browsers if an unsupported one is used.
Version 1.3.0
- New design
- Address book
- Fix Apostille on Chrome and Safari
- No need to provide an account address to create a private key wallet, address will be shown automatically
- Same as above point but for creating multisig accounts
- Importance transaction module show the corresponding remote account address when a custom public key is provided
- Fix handling of decimal amount in normal transfer transaction, comma and dot decimal mark can be used
- Fix message fee
- Fix ‘unknown mosaic divisibility’ error when receiving a new mosaic
- Limit individual apostille file to 100MB
- Fix display of importance score
- Fix “FAILURE_TIMESTAMP_TOO_FAR_IN_FUTURE” using NIS time-sync API
- Lock app and show message if browser not supported
- New market data provider
- Minor fixes & improvements
2 Likes
Since the start and stop marks of the harvest are the same color, it may be a bit confusing.
When I am not harvesting and not connected, I think that the red mark is better like before.
should be in a different color and different shape. hopefully we will have messages that come up when you hover your mouse over it too.
I confirmed that the ALT message appears on mouse over.
I just tested it. Encrypted messaging works fine. The problem is you can’t send an encrypted message to an account that has no outgoing transaction.
For encryption to work there needs to be a private/public key pairing and accounts that have not ever made a transaction out don’t have a published public key.
We really need a better error message to help people with that.
1 Like
As a result of various tests, I found an event that Encrypt can not be checked if the destination address is incorrect.
Would you please check the destination address once?