If we can't confirm that user has not used another channel to comment, then don't allow commenting at all. Otherwise, there's no point doing the check.
## Why
Lost in a rebase. The GUI clamping was just meant to complement this (so that user knows what's going on), but ended up being the only thing that was pushed.
## Changes
- If the fetch failed or still in progress, we ask the user to wait or simply refresh the page.
- If already commented from another channel, bail and inform via Toast.
- this way, you can choose an active channel for something like commenting but when that component is unmounted, you always go back to the default channel (like leaving page)
- Moved from reach/ui to material/ui menu components, because reach ui wouldn't work with 2 menus
- This channel selector stores the default on settings
- setActiveChannelIfNotSet was deprecated, if the account has channels, it will always return a channel even if there is no active channel or stored channel
- Make the chapters button appear consistently.
- Previously, it was only appearing for Original.
- We still hide it for mobile, as per previous explanation.
- Changed the Chapters button position and popup aesthetics.
799
## Issue
`TxoList` is not shown when balance is zero. A zero balance doesn't always mean zero transactions.
## Fix
Just like in other components, don't make `YrblWalletEmpty` a mutually-exclusive thing.
- Deemed not useful in mobile, unless you have an S-pen that can hover.
- The chapters button (that invokes the chapters popup) would make more sense in Mobile, but we need to deal with the limited controlbar space first (e.g. overflow menu system)
We were already limiting the call to once-per-5-minutes (for the succesful case), so just need to put failure cases into the mix.
Retry 3 times before stopping.
## Issue 1263
Previously, we tried to inform the user that when an SDK call such as `support_create` and `publish` fails (specifically, timed out), the operation could be successful -- please check the transactions later.
However, we only covered the case of `fetch` actually getting a response that indicated a timeout, e.g. "status = 524". For our SDK case, the timeout scenario is an error that goes into the `catch` block. In the `catch` block, we can't differentiate whether it is a timeout because it only returns a generic "failed to fetch" message.
## New Approach
Since `fetch` does not support a timeout value, the usual solution is to wrap it with a `setTimeout`. This already exists in our code as `fetchWithTimeout` (yay).
By setting a timeout that is lower than the browser's default and also lower than the SDK operation (90s for most commands, 5m for `publish`), we would now have a way to detect a timeout and inform the user.
Firefox's 90s seems to be the lowest common denominator ... so 60s was chosen as the default (added some buffer).
For the case of 'publish', it is actually called in the backend, so wrap the xhr call with a timeout as well.
