search

hivewallet / hive-js

Hive digital currency wallet
http://www.hivewallet.com
GNU General Public License v2.0
81 stars 57 forks source link

Internal XMLHttpRequest Error #233

Closed KBenavidez closed 9 years ago

KBenavidez commented 9 years ago

Issues from : https://hivewallet.zendesk.com/agent/tickets/784, https://hivewallet.zendesk.com/agent/tickets/783 and Paul via Skype

Wallets cannot be opened in any app/device - iOS, Android or Web.

From Paul's log:

Velocity is already loaded or its namespace is occupied. blob:https%3A//web.hivewallet.com/a50f8864-958d-4269-8706-153d114a2e20 Failed to load resource: the server responded with a status of 404 (Not Found) /assets/js/application-en.js:3675 The above 404 is totally normal. PouchDB is just detecting blob URL support. /assets/js/application-en.js:3197 Discovered 4 addresses /assets/js/application-en.js:3197 Discovered 5 addresses https://hivewallet.cloudant.com/?_nonce=5LvgS3fy2bht2uoT Failed to load resource: the server responded with a status of 403 (Forbidden) https://hivewallet.cloudant.com/?_nonce=WRHlj59mXs5bOs72 Failed to load resource: the server responded with a status of 403 (Forbidden) https://hivewallet.cloudant.com/?_nonce=IzE35pk4jC6Z7X2o Failed to load resource: the server responded with a status of 403 (Forbidden) /assets/js/application-en.js:3342 Error: Internal XMLHttpRequest Error

surajchavda commented 9 years ago

I am facing the exact same issue. Not able to log in from browser or app.

ajayspi commented 9 years ago

I'm facing the same issue please resolve it fast

weilu commented 9 years ago

Our staging site has a newer version of the wallet. Try https://hive-js.herokuapp.com/

dabura667 commented 9 years ago

still having this issue.

ghost commented 9 years ago

Do any of you who have this issue have low-balance wallets that you wouldn't mind sharing the passphrase and PIN of? We have no wallets with this issue, making debugging difficult... If you don't mind sharing, please send PIN and passphrase to w@hivewallet.com - thanks!

PS- please include the balance if you know it, just so we have on record how much SHOULD be in there. :)

ghost commented 9 years ago

@weilu says:

The [issue is the] browser and/or API resets the connection after some timeout. You can only get into your wallet if all your requests manage to finish before the timeout.

Caching API responses in the browser partially solves the problem for frequent users -- it works until user clears the browser cache, or logs in the first time (or after a long time) using another browser. Not to mention that caching isn't trivial to implement correctly. This is among those any solutions but not a good one.

There are smart ways to defer making requests to the blockchain API:

  1. Open the wallet as soon as all the used addresses are discovered. At this point we have the balance. User can see the balance, but not the transaction history, and they will not be able to spend any money.
  2. Fetch all the unspents for the discovered addresses. After this is done, user will be able to send money.
  3. Load transactions. Given the limitation of blockr, we cannot query transactions by block height for a given set of addresses, so there's no sure way to load the latest transactions first. Our best bet is to load the transactions in order of the newest discovered to the first discovered addresses. In UX words, 1) it's not possible to load the latest n transactions first, then wait for user to scroll to load more, while guarantee correctness. 2) if we decide to show transactions as they come in, transactions will come in no particular order -- you will see transactions inserted in between already loaded transactions, if we want to preserve the current reverse chronological order in the history tab. Whether we want to show transactions as they come in or show nothing until all transactions are loaded, that's a UX decision I'll leave to Matt.
  4. Once all above is done, we can consider caching transactions to speed up step 3. The number of confirmations can be updated by caching each transaction's block height, and then finding out the current block height. We need to be careful about unconfirmed transactions -- I'd advice to not cache any transactions with less than 6 confirmations, but as we all know, 6 isn't a magic number when the amount involved is big, but it's probably a good enough start.

All of above still doesn't guarantee reliable use of the wallet though, if say, the blockchain API has an IP based throttle for requests. We still need to exhaustively fetch all unspents for all discovered addresses. So depending on the throttle limit, a heavily used wallet could very well stop loading during step 2 -- meaning that the user still cannot spend.

ghost commented 9 years ago

We'll be back to working on Hive full-time in 1 month, at which point this and other issues can hopefully be knocked out. In the meantime, open to pull requests if anyone wants to take a shot at it.

Oaklandish commented 9 years ago

@w-hive

  1. my wallet is not "heavily" used, as you (probably) assumed. it's been in use for a few days and had only 7 transactions totally.
  2. as far as I read the comments of people having this problem, it seems it's related to extension/plugin changes in user browser, after the last login. (what I know that I have done)
  3. in response to your quotation, "very difficult to diagnose when we have zero access to peoples' wallets" , I can give you my passphrase, PIN, and the info about all transactions, and the last amount of BTC in my wallet, if it helps. ( and my hard-earned wealth doesn't get disappeared :] around 2 mBTC )
  4. my (rookie, wild, probably wrong) guess is this : your server saves something about the Java-RE version installed and used the last time by wallet, or sets something based on that version. then the user logs out, (or in my case, just closes the hive wallet tab in browser). then he updates/changes the JRE plugin used by his browser. then he tries to login, and your server does not take something about this change into account. and leads to an error.

I guess it's not about how heavily-used a wallet is, as my wallet was really brand-new and infant :) I updated my JRE plugin from version 8.0-build:25 (or maybe 26) to 8.0-build:45 and started to see the error.

ghost commented 9 years ago

Well, that that your wallet hasn't been used much is a bit troubling, since that is what we had assumed it was connected to. @weilu any thoughts? I'm doubtful about the Java-RE being a cause.

If you don't mind emailing me the passphrase -- w@hivewallet.com -- it would help.

Oaklandish commented 9 years ago

by the way, I forgot to mention, It's not this version of JRE causing the error. because right now I can open any new, already-un-opened wallets just using this (updated) version of Jre, and this same browser that experienced the error. and I can't open my wallet even in other browsers (my friend's pc), that have other versions of JRE. and his PC can open other wallets too, just like my Laptop.

so the only reason for error is the CHANGING/UPDATING of JRE, rather than a specific version of JRE itself. send you the mail right away.

ghost commented 9 years ago

Can everyone here try http://hive-js.herokuapp.com with your passphrases? With the few that you've sent us, they are mostly now working.

ghost commented 9 years ago

Closing this and other redundant issues now; #237 and #239 should suffice.