## Fixes:
4220
## Changes:
For `vjs-layout-small`, there is still space to display the said controls. This layout covers devices like Galaxy S5 up to Nexus 6P.
For layouts smaller that that (e.g. 'vjs-layout-xsmall'), they will remain hidden.
## Fixes:
4351: "Infinite load won't work if the same sort option clicked"
Test case:
1. Click Following
2. Click New
3. Scroll down to load at least 1 extra page.
4. Go up and click New again.
## The Issue:
`scrollBottomCbMap[page]` in this case did not reset since the `id` remained the same.
## The Fix:
I don't know how else to notify the effect to run. Perhaps "when `page=1`" is one criteria, but I found that removing `scrollBottomCbMap` can also fix it.
I don't know what scenario that `scrollBottomCbMap` was originally meant to handle, so will need to depend of reviewer to confirm I did not break something else. This fix assumes that recent inf-scroll fixes and debouncing would have addressed the "weird stuff happening with fast scrolling" problem mentioned in the comments.
The previous code was simply delaying the handler, which served the intention of the time, which is to avoid using the wrong coordinate from querying too early. However, we ended up servicing each scroll message.
This is the proper fix, and should technically make scrolling smoother. Maybe this will fix 3576 as well, although I don't see much difference.
## Fixes:
3071: "Infinite scroll stops working when navigating to file page / back"
## The Issue:
In the POP operation, the `page` value is back to 1 due to the initializer `useState(1)`. If the results cache already contained more than 1 page's worth, then the rest of the logic thinks there's nothing to do.
## The Fix:
Previous fixes to Inf-Scroll added a "page correction" code to handle the mismatch. This fix simply adds this scenario to the list of scenarios to perform the correction.
## Fixes:
4214
## Approach:
`ClaimList` currently only shows the loading indicator if there is a header. We could make the indicator always appear at the top of the list when `loading=true`, but that would be the list jump up and down as the indicator appears/dissapears. I assume that is too distracting and is the reason why it was not made that way in the first place.
Show the indicator in place of the Refresh button while fetching instead.
## Fixes:
3641 Language switch does not take effect right away
## Assessment:
Although `Card`s in the Settings Page are actually being re-rendered, the `actions` within them might not be getting the signal, depending on their props.
## Changes:
(1) Pass the language variable to the `actions`'s props for items that are affected.
(2) Make the Wunderbar listen to language-changes as well (the only component outside of Settings that would need an immediate update).
1. Use a constant for the classname instead of being hardcoded.
2. Use existing 'debounce' function instead of introducing another.
3. Added changelog entry.
Fixes #-4021.
## Changes:
When the autoplay overlay gets partially off-screen, the timer will be stopped. We can tweak how much down it needs to be scrolled.
When timer is paused, the countdown resets.
The pausing mechanism has no effect on the floating player (since the 'top' can never go negative). This behavior is the same as another big video platform.
---Fixes:
#-2882: "Fix UX around publishing to already published URL".
---Changes:
1. Improved the error message (change color to red; emphasized the URL; tweaked the sentences a bit).
2. The `Publish` button will be grayed out in this scenario, until user explicitly decides to edit existing claim instead.
--- Issues:
(1) #-2669: Page does not restore to top when navigating new tags.
(2) "Encountered children with the same key" error (duplicate entries shown).
https://github.com/lbryio/lbry-desktop/issues/4367#issuecomment-645449206
--- Changes:
(1) Ignore the history if it's a new query (i.e. explicitly clicked). The BACK history will still behave as normal (doesn't reset to top).
(2) Previously, the `page` variable will continue to increment as you scroll and stay within the page (e.g. Trending vs New, or clicked another Tag). As you move between queries, we hit a scenario where `page` is significantly under or over the latest retrieved `claimSearchResult.length`. This messes up the rest of the code.
Fix by correcting the value of `page` according to the current `claimSearchResult.length` when necessary.
