- 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.
## Ticket
1358 - flicker on livestream tile when viewers updates
## Change
Defining the component that way results in unique Card wrapper on each resolve, so everything gets torn down and re-mounted, causing the flicker.
There is a css side-effect though: the tags changed from red to black. But tags are inconsistent through the app ... sometimes black, sometimes red (I think it should always be red + smaller font from the body).
Re-used lots of Anthony's code + made fixes to a few areas including the publish page.
a
new videojs
video.js@7.18.1 + http-streaming@2.14.2
remove console log
Mainly only useful for Wild West, which doesn't use `channel_ids` (otherwise, the homepage maintainer could just exclude the id from `channel_ids` directly).
- Router: no need to specify the route directly anymore (will come from definition), but we still need to disable it for certain regions.
- Sidebar: no need to custom addition anymore.
## Ticket
`odysee-homepages :: 1318`
It was previously done in `GetLinkData`, but accidentally removed in d854a992.
It is DRY-er to do it here rather than at the client side.
Also needed to filter in the homepage-sort dialog, so move the definition to a constant array.
## Ticket
1308, 1363 - "Hide/skip "removed" recsys entries"
## Change
Ported the `isAbandoned` handling from the list-layout to the tile-layout (yet another grumble on why tile vs. list is not just a css difference but an entire different component).
## Misc
Because "ClaimList + tileLayout" was showing abandoned claims by default, search around to see if it was still needed. I think only collectionsListMine would require that (or maybe not, can remove later).
* Fix report page on mobile
* Fix mature tag colors in light theme
* Adjust spacing for badges in navigation
* Fix reply input background for notification on mobile
## Ticket
1074
In mobile, the second livestream tile in Following gets missing because of the Ad being in 'replace' mode.
## Change
Switch from 'replace' to 'insert' mode in Mobile layout.
If missing (replaced) tiles is not a desired behavior, the true fix would be to always use 'insert' mode, and either live with the uneven tiles or wait for our design master's solution.
It was meant to be general-purpose in the first-place, but ended being tied to ads due to time constraint and also bad documentation.
No functional change.
## Issue
1345
## Change
The refactor in 04c5ac46 broke the logic, because `!hasCost` would incorrectly include an undefined `costInfo` (haven't fetched) as free content.
## Issue
??
## Behavioral Changes
- Use `claim_search` instead of `claim_list` to retrieve all all own claims with the same name (case-insensitive).
- Caveat: annonymous posts will be excluded.
- When a clash occurs, there is a possibility that we have multiple existing entries (e.g. "xxX", "xXx"). Since we don't know which one is best to fall back, I removed the "edit" button for this and replaced with a simpler text
## Code Note
- If not mistaken, the rest of the code still needs `selectMyClaimForUri` to be case-sensitive, so augment the selector to support both through an optional parameter.
As of this commit, only the Channel Page is fetching the data through the new API, which has the viewer count correctly populated.
For both "0" and "undefined", continue to show as "LIVE".
The code currently supports both the baked-in homepages, as well as fetching from `/$/api/content/v1/get`.
As the latter is currently a circular round-trip, just use the baked-in version until the service is moved elsewhere. Loading performance will be better.
Just like ClaimListDiscover, stop `claim_search`-ing if the result is a failure (null).
Leaving the placeholder tiles as is for now. Can show the timed out message like ClaimListDiscover -- just toggle SHOW_TIMEOUT_MSG.
Potentially closes 1319
## Note
- `persistor.purge` returns a promise, we should wait for the resolved results before reloading, instead of just adding an arbitrary `setTimeout`.
- Perhaps the `setTimeout` method is to ignore a super-long or hanged purge (not sure), but it wouldn't be right since it would end up in a limbo state.
- Log errors to get clues for future.
- Reduced code by moving the reload to `finally`.
## Change
Due to "Own Comments" being implemented the same way as "Discussion Page", the comment lookup did not work for the abandoning case.
Just skip the local cleanup of `byId` -- it doesn't matter, as the GUI uses `selectCommentsForUri` to grab the per-channel comments, so it would still disappear in the GUI immediately.
## Ticket
1307 newly added categories aren't adding to existing customized homepage
## Change
In Customize, new categories were appended at the bottom, but forgot to repeat the behavior on the actual homepage itself.
## Issue
Desktop 7022: i18n: Notification title localization lost
## Approach
The current code breaks up the string into an array of strings, so i18n is somewhat impossible.
Since 99%¹ of dynamic notifications come with a `dynamic` property for all the replaceable values, we can actually reconstruct the string however we want.
¹ <sub>_as far as I can find, only `fiat_tip` does not provide the value via `dynamic`, i.e. hardcoded in the string. Boo._</sub>
### Benefits of this approach:
- able to localize the string again
- able to customize the string (e.g. making claim titles italic, fix typos, use more concise strings, etc.)
### Problems with this approach:
- if the api overloads a particular notification type with several strings, then the approach is broken.
- Ex. For the case of `comment` type, the overload is whether the comment is a normal comment or hyperchat. But I was able to replicate the logic to differentiate them, so all is good.
- For the case of "livestream reminder in 30 minutes", we would have to inspect the string to differentiate against "is live streaming". I think this reminder is not being used, so I didn't do it yet.
- some work is needed to maintain the code when the server side updates something. But we are already manually maintaining the i18n strings anyway, so it shouldn't be too much of a burden.
- With the exception of the overload problem, any new notification type will simply pass through as un-localized, so things should continue to work, i.e. no need to update the front-end immediately 🤞
Ticket: 1180
I believe the original intention was "if a claim was previously resolved, but without authentication (no `is_my_output` data), then resolve again with `include_is_my_output`"
Update to exclude that logic for Incognito.
## Aside
The check for `!canonicalUrl` is interesting:
- Are there claims that really don't have `canonical_url`? If yes, would that end up in an infinite `resolve` loop?
- When collapsing, scroll back to the first comment instead of hanging in the Recommended section.
- Enhancement for 5380bc04: don't show "Collapse/Expanse" if there's only 1 comment. The comment itself is already collapsed to 3 lines, so it won't take up too much height.
- Fix css: recalling what Dan mentioned: if following BEM right (modifiers shouldn't be used standalone), we wouldn't incorrectly use `@extend` in this case and confuse the reader.
- Enlarged the empty spacing to make it symmetrical with the Recommended section below it.
## Issue
Thumbnails in mobile, especially tablets, is blurry
## Change
Account for the larger thumbnail width in mobile.
Approximation is based on `$breakpoint-small: 900px;`
## Issue
In Medium layout, the Expand/Collapse button would still appear even for 0 comments.
## Approach
Hide the button when comments = 0, but didn't hide the section because the separator line feels useful as a visual guide to mark the sections.
## Issue
- Due to the timer used, the script could be loaded after the path-checking useEffect ran.
- Stale closure is also an issue.
## Approach
Create refs for the props, and listen to `onload` as well to resolve the visibility state.
## Issue
- Adding `content__non-clickable` everywhere probably isn't the right way when we move forward to separating `all.scss`.
- Not intuitive -- easier to use if it's an attribute to `ClaimPreview`.
## Change
- Consolidate to a re-usable `non-clickable` class.
- Made Wallet Send search preview non-clickable as a temporary band aid until the channel-finder is consolidated.
- `listBlocked`: something is overriding the pointer, so non-clickable isn't working. Removed for now -- doesn't really matter.
https://github.com/AdeleD/react-paginate/ issues/125#issuecomment-276625181
Apparently, the page bubble cannot be made clickable due to accessibility issues, so the click area is very small.
Changed the css as suggested by the maintainer.
## Issue
Ticket: 108
## Interesting
Uploads Page uses `claim_list`
Channel Page uses `claim_search
A second `claim_list` would instantly show updated results, but `claim_search` takes a long while to reflect the deletion.
## Change
This PR only handles the `claim_list` (Uploads Page).
The `claim_search` version would be troublesome to handle. If a refresh would bring back the results (due to the `claim_search` slow update behavior), we would need to store the deleted claim persistently. Then ...
- Store where? rehydrate?
- When to clear?
- How to make each `ClaimList` filter this out without polluting the code? etc.
...will be messy. Feels easier to "fix" at the `claim_search` level to make it update faster (maybe a command to clear cache at server or something).
Ticket: 1256
For `notify`, "file is currently locked" and "no such file or directory" is indication that the previous "failed" SDK call actually worked. Tell the user to check the transactions.
This is the band aid until odysee-api/401 is addressed.
## Cause
It broke because lack of awareness that we can't use our components in preview mode. For some reason, we don't have redux access in SimpleMDE's preview mode.
## Change
- Restore the stub for iframes
- Fix preview for images, and apply the same styling as in posts.
Partial copy from https://github.com/Rovak/InlineAttachment
We need to make some changes to handle xhr errors. Given than the repo hasn't been updated in 7 years, and it's a hassle to push the changes or fork the repo, just copy over the required files.
pinnedUrls = resolve
pinnedClaimIds = claim_search
Make `pinnedClaimIds` take precedence for now, since the homepage is defining both to support Android.
For some reason, I previously made `pinnedUrls` the priority, thinking this should be the "correct" one to use when the SDK is fixed.
## Issue
Maybe related to https://github.com/OdyseeTeam/odysee-frontend/issues/99#issuecomment-1042384649
## Notes
`fileInfo` does not contain `metadata` anymore -- not sure what happened. With zero duration, `videoPlayedEnoughToResetPosition` was never true.
But the claim usually contains the duration already, so we can use that. There are some audio/video claims that don't, but those are a minority.
Expanded homepage pins to support 2 types of input (if both are passed in, pinnedUrls take precedence):
(1) pinnedUrls --> uses doResolveUris (resolve)
(2) pinnedClaimIds --> uses doResolveClaimIds (claim_search)
Instead of injecting the pinned URLs directly, we inject from `resolvedPinUris`, which will be blank until the uris are resolved, thus preventing it from being resolved individually from the tiles.
There's additional complexity with the `claim_search` method, as the rest of the code deals with uris instead of IDs. Fortunately, it's all contained with `useResolvePins`, so removal would be easier when the batch `resolve` issue is fixed.
Ticket: 1228
## Code changes
- Pass through `getTimeAgoStr` so that the value gets localized.
- Pass the simpler `number` around instead of the `moment` object for better memoization.
## Notable differences
Due to how `getTimeAgoStr` is written, we now get to see the time actually counting down, vs "in a few seconds" currently in production. I think the counting-down behavior was the original intentional, since a 1s timer was used (otherwise, a 1-minute timer could be used) ... or maybe not since streams may not start on the dot.
