The solution didn't work 100%, only reduces the chances of happening significantly. So far, still can happen on hot-reload during development.
- Reverted 15bd26399f.
- Fix by just hiding the unoccupied aniBox
## Issue
Double ads on screen
## Reproduce
- Pre re-design:
- Change "Only Language" from tne locale nag.
- Post re-design:
- Follow a bunch of channels with active livestreams. The homepage ad will show 2 ads stack on each other, with second one invisible.
Both should be equivalent, just different UI/style.
## Analysis
In both cases, it is due to `removeIfExists` failing to remove the element if the ad script hasn't run yet.
This can happen when the component is re-mounted immediately after the ad script was added. When the effect-cleanup runs, the script have not started or is running halfway.
Aside: The need to run `removeIfExists` further strengthens my hunch that the script is meant to live throughout the lifetime of the app, with it populating the given div as we navigate. But just my guess.
## Approach
Clean up before adding the script as well. This covers any missed elements from the previous cleanup.
The drawback is that this approach assumes there will only be 1 ad per page, but that's pretty much the case with the existing `removeIfExists` approach.
- Initially, we did a bunch of forceful CSS to make the ad tile resize properly when the browser resizes. This was causing the EU ad to display incorrectly. Turns out, that css is no longer needed after the BEM-style re-write.
- Changed the floating ad selector to cover both EU and non-EU version. It's probably still not the best given it relies on style rather than ID, but the ID seems dynamic.
- Removed "customAniviewStyling"
- No longer exists -- it was from the old DOM manipulation method.
- Removed "with no tileLayout it indicates sidebar ad"
- Misleading and not useful. I can easily set the sidebar ad to Tile if we wanted to (it used to be in Tile, we changed to save space). So, every time we change the style, we need to update the comment??
- The sidebar is not the only place that List layout is used -- there's Channel and Category pages, which allows either layout.
Closes 605 "Add pagination support to channel search"
## Previous Attempt
The previous attempt (69de63c4) didn't work because the wunderbar is part of the list component, so it is unmounted when we switch between the Normal and Filtered list, causing it to lose focus while typing.
Also, creating another full-blown ClaimList* component is really redundant (we should be consolidating instead).
## Approach
ClaimListDiscover recently added a new `subSection`, so we can place the filtered `ClaimList` here without causing the wunderbar to unmount.
Wrapped the "lighthouse search with channel_id" into `searchResults.jsx` for now as a quick and isolated solution. When we refactor ClaimList*, we can then consider incorporating into `doSearch`.
The tile placeholder method didn't work well because the component doesn't know how big the page size is, so we always end up rendering 1 placeholder tile, followed by N (= page size) placeholders (if not yet resolved). It's pretty ugly.
Removed comments:
- Incorrect/misleading: "injected item" does not mean "ads". It can be any React component that you want to put at a specific index.
- Redundant: don't explain the syntax. It's very annoying having to maintain the comment when the logic changes.
Since we are temporarily disabling the floating ad, it means that the invisible close button issue in Firefox Android is also temporarily not an issue.
- Instead of 2 ways to display ads (DOM injection + React method) and having both of them clash, just do it the predictable React way.
- Augment the existing React version to support tile layout + ability to place in last visible slot.
- Consolidate styling code to scss ... DOM manipulations were making it even harder to maintain.
- Removed the need to check for ad-blockers for now. It was being executed every time an ad is displayed, and now that we are displaying ads in more places, the gains doesn't justify the performance loss. Also, it wasn't being done for Recommended ads anyway, so the inconsistency probably means it's not needed in the first place.
Other known issues fixed:
- double ad injection when changing language via nag.
- additional "total-blocking-time" due to ads at startup removed.
- fixed ads not appearing in mobile homepage until navigated away and back to homepage.
- enable ads in channel page.
- support for both List and Tile layout.
Since `triggerBlacklist` is just a simple boolean and `<Ads>` is not doing any additional logic on top of it, it doesn't make sense to pass as a parameter. Just not mount the component -- it's more concise and obvious at the client side.
Ticket: 1018
Reference: 2575c5d
- Restored position of the ad to the 4th slot.
- Moved repeated query out of the map predicate (`droppableProvided ?`)
- For draggables, make the injected item always on top for now. There are draggables with injected items at the moment.
## Cause
When 'selectRecommendedContentForUri' is filtering results against the blocklist, it relies on claim data which could be unresolved yet. It filters to empty results for this scenario, hence the flashing message.
## Change
Just return raw results when claims are not resolved yet, so that the GUI knows it needs to show the placeholders while resolving. After resolving, it'll go through the blocklist filtering again.
## Issue
Closes 1020 strange refresh on signup + youtube sync
It's due to the sync-on-focus.
## Change
Only show the spinner for the initial wallet sync. I thought we can do without the spinner for sync completely, but based on the comments below, better to retain that for the initial sync. I think the rest of the stages don't need to block over a sync call.
```
// Don't claim the reward if sync is enabled until after a sync has been completed successfully
// If we do it before, we could end up trying to sync a wallet with a non-zero balance which will fail to sync
```
This is a follow-up for #1016
Still doesn't affect anything at the moment, but this reduce the amount of work needed when we yank out the homepages from our bundle later.
