rotemdan / youtubecinemamode Goto Github PK

This is a long-standing chrome-only bug and is not caused directly by the script. It seems to happen when going in and out of full screen, especially with screen sizes with more "square" ratios such as 5:4. This seems to be triggered because the script adds a overflow-y: scroll to the stylesheet (to prevent noticable rescaling on load when the page becomes long enough and the scrollbar appears). Doesn't seem to happen with the the new (transparent) HTML5 player based on my testing, so enabling it might be a possible workaround.

The default YouTube behavior doesn't put focus on any element when a watch page is loaded. Since the top bar is hidden by default (so it is not even considered as an option for focus), it might be useful to focus the player to have keyboard control of the video available immediately on page load.

It shows only a blank screen.

The small "play" icons added when a tab contains a playing video don't seem to work 100% correctly on Firefox with this script.

Playlist element positioning does not correctly adjust to the larger video player and is partially overlapped by it.

It seems YouTube's layout assumes a predefined size for the player so the playlist does not adjust to the larger player. Fixing this consistently seems quite difficult (much more than it may seem at first), especially getting it right when the window is resized (may require adjusting the layout from Javascript which I don't consider very desirable - I prefer using CSS as much as possible).

There is currently no way to switch the video player to the "default" size. Having this ability would be especially useful for live broadcasts, where there's a live "chat" area alongside the video.

Adding this in a non-buggy way would require some work (currently the script injects a permanent, non-reversible stylesheet to resize the player).

The current approach to restore playlist positioning in video pages doesn't correctly handle cases where the browser is resized to less than the maximum width. Height-only adjustments seem to work correctly.

I'm testing an alternative version where instead of showing the top bar when the mouse is hovered over the top area, the top bar is displayed whenever the page is vertically scrolled to a position different than the topmost one (i.e. scrollHeight > 0 ).

Advantages:

• The top bar will never display unintentionally when moving the mouse while watching the video (when switching tabs, etc.).
• The top bar will never disappear unintentionally or when using popup element such as autocomplete or other sub-menus that are opened (unless the user scrolls the page to the top while a popup element is open).
• The top bar is accessible when viewing the comment area.

Disadvantages:

• The top bar will not appear when the page is scrolled to the top. The page must be scrolled a little bit in order to use it.
• The top bar will take some page space when viewing the comments (this has become the default behavior in YouTube anyway though).

I'll be using this myself for a while to see how usable/convenient this is in practice and if there might be some adjustments that may improve it. You can test it now by installing this Gist (the main script should be disabled first).

An alternative version that will always display the top bar whenever the video is paused (regardless of the scroll position) can be tested here (I considered this for a while as a possible improvement but found it less usable personally. It also had some "flicker" problems when seeking the video [which creates very quick pause and play events], though that could be solved by adding a delay - but that might introduce some other problems if not done very carefully),.

A weird layout behavior of YouTube (that has nothing to do with the script) is that the video player is not correctly scaled if the browser window's width is more than 50% of the screen width. When 100% or <50% it does seem to work correctly.

Edit: This seems only to happen only when the browser zoom is different than the default (i.e. not 100%). It seems that YouTube developers haven't considered non-standard zoom configurations for the scaling, so it is possible they might fix it in the future.