We are asking Outbrain to make it order-agnostic, but for now, we need to load the Sticky script first before the Banner script.
This is ugly code because the requirement is not obvious unless we put a bunch of comments, but I don't want to pollute `app/view.jsx`. Hopefully they can address this and we can revert in the coming days.
* Fix adnim ads
* Adjust ad container width
* Change widget on mobile
* Fix 3 column grid
* Ad ad banner top bar
* Ad ad banner bottom bar on mobile
* Ad ad banner bottom bar radius on mobile
* Adjust ad banners on mobile
* Make some mobile adjustments
* Remove dbeug box
* Combine ad classes
## Issue
Stickly loads fine when Category Page is opened directly (F5, open), but doesn't load if F5 was at Homepage and then navigated into Category Page.
## Root
There is a bug where AdsSticky cannot be loaded on a page where AdsBanner exists. As long as AdsSticky is loaded in a page without AdsBanner, they both can still be visible together later, says from navigating around.
## Temp fix
Adding inAllowedPath to the logic is a band-aid that relies on AdsBanner only being used in Homepage for now, which we currently happen to not place AdsSticky.
## Ticket
1583: "add incontent ads to category/channel pages (break up every X claims?), or add back bottom ad in those areas."
## Behavioral changes
- Hide when in homepage (as currently we have ads between categories).
- Fix the light theme (it was transparent).
## Code changes
- While an Effect is the 'right' choice given that there is no jsx to mount, the need to prop-drill from the parent was getting a bit annoying, so converted to a Component instead.
- Remove the delay for Core Vitals avoidance for now -- seems to make the sticky less likely to serve an ad.
- Now that the membership state is correctly populated for incognito (see 9d830615), there is no more need to check for `isAuthenticated`.
Using that global variable was a bad idea. Stick to redux as the source of truth.
The flag is not listed for rehydration, so it will always start off as `undefined`, which is what we need anyways.
`undefined` indicates we haven't tested for ad-blockers, so we'll run the fetch and update the store with a true|false value.
It would be nice if the individual components can handle the remounting of the ad-script, but there is currently a need to synchronize the cleanup of the `window.OBR` object.
The quickest solution for now is to add a key at the parent side to synchronize the mount-unmounting. Not ideal -- revisit later.
- This increases the amount of ads, filling up the entire width. No more need to restrict with `max-width` ourself.
- Changed the ad-driver to top-right since the "Powered by Outbrain" text is now locked in bottom-right. Also made the container having a minimum height, as the method to "display the driver after ads are loaded" is not future proof -- it depends on the IDs being used by the ad. Reserving some space seems to be easiest, and it also reduces shifts as well.
## Behavior in homepage
- Mobile: show after every other category
- Desktop: show after first category, then every 2 categories.
## Known issue:
- "FYP" is not part of the categories array at the moment, so it does mess up the behavior.
## Notes
I think this is also called "in-content" by adnim (not 100% sure of the terminology).
## Ticket
1572
Always check for availability before use.
## Changes
- Consolidated the keys into one place for easier tracking.
- It'll also be easier to code using constant autocomplete.
- Cleaned up the wrapper to be as close as the original.
- Updated existing code to use the wrapper (even if they already handled the availability) to encourage future code to just use the wrapper.
1446
- Requires an accompanying commit in `odysee-frontend`.
- The change assumes that the `odysee-frontend` is the only project that uses these files directly, i.e. other clients will use the API instead.
Was trying to save 1 state by assuming the homepage will be in a busy state and the ad-detection code will finish first. But this is not true for those with a small Following count.
* various cleanups
* more touchups
* select currency to use based on location
* fix sidebar
* fixing strings and other touchups
* refactor and do proper string interpolation
* fix stripe error
* text bugfix
* Adjust help
Co-authored-by: Thomas Zarebczan <thomas.zarebczan@gmail.com>
* Homepage-Following: insert instead of replace when ad-blocker is detected.
`window.odysee_ad_blocker_detected` was not meant to be used outside of `<Ads>`, since it wouldn't spark a GUI update. But since homepages are rendered several times, perhaps it doesn't matter and we can skip adding to redux for now.
* Handle uBlock origin
If refreshed via "Clear Cache and Hard Reload", the detection method fails, but it does perform an internal redirect, so treat that as a failure.
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.
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.
