* Remove ad-handling in videojs.jsx
Primary impetus is to remove unnecessary IntersectionObserver usage, but it should be removed anyway because:
- no longer relevant today with Adnimation's script.
- we also globally hide floating ads now, so no more invisible divs.
- the code is wrongly placed -- it's not the responsibility of the Videojs component.
* use-lazy-loaded: skip if IntersectionObserver is not supported
## Issue
Page not loading in older Safari (e.g. ipad air 2)
## Approach
Instead of using a polyfill (which comes with implementation caveats), just not apply the lazy-loading for those old browsers. Not lazy-loading is better than not loading at all, plus this is way easier to test (even by just reading the code) than testing out the polyfill implementation's caveats.
The cons is we would need the polyfill if we use it in other places in the future.
## Code Changes
Factor out the src-setting code, and use it directly when IntersectionObserver is not found.
* PublishReleaseDate: improve calendar error handling
Ticket: 1738
- Report invalid `minute` and `day`. The 3rd-party widget auto-corrects the other fields. Don't think there is a way to make it autocorrect for all.
- Report invalid range (cannot set to future date).
* Block form on releaseDate error instead of silently sending last valid value
which does not tally with what's on screen.
## Issue
1709 - If you sign in while reporting, you end up in the homepage
## Notes
The other option is to just make `<Header>` always redirect back to where it came from using the full path. But existing code elsewhere seem to always trim off any params (e.g. `location.search`, `location.hash`) when doing redirects.
So, ended up making it generic and let the caller decide where to redirect (and with what params).
In `doResolveUri`, if the `uri` is a collection, it will attempt to fetch all items in the collection.
Can't think of any special reason to keep the page-size small, and not seeing any notes in the commits either. It just ends up making several `claim_search` of 5's until all items are fetched.
I previously hardcoded both IDs since the script was not looking the right one at one point, but I guess that was unnecessary.
I don't think it causes any problems, because I'm still just loading 1 script (no double video, just 2 divs for them to choose).
Note that we are still using the `filepage` script since the `homepage` one is not working.
## Ticket
1526 strange thumbnail size requested on mobile layout (pc only?)
## Notes
The 900px was to account for blur tile thumbnails in mobile homepage (4f4803c6).
Fix to only do that in tile mode.
## Ticket
1526: strange thumbnail size requested on mobile layout (pc only?)
## General Problem
It was trying to fetch based on the exact size of the video container, which would satisfy Core Vitals (in an overkill way), but would bring several issues:
- server-side caching would not work since everyone's window size is different in a responsive layout design.
- the additional 200ms wait for container size to settle down is not good (hardcoded wait time).
- the code did not account for device-pixel-ratio, so it's quite a futile effort.
Aside: In the past, we used to take the same image url as the tiles, so the video poster would appear immediately from due to browser cache, but the quality is bad because the tile requested a much smaller size.
The embed wrapper was not going through the CDN either as a null `containerRef` was passed in.
## Change
Removed the container-size check and just request for 1280x720. Reasons for this size:
- On average, that would be the ballpark of the final calculated value anyway for the average screen (+DPR consideration).
- That seems to be the current suggested thumbnail size in most recommendations.
- Our YT Sync is grabbing a much smaller size anyway.
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 bug and add some documentation
* Prevent is_live fetching when playing stream and going back to livestream page
Co-authored-by: Rafael <rafael.saes@odysee.com>
Fixed the title that did not update from stale closure because we no longer re-initialize the plugin.
We still continue to sever the connection when switching sources for now (although videojs is now single-instance) due to a problem that stops the next remote playback after 5-10 seconds. Unclear whether it is the plugin problem or due to our changes (although I don't see this issue in their repo).
