- Auth (excluding notifications*) APIs
- Mixes
*Notifications currently require the "connection_channel" channel
for talking with the notifications job. Unfortunately, we cannot
access that within the route modules yet.
* use the new youtube api for comments
* remove PG_DB & action parameter + allow force region
* support new comments data with onResponseReceivedEndpoints
* Extract primary channel routes from invidious.cr
Also removes timedtext_video stub since all it does is redirect to the
homepage. However, Invidious's 404 handler already does this.
--
As the template for the channel about page doesn't exist yet, the
behavior for the /channel/:ucid/about endpoint has been changed to be
the same as what's currently present on Invidious
(cherry picked from commit 8fad19d8057d7d22e3de27ebbc88a9978c1df27b)
* Manually extract brand_redirect from 1b569bbc99207cae7c20aa285f42477ae361dd30
This commit manually extracts the brand_redirect function from the
commit mentioned.
However, the redirect to the `.../about` endpoint is removed due to the
fact that it doesn't exist yet.
This commit is also mainly just a bridge for the next few cherry picks from
\#2215
* Update brand_redirect to use youtubei resolve_url
(cherry picked from commit 53335fe7cfdfac392365b7cac447bc7cc6478134)
* Add additional channel endpoints to brand_redirect
(cherry picked from commit 8fc6f3add637dabb09b2034f4d82fc3d039ba15c)
* Add separate handler for /profile endpoint
* Add /channel/:ucid/home route
* Document all channel brand_urls
* Move Crystal stdlib classes overrides to a separate file
* Document known crystal overrides
* Update crystal overrides for HTTP::Client socket
* Update shard.yml to restrict crystal versions
* Fix compilation error in Crystal 1.1.x (See
https://github.com/crystal-lang/crystal/issues/10965
for more details about this issue).
The private `_post_json` method of the YoutubeAPI requires a ClientConfig
as the third parameter. This was passed in all Youtube API methods except the
`#resolve_url` method.
* Put youtube API functions under the YoutubeAPI namespace
* Implement the following endpoints:
- `next`
- `player`
- `resolve_url`
* Allow a ClientConfig to be passed to YoutubeAPI endpoint handlers.
* Add constants for many new clients
* Fix documentation of YoutubeAPI.browse(): Comments and search
result aren't returned by the browse() endpoint but by the next()
and search() endpoints, respectively.
* Accept gzip compressed data, to help save on bandwidth
* Add debug/trace logging
* Other minor fixes
Fixes:
* Sanitize user-provided content in HTML (Fixes#2193)
* Fix encoding of search query in prev/next pages (Fixes#2229)
* Fix some issues introduced with #2196:
- Fix alignment of all <h3> elements (Move the inline style from the parent to the <h3> element)
- Add missing comma on 'dir' HTML attribute (Typo introduced by PR #2196)
Code cleaning:
* Remove unnecessary 'each_sclice' + 'each' double loop in ECR files
* Clean the player's <source> list generation code (in player.ecr)
Related to #1416, it doesn't really fix the real error, but instead mutes the exception message.
Like explained in #1416, this "exception Error" while flushing the client data doesn't harm the client-server connection. However, this exception message continuously spams the logs and makes debugging and error finding really difficult.
Cherry picked from ui overhaul branch with a few modifications:
- channel folder is renamed to channels
- parsing for channel home and featured channels are removed due to
lack of infrastructure from other commits
(cherry picked from commit 44d18b8e147b47ad06a54cc6fd08423d9f39074d)
i was injecting custom css into the site that made the avatars round, and noticed comment avatars looked a little odd
i opened dev tools and siffed through the html, and noticed that the image was being padded,
when it would look nicer if the element used margin instead of padding
with padding:
https://imgur.com/c0pB37e
with proposed changes (margin instead of padding):
https://imgur.com/iKmBzEi
The behavior was as follow: on Right-To-Left text (e.g Arabic) that is wrapped
(because it's too long to fit on one line), the second row and following rows
may or may not be right aligned (as RTL text should be). Opening the devtools
fixes that alignement, as consistently as closing the devtool breaks it.
This problem seems to arrive only in the following configurations (link nested
in a paragraph, both of which may or may not have the dir= attribute):
* `<p><a href="some_link">RTL_TEXT</a></p>`
* `<p><a href="some_link" dir="auto">RTL_TEXT</a></p>`
* `<p dir="auto"><a href="some_link">RTL_TEXT</a></p>`
with the following CSS:
```
p {
unicode-bidi: plaintext;
text-align: start;
}
```
Changing the HTML to the following configuration (a paragraph with the dir=
attribute, nested in a link) seems to fix it:
`<a href="some_link"><p dir="auto">RTL_TEXT</p></a>`
This will prevent, on large pages, the LTR and RTL text to be
far away, on each side of the page. This could happen on channel
and playlists descriptions, when the page is displayed on a large
screen.
