View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004047 | Taler | wallet (WebExtension) | public | 2015-11-09 21:11 | 2019-12-26 21:37 |
| Reporter | Christian Grothoff | Assigned To | Marcello Stanisci | ||
| Priority | high | Severity | tweak | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | 0.0 | ||||
| Target Version | 0.0 | Fixed in Version | 0.0 | ||
| Summary | 0004047: "wire funds" button dialog is ugly and could be improved | ||||
| Description | 1) We probably don't want to even show the reserve key. Good security software hides this stuff, and I think here we can! (See 7.). For now, I'd just remove the "Reserve keys successfully created" text. 2) The dialog subject should not be "Keys Checksum", but maybe "Create reserve..." or "Specify amount to withdraw". 3) Plese => Please 4) value | fraction | currency is very ugly and low-level. We should use ONE input field that expects an input of the form "1.25" or "1,52" (tolerate use of comma or point), and maybe for now limit fraction to two digits (but do not require use of comma/dot). Naturally, the dialog should prevent users from entering anything but numbers. Actually, (8) would be an even better solution here, as that way we only enter the amount once. 5) Currently, currency selection allows KUDOS OR EUR. But the mint only supports KUDOS. Here, the event triggered by the website should communicate the set of supported currencies to the wallet (either directly as part of the event or by having the wallet fetch /keys) and only the currencies supported by the mint should be shown. 6) Instead of "copy to clipboard" and "close", we need a button "OK" and another "cancel". Cancel should abort the operation, and "OK" should take the reserve key and paste it directly into the DOM's input element. Like the set of supported currencies (or alternatively the Mint base URL), the (name of the) DOM input element to update should be communicated from the button's event handler to the wallet. In practice, applications can then even choose to hide that input element, so users might never really see the reserve key ascii art. Even if they do, we can avoid the ugly manual 'copy & paste'. 7) The wallet API should document the event (and the arguments like mint URL or currency list and DOM element to update) that is used to trigger this dialog. I guess that falls under wallet-mint API, so we may need another section in the API spec for that. 8) Like (6), the wallet could also update the amount input widget in the same way. Or maybe better: have the user enter the amount in the normal DOM and *fetch* the amount from the Website DOM's input field. At that point, the wallet dialog becomes (for the user) a simple "confirm: OK/cancel", but behind the scenes it updates the reserve public key in the DOM (and the wallet database). | ||||
| Tags | No tags attached. | ||||
|
|
fixing 1), 2), 3), 4). As of 6), up to the point (see mint codebase) of specifying mint's base URL and input DOM 'id' attribute (NOT tested). |
|
|
(NOTE: some changes in INRIA's machine not pushed!) |
|
|
As for 8), the amount (DOM) 'input' widget belongs to a *bank*'s SEPA web form, so the proposed solution will work just for the fake wire transfer. Actually, the same holds for the 'input' widget which gets the reserve's key pasted. EDIT: because of the planned integration with the bank system, the fake transfer should already look like the expected way of doing that |
|
|
8) wallet has a problem in getting the currency from the DOM (FIXED) |
|
|
fixed in d4414f0..3e95d7a (wallet) a0a82c2..1a29502 (api) As for the API, there is a new section for wallets-banks interactions, since the interaction with the mint is test-ish |
|
|
I don't understand the 'reserve-submitted' event in the 'banks.html' specification. Also, the HTML (!) of the demo/transfer/ page is awkward, as the 'wire funds' button will read the 'Amount to credt to your reserve', but that field is below 'wire funds'. Finally, the submit button is sensitive even if the reserve public key is not present (and that element should probably be hidden). Finally, we ought to rename 'wire funds' to "select mint", and the HTML page should be "Welcome to the KUDOS Bank!". And then the wallet should allow the user to pick the mint... |
|
|
problems in getMintCurrency() from DB: values are fine, but kind-of can't return the string (fixed: just a typo) |
|
|
'input' element not happy to be programmatically filled (resulting in server side script unable to POST /admin/add/incoming) FIXED, align the API before closing the issue |
|
|
http://stackoverflow.com/questions/4683331/how-to-fill-in-form-field-and-submit-using-javascript suggests that something like: document.getElementById('username').value="moo" document.forms[0].submit() should work. Did you try this? Does it work if you do it in the JavaScript from the page and not the extension? |
|
|
Yes, it works. I'm just not using this array notation to get the form's DOM; just pick it based on the 'id' (see the API). 'from the page' you mean that once the extension has prepared any needed data, it signals something to the page and the page does the submit? |
|
|
any point has been addressed. Note: the accounting of any chosen mint (to show them in the dropdown menu) is already reported in 0004051 |
|
|
The bank-site still suggests/allows/displays text relating to installation of Taler wallet, even if the wallet is already installed. Maybe make it like the shop site instead? (FIXED) Also, I clicked twice on "select mint" (not seeing the pop up on the 2nd screen). Would be 1) good to make the pop up appear on the same screen (for multi-screen setups) 2) ignore the 2nd click to the select mint button IF the dialog is already open (and instead re-focus on the existing dialog) (FIXED) When 'withdrawing' in the background, my CPU goes rather crazy for a bit and the browser seems to 'hang'. Likely we need to 'stage' the computations a bit more carefully, either by having a 2nd thread for computational tasks or by spreading it out a bit more or by showing a 'progress' window with a progress bar to pacify the user and indicate that the browser didn't just go into an infinite loop but is doing "regular" work. Or maybe the problem was excessive computation for withdrawing 1000 coins (could I have gotten like 10 kudos in 0.01 ct coins!?) The contract shown after the payment method is selected is still very ugly, especially the way the amount is displayed must be fixed. In the wallet-generated pop up to select the mint, the value is not properly filled in as the default. The default mint is in the drop-down list, but not in the text entry field. Likely trivial to fix. (FIXED) Fullfilment page after "buy" concludes does not work. (Shown, but links inside the body are inactive) => What about solving that with a redirect? As of now, the show of a fullfillment page works by manipulating the DOM from the extension's JavaScript, but it seems to be prone to these unexpected behaviours. |
|
|
ToDo: 1) check that UKP solver picks the most convenient coin (CHECKED) 2) tune the mint's config file to allow more discretized denominations (DONE) NOTE: when withdrawing 5 KUDOS, the wallet won't get a 5 KUDOS coin, because of the withdrawing fees! |
|
|
3) fix: 1 kudos chosen => 10 kudos shown on contract (FIXED) |
|
|
There is a 'window.screen' object which tells which screen is hosting a given DOM, but is a 'getter'; any link explaining how to *set* a screen for a DOM is welcome. |
|
|
Improving performance on Firefox https://developer.mozilla.org/en-US/docs/Mozilla/Performance see 'performance' branch |
|
|
http://archive.cpradio.org/code/javascript/dual-monitors-and-windowopen/ http://stackoverflow.com/questions/16363474/window-open-on-a-multi-monitor-dual-monitor-system-where-does-window-pop-up |
|
|
The links above seem to work only if the two monitor have the same width, which is the 99% of cases |
|
|
panel.openPopup(..) fails to open a popup though no errors are shown. panel.openPopupAtScreen(x, y) ignores the given coordinates EDIT: 1. window managers without draggable windows can deliberately ignore coordinates given to popup's definition 2. openPopup failed to open because it was given 'window' as anchor, instead of 'window.document.documentElement' |
|
|
Showing 'pick mint' dialog through a dedicated .xul, in order to avoid problems with dialog position. In contrast to the previous solution, the editable 'menulist' is NOT sensitive to manual changes, i.e. its 'value' attribute contains what programmatically given (in other words, the same script seems to behave differently when run within the .xul). The demo should work since the given mint is always "mints.demo.taler.net". |
|
|
Ok, so that looks already much better, the pop up for withdraw action is now in the right place and the dialog looks fine. The only issue now is that withdrawal can still take a few secs, leaving the user in a bit of an unsure state as the 'select mint' dialog is closed but the extension has not yet moved the main DOM to the 'success' page (and then we get that odd pop up reporting success as well). What we should do for now is show a dialog with just a progress meter: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/Progress_Meters Basically, when I select the mint, the dialog should close and be replaced with a dialog with a determinate progress meter: we know how many coins we will withdraw, so we can progress by the respective percentage for each coin. When all coins are withdrawn, the progress bar dialog should self-destruct (now being at 100%) and the main page should immediately advance to the 'success' page. And then there should be no pop-up. |
|
|
Ok, but there may be cases when the withdrawal takes long and it could be boring for the user having a central visible progress meter. What about some smallish notification just next to the button when all the coins have been withdrawn? Or having a little progress meter (like a spinning wheel or whatever) stuck to the Taler button? (Not sure how much XUL can help on that.) |
|
|
Yes, we could have some progress indication in/with the Taler button, but note that especially with non-cooperative banks, the "progress" may take hours or days, not seconds, so having something "annoying" there would be bad. Given that we'll show the balance anyway, maybe just an indicator "W"(ithdraw in progress) would do. |
|
|
The heavy operations which get the UI stuck are: 1) crypto to verify signature on /keys received at reserve creation time 2) DB operations to store gotten /keys 1) has been addressed by putting all the crypto work within a web worker, and it showed an improvement: when clicking "ok" the dialog disappears instantaneously now. 2) has been addressed by making all the DB work asynchronous, BUT it wasn't enough to entirely free the browser: a delay of +or- 2 seconds is still in place (though not as annoying as it used to be). Unfortunately, is not possible to put SQLite calls inside the worker: it allows only indexedDB, and there is no workaround for that. What task should take priority? 1) porting all DB work from SQLite to indexedDB, as Tg already suggested 2) keeping the wallet like this and fix other minor (or not-so-minor) things? |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-11-09 21:11 | Christian Grothoff | New Issue | |
| 2015-11-09 21:11 | Christian Grothoff | Status | new => assigned |
| 2015-11-09 21:11 | Christian Grothoff | Assigned To | => Marcello Stanisci |
| 2015-11-09 21:14 | Christian Grothoff | Description Updated | |
| 2015-11-10 18:35 | Marcello Stanisci | Note Added: 0009884 | |
| 2015-11-10 20:14 | Marcello Stanisci | Note Added: 0009885 | |
| 2015-11-12 10:28 | Marcello Stanisci | Note Added: 0009890 | |
| 2015-11-12 11:00 | Marcello Stanisci | Note Edited: 0009890 | |
| 2015-11-12 18:25 | Marcello Stanisci | Note Added: 0009891 | |
| 2015-11-12 22:02 | Marcello Stanisci | Note Edited: 0009891 | |
| 2015-11-12 23:26 | Marcello Stanisci | Note Added: 0009892 | |
| 2015-11-12 23:26 | Marcello Stanisci | Status | assigned => resolved |
| 2015-11-12 23:26 | Marcello Stanisci | Resolution | open => fixed |
| 2015-11-13 09:55 | Christian Grothoff | Note Added: 0009893 | |
| 2015-11-13 09:55 | Christian Grothoff | Status | resolved => feedback |
| 2015-11-13 09:55 | Christian Grothoff | Resolution | fixed => reopened |
| 2015-11-13 18:42 | Marcello Stanisci | Note Added: 0009894 | |
| 2015-11-14 22:23 | Marcello Stanisci | Note Edited: 0009894 | |
| 2015-11-14 22:24 | Marcello Stanisci | Note Added: 0009899 | |
| 2015-11-14 23:03 | Marcello Stanisci | Note Edited: 0009899 | |
| 2015-11-14 23:06 | Marcello Stanisci | Note Edited: 0009899 | |
| 2015-11-15 03:37 | Christian Grothoff | Note Added: 0009900 | |
| 2015-11-15 03:37 | Christian Grothoff | Status | feedback => assigned |
| 2015-11-16 16:40 | Marcello Stanisci | Note Added: 0009906 | |
| 2015-11-16 16:52 | Marcello Stanisci | Note Added: 0009907 | |
| 2015-11-16 16:52 | Marcello Stanisci | Status | assigned => feedback |
| 2015-11-16 21:14 | Christian Grothoff | Note Added: 0009908 | |
| 2015-11-16 21:14 | Christian Grothoff | Status | feedback => assigned |
| 2015-11-16 21:15 | Christian Grothoff | Note Edited: 0009908 | |
| 2015-11-17 13:32 | Marcello Stanisci | Note Added: 0009911 | |
| 2015-11-17 17:36 | Marcello Stanisci | Note Added: 0009920 | |
| 2015-11-17 22:13 | Marcello Stanisci | Note Edited: 0009920 | |
| 2015-11-18 10:21 | Marcello Stanisci | Note Edited: 0009908 | |
| 2015-11-18 10:23 | Marcello Stanisci | Note Added: 0009924 | |
| 2015-11-18 10:24 | Marcello Stanisci | Note Edited: 0009924 | |
| 2015-11-18 11:21 | Marcello Stanisci | Note Edited: 0009908 | |
| 2015-11-18 11:34 | Marcello Stanisci | Note Edited: 0009908 | |
| 2015-11-18 14:46 | Marcello Stanisci | Note Edited: 0009911 | |
| 2015-11-18 17:01 | Marcello Stanisci | Note Edited: 0009908 | |
| 2015-11-20 11:34 | Marcello Stanisci | Note Added: 0009931 | |
| 2015-11-20 11:34 | Christian Grothoff | Note Added: 0009932 | |
| 2015-11-20 13:52 | Marcello Stanisci | Note Edited: 0009931 | |
| 2015-11-20 14:26 | Marcello Stanisci | Note Added: 0009933 | |
| 2015-11-20 16:05 | Marcello Stanisci | Note Added: 0009934 | |
| 2015-11-20 16:58 | Marcello Stanisci | Note Edited: 0009934 | |
| 2015-11-20 22:10 | Marcello Stanisci | Note Added: 0009935 | |
| 2015-11-23 09:55 | Christian Grothoff | Note Added: 0009940 | |
| 2015-12-01 14:59 | Marcello Stanisci | Note Added: 0009966 | |
| 2015-12-01 15:49 | Christian Grothoff | Note Added: 0009970 | |
| 2015-12-07 16:54 | Marcello Stanisci | Note Added: 0009983 | |
| 2015-12-07 16:54 | Marcello Stanisci | Note Edited: 0009983 | |
| 2015-12-07 17:29 | Christian Grothoff | Status | assigned => resolved |
| 2015-12-07 17:29 | Christian Grothoff | Fixed in Version | => 0.0 |
| 2015-12-07 17:29 | Christian Grothoff | Resolution | reopened => fixed |
| 2015-12-10 11:08 | Christian Grothoff | Status | resolved => closed |
| 2019-12-26 21:37 | Florian Dold | Category | wallet (browser-based) => wallet (WebExtensions) |
| 2023-04-13 20:37 | Florian Dold | Category | wallet (WebExtensions) => wallet (WebExtension) |
