- 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.
- Corrected flow definitions.
- Properly differentiate between "not yet fetched" and "no membership" as "undefined" and "<empty string>", respectively. There are GUI elements that need to know the unfetched case.
## New behavior:
- If you have commented on a claim before, the channel selector will be clamped to that channel.
- There might be more than 1 channel if commented in the past.
- This includes blocked comments, i.e. if the creator blocked you, you will not see your comment, yet your channel-selector is clamped to the used channel.
- EXCEPTION: you can use other channels if it's your own claim (for now).
## Approach
- Run `comment.List` over all your channels on the specific content. This covers nested replies and pagination (sweet).
- So, if the total is non-zero, mark that channel(s) as having commented on the claim.
- Only fetch this once per content claim.
- In the comment channel-selector, clamp the list to this value.
## Issue
1075, spam prevention.
## Approach
- When making a reaction, fetch reactions for all my channels for the particular comment id, and reject the reaction is any was found.
- Report the channel name in the toast so that user can at least know which channel to select in order to undo the reaction.
## Ticket
1320
## Approach
- Create a layer on top of the `Lbry` to log failures. `ApiFailureMgr` encapsulates this.
- Only logging `claim_search` for now as a start. Can be used for all methods.
- When a `claim_search` (with the same options) repeatedly failed for 5 times within 500ms, block subsequent calls for a duration of 1 minute.
- These values can be adjusted.
Completely remove any need to update things on our side when a Category is added or changed.
Will need to inform homepage owners to directly translate the 'label' field, so we don't need to use our translation system.
## Issue
1378
> "Content Type: Any" uses `claim_type: [streams, reposts, channels]`, with `stream_types: ["video", "audio"]`, so channels aren't returned, and not any types of streams either. Probably shouldn't have `stream_type` filter there.
(This also happens in categories, but maybe wanted in there?)
## Root
Due to this line in `ClaimListDiscover`:
`defaultStreamType = SIMPLE_SITE ? [CS.FILE_VIDEO, CS.FILE_AUDIO] : undefined, // add param for DEFAULT_STREAM_TYPE`
Wanted to check if this fallback was meant for Categories only or any list, but the git history is not preserved because Odysee was a squashed single-commit back in the `SIMPLE_SITE` days.
## Change
Will assume it was meant for Category Page only and moved that line from the component and into the client-side.
This also means that clients of `ClaimListDiscover` without `streamTypes` and `defaultStreamTypes` defined will no longer have `stream_types: ['video', 'audio']` as the automatic fallback (they must define `defaultStreamTypes` themselves). I think this modal is clearer -- it doesn't make sense to have filters like "content=any" but overridden quietly to `video|audio`.
## Ticket
31: "quality selector not available on safari browsers"
## Notes
The quality selector isn't populated in some Apple products -- a known issue with videojs as the platform doesn't relay the info.
But it seems like only iPhone is affected, so let's enable the override for all platforms except iPhone.
## Ticket
1368
> can we remove the repost filter option on categories outside of wildwest/following?
## Approach
Using `context` to:
- reduce the amount of files that need to change.
- avoid prop-drilling.
- allow the ability to dynamically define the Filter's allowed values in a contained manner.
Clients that don't need customization simply does not need to wrap their component with the context.
The context only contains Content Type for now, but can include anything that future clients need to dynamically adjust.
## Ticket
Part of 1368 ("if user overrides the category homepage language with a different language setting + use 'search this language' option, use that instead. It's not typical this will happen, but probably expected.")
## Change
- Refactored to move more logic into `resolveLangForClaimSearch`
- Replaced the ternary version to make it more readable (hopefully).
- Inverted the language filter precedence by honoring the user's setting first.
- Note: for both User and Category, URLSearchParams will always take precedence.
- I got the previous logic completely wrong.
- Wild West's release time now comes from the homepage definition, but since the definition currently does not support "start of week", continue to hardcode the customization here.
- This logic also fixes the release_time for Tags.
