Prevent the 'arrow' of a message bubble from being sporadically anchored
to the wrong side - appearing on the left instead of the right hand side
of the bubble. This is due to the same ListCell object being reused by
JavaFX for different bubbles as the user scrolls up and down the chat
pane, which requires that the anchors of each arrow be properly cleared
between ListCell.updateItem(..) calls.
To this end, move the block of AnchorPane.clearConstraints(..) calls to
the beginning of the updateItem(..) method, as the apparent assumption
that 'updateItem(item, empty = true)' will always be called to clear the
given ListCell before reusing it as a new bubble turns out to be wrong.
Use stricter criteria when deciding which of the taker's accounts (if
any) are valid for a given offer. Specifically, prevent National Bank
accounts from being used to take Same / Specific Bank(s) offers, so the
three payment method types can never being mixed.
This prevents an error on the trading peer when the trade starts, due to
enforcement of equal maker & taker payment method IDs (except for SEPA)
in the Contract payload constructor.
This partially addresses #3602, where the erroneous peer response causes
the taker to be presented with a confusing timeout.
Remove redundant stubs from the MoneyGram and Western Union tests and
ensure that all such stubs result in failure. In particular, the 'offer'
mock is never accessed directly by ReceiptValidator.
Now that there are cases where the SequenceNumberMap and Broadcast
are called, but no other internal state is updated, the existing helper
functions conflate too many decisions. Remove them in favor of explicitly
defining each state change expected.
Now that we have introduced remove-before-add, we need a way
to validate that the SequenceNumberMap was written, but nothing
else. Add this feature to the validation path.
This prevents a scammer to use publicly known account details
(without being in control of the account) as a seller to get
signed by a buyer. The money received in the seller account might
not be detected by the legitimate owner and/or the money not sent back.
30 days later the scammer could use this signed account as seed to peer sign other stolen accounts.
* Updated price node list for monitor
* Price monitor is more resilient against timeouts
Recenty, a price node got removed. Unfortunately, this node
has been the first in the list of configured price nodes in
the monitor configuration.
A misplaced catch block caused the loop to stop instead of
trying the next configured price node in the list.
* Monitor selects a price node randomly
Up until now, the monitor always chose the price nodes
in their configured order. This resulted in querying
always the same node and thus, create a bigger system
load for this very node. Only in case of a failure,
the monitor moved on to another node.
Shuffling the list of nodes prior to querying provides
at least some load balancing for the price nodes.
* Fixed monitor market API query
The format of the market API response changed. Formerly,
there has been one line, now it is pretty print json.
* Add RefundAgent messages to monitor
Add the relatively new RefundAgent message to the monitor.
* Adjust monitor timeout
Observed, that a timeout of one minute works better than
the original 90 seconds.
It is possible to receive a RemoveData or RemoveMailboxData message
before the relevant AddData, but the current code does not handle
it.
This results in internal state updates and signal handler's being called
when an Add is received with a lower sequence number than a previously
seen Remove.
Minor test validation changes to allow tests to specify that only the
SequenceNumberMap should be written during an operation.
Addresses the second half of #3629 by using the HashMap, not the
protectedDataStore to generate the known keys in the requestData path.
This won't have any bandwidth reduction until all seednodes have the
update and only have the 32-byte key in their HashMap.
fixes#3629
Addresses the first half of #3629 by ensuring that the reconstructed
HashMap always has the 32-byte key for each payload.
It turns out, the TempProposalStore persists the ProtectedStorageEntrys
on-disk as a List and doesn't persist the key at all. Then, on
reconstruction, it creates the 20-byte key for its internal map.
The fix is to update the TempProposalStore to use the 32-byte key instead.
This means that all writes, reads, and reconstrution of the TempProposalStore
uses the 32-byte key which matches perfectly with the in-memory map
of the P2PDataStorage that expects 32-byte keys.
Important to note that until all seednodes receive this update, nodes
will continue to have both the 20-byte and 32-byte keys in their HashMap.
Remove the type parameter from Popup<T>, as it appears to have never
been used or set anywhere in the code. (This mainly involves replacing a
lot of "new Popup<>" occurrences.)
* Implement installation path check on Windows
Prior to starting the installation, check if the install location
contains special characters and if so use a different default install
location as well as display a prompt to the user providing additional
details.
This is in response to #3605, for which a proper solution has yet to be
found.
* Ensure the destination location dialog is always shown
This resolves#552
* Show the Welcome dialog
Rather then potentially being greeted with the newly implemented
prompt on the destination location dialog if they have special
characters in their install path, greet the user with the Welcome
dialog when they initially launch the installer.
* Reorder/group setup items logically
Rather then potentially being greeted with the newly implemented
prompt on the destination location dialog if they have special
characters in their install path, greet the user with the Welcome
dialog when they initially launch the installer.
Prior to starting the installation, check if the install location
contains special characters and if so use a different default install
location as well as display a prompt to the user providing additional
details.
This is in response to #3605, for which a proper solution has yet to be
found.
