Extend addresstablemodel to return the display name from the wallet and
set it to the addressbookpage window title when its model is set.
Github-Pull: gui#757
Rebased-From: 58c9b50a95
From https://geti2p.net/en/docs/api/samv3:
If SILENT=false was passed, which is the default value, the SAM bridge
sends the client a ASCII line containing the base64 public destination
key of the requesting peer
So, `Accept()` is supposed to receive a Base64 encoded destination of
the connecting peer, but if it receives something like this instead:
STREAM STATUS RESULT=I2P_ERROR MESSAGE="Session was closed"
then destroy the session.
Github-Pull: #28077
Rebased-From: 5c8e15c451
Background:
`Listen()` does:
* if the session is not created yet
* create the control socket and on it:
* `HELLO`
* `SESSION CREATE ID=sessid`
* leave the control socked opened
* create a new socket and on it:
* `HELLO`
* `STREAM ACCEPT ID=sessid`
* read reply (`STREAM STATUS`)
Then a wait starts, for a peer to connect. When connected,
`Accept()` does:
* on the socket from `STREAM ACCEPT` from `Listen()`: read the
Base64 identification of the connecting peer
Problem:
The I2P router may be in such a state that this happens in a quick
succession (many times per second, see https://github.com/bitcoin/bitcoin/issues/22759#issuecomment-1609907115):
`Listen()`-succeeds, `Accept()`-fails.
`Accept()` fails because the I2P router sends something that is
not Base64 on the socket:
STREAM STATUS RESULT=I2P_ERROR MESSAGE="Session was closed"
We only sleep after failed `Listen()` because the assumption was that
if `Accept()` fails then the next `Listen()` will also fail.
Solution:
Avoid filling the log with "Error accepting:" messages and sleep also
after a failed `Accept()`.
Extra changes:
* Reset the error waiting time after one successful connection.
Otherwise the timer will remain high due to problems that have
vanished long time ago.
* Increment the wait time less aggressively.
Github-Pull: #28077
Rebased-From: 762404a68c
The recent payment requests list has somewhat broken functionality. You can only
select contiguous rows. Sorting the list loses the selection data. The context
menu appears when multiple rows are selected despite the actions only affecting
the first in the list. These issues are all corrected.
First, a QSortFilterProxyModel is inserted to take care of sorting instead of sorting
the model manually. This also preserves selection data when sorting. Second, the
selection model is changed to ExtendedSelection to allow for non-contiguous multi-
select. Third, the context menu now operates on multiple selections properly. It will
copy newline-separated rows of data if appropriate.
Github-Pull: gui#684
Rebased-From: a6f567590b73986fde83d8face6827e0801a2e8c
a13670090d doc: update release notes for 25.1 (fanquake)
e8d5c35e80 doc: update manual pages for 25.1 (fanquake)
9e00b73ee7 build: bump version to 25.1 final (fanquake)
Pull request description:
Final changes for `v25.1`.
PR for bitcoincore.org is here: https://github.com/bitcoin-core/bitcoincore.org/pull/991.
No additional changes have been backported since rc1 (tagged 14 days ago),
and no bugs or issues have been reported (test bins have been available for 9 days).
ACKs for top commit:
hebasto:
ACK a13670090d.
TheCharlatan:
lgtm ACK a13670090d
Tree-SHA512: 037f937dd4d2a9de15ff15a80f35b6047b61ffc3d9a33e7d4a4fcbce6302569bbc516c6da5849211b34ebbe914c4edcdd182e2d1d43897d0dcd32834ce6f2574
10f3f813b2 doc: add release notes for 25.1rc1 (fanquake)
71aed7aa31 doc: update manual pages for 25.1rc1 (fanquake)
02f059c819 build: Bump version to 25.1rc1 (fanquake)
dc1fcec026 doc: add 25.0 release notes (fanquake)
Pull request description:
Final changes to tag a `25.1rc1`.
Bumps version numbers, man pages, adds release notes etc.
ACKs for top commit:
dergoegge:
ACK 10f3f813b2
hebasto:
ACK 10f3f813b2, I have reviewed the code and it looks OK.
willcl-ark:
ACK 10f3f813b2
stickies-v:
ACK 10f3f813b2
Tree-SHA512: 3e1c527dac06afb4c8e1e481055211f69aa0ed769ac242ed610d23d470bbc0c062227034d01876ba4a5fa836e953fb001e8b0d6bc026069d372d34b8a031fb25
It is possible that the client disconnects before the request is
handled. In those cases, evhttp_request_set_on_complete_cb is never
called, which means that on shutdown the server we'll keep waiting
endlessly.
By adding evhttp_connection_set_closecb, libevent automatically
cleans up those dead connections at latest when we shutdown, and
depending on the libevent version already at the moment of remote
client disconnect. In both cases, the bug is fixed.
Github-Pull: #28551
Rebased-From: 68f23f57d7
There is no significant benefit in logging the request count instead
of the connection count. Reduces amount of code and computational
complexity.
Github-Pull: #28551
Rebased-From: 084d037231
Introduces and uses a HTTPRequestTracker class to keep track of
how many HTTP requests are currently active, so we don't stop the
server before they're all handled.
This has two purposes:
1. In a next commit, allows us to untrack all requests associated
with a connection without running into lifetime issues of the
connection living longer than the request
(see https://github.com/bitcoin/bitcoin/pull/27909#discussion_r1265614783)
2. Improve encapsulation by making the mutex and cv internal members,
and exposing just the WaitUntilEmpty() method that can be safely
used.
Github-Pull: #28551
Rebased-From: 41f9027813
Update Node window with the chain type except for mainnet.
This replicates the behaviour of the main window.
Github-Pull: gui#758
Rebased-From: 9d37886a3b
By moving the appMenuBar destruction responsibility to the QT
framework, we ensure the disconnection of the submenus signals
prior to the destruction of the main app window.
The standalone menu bar may have served a purpose in earlier
versions when it didn't contain actions that directly open
specific screens within the main application window. However,
at present, all the actions within the appMenuBar lead to the
opening of screens within the main app window. So, the absence
of a main app window makes these actions essentially pointless.
Github-Pull: gui#751
Rebased-From: bae209e387
As the 'QMenuBar' is created without a parent window in MacOS, the
app crashes when the user presses the shutdown button and, right
after it, triggers any action in the menu bar.
This happens because the QMenuBar is manually deleted in the
BitcoinGUI destructor but the events attached to it children
actions are not disconnected, so QActions events such us the
'QMenu::aboutToShow' could try to access null pointers.
Instead of guarding every single QAction pointer inside the
QMenu::aboutToShow slot, or manually disconnecting all
registered events in the destructor, we can check if a
shutdown was requested and discard the event.
The 'node' field is a ref whose memory is held by the
main application class, so it is safe to use here. Events
are disconnected prior destructing the main application object.
Furthermore, the 'MacDockIconHandler::dockIconClicked' signal
can make the app crash during shutdown for the very same
reason. The 'show()' call triggers the 'QApplication::focusWindowChanged'
event, which is connected to the 'minimize_action' QAction,
which is also part of the app menu bar, which could no longer exist.
Github-Pull: gui#751
Rebased-From: e14cc8fc69
