fix(youtube/hide-video-action-buttons): fix 'hide share button'

[LisoUseInAIKyrios]

Consolidated "hide share button" setting into the existing "hide action buttons" (change required to fix broken layout issues)

Consolidated "hide like" and "hide dislike" into a single setting. Since most users have segmented like/dislikes and both must be hidden together.

This PR appears to fix ReVanced/revanced-patches#1863

integration changes

[oSumAtrIX]

Any indication on why share is not hidable? They are all children of a component tree.

[LisoUseInAIKyrios]

I just looked again, and the share button appears to be part of the 'create clip and thanks' component, as hiding that also hides the share button.

I'll update the strings and comments now.

[0xrxL]

Probably, an alternative way to accomplish this goal, is to search between protobuf (or other type of web) request and change the actionbuttons visibility.

Cheers!

[oSumAtrIX]

The ConversionContext object can yield more information to that. Also i am not sure what you mean share is part of the other buttons, they should be seperate components. The paths might be identical. Is that correct?

[LisoUseInAIKyrios]

The existing HIDE_ACTION_BUTTONS blocks "ContainerType|video_action_button" (which matches "video_action_button.eml")

Enabling this also hides the share button.

It appears that YouTube has moved the share button into this component.

[oSumAtrIX]

So how I remember it was that the log spits out multiple of the same path so it's not differentiable. A hack I used was to count the amount of how often I see the action button path. Since the share button comes right after the dislike/like button, we can identify it among the other action buttons. So to allow hiding the share menu, simply check if it is the first occurrence of action button. If it is and the option to hide it is on, then hide it. If the option to hide the rest of the action buttons is on, simply hide them as well, otherwise show them.

[0xrxL]

So how I remember it was that the log spits out multiple of the same path so it's not differentiable. A hack I used was to count the amount of how often I see the action button path. Since the share button comes right after the dislike/like button, we can identify it among the other action buttons. So to allow hiding the share menu, simply check if it is the first occurrence of action button. If it is and the option to hide it is on, then hide it. If the option to hide the rest of the action buttons is on, simply hide them as well, otherwise show them.

Your solution only had one inconvenience: it hid Share Button instead Live Chat action button (on normal videos), because there wasn't (and still isn't) a way to determine if a video contains the Live Chat action button or not.

[LisoUseInAIKyrios]

The logic is there (before this PR):

        if (dislikeRule.check(path).isBlocked()) ActionButton.doNotBlockCounter = 4;
        if (currentIsActionButton && ActionButton.doNotBlockCounter-- > 0) {
            if (SettingsEnum.HIDE_SHARE_BUTTON.getBoolean()) {
                LogHelper.printDebug(() -> "Hiding share button");
                return true;
            } else return false;
        }

But I think that logic is causing the broken button layout when 'hide create, clip, thanks' is enabled. Because I removed the counting logic and it now blocks using only the path, and I'm no longer seeing the broken layout.

[oSumAtrIX]

I believe that can be fixed. You can check for the first occurrence of action button. First occurrence will be share button. The remaining occurrences are the rest of the action buttons. It should be possible to hide share and other buttons separately that way.

[oSumAtrIX]

So how I remember it was that the log spits out multiple of the same path so it's not differentiable. A hack I used was to count the amount of how often I see the action button path. Since the share button comes right after the dislike/like button, we can identify it among the other action buttons. So to allow hiding the share menu, simply check if it is the first occurrence of action button. If it is and the option to hide it is on, then hide it. If the option to hide the rest of the action buttons is on, simply hide them as well, otherwise show them.

Your solution only had one inconvenience: it hid Share Button instead Live Chat action button (on normal videos), because there wasn't (and still isn't) a way to determine if a video contains the Live Chat action button or not.

@0xrxL yes. There is no proper way currently to determine it. The only way would be to dig in the conversioncontext object (and possibly children) to check, if the action button is a share button for example

[LisoUseInAIKyrios]

When the screen is scrolled up/down, the filter events run again. So with the current code (not this PR), different buttons can become hidden each time they appear on screen.

[oSumAtrIX]

Does the order of the buttons change?

[0xrxL]

So how I remember it was that the log spits out multiple of the same path so it's not differentiable. A hack I used was to count the amount of how often I see the action button path. Since the share button comes right after the dislike/like button, we can identify it among the other action buttons. So to allow hiding the share menu, simply check if it is the first occurrence of action button. If it is and the option to hide it is on, then hide it. If the option to hide the rest of the action buttons is on, simply hide them as well, otherwise show them.

Your solution only had one inconvenience: it hid Share Button instead Live Chat action button (on normal videos), because there wasn't (and still isn't) a way to determine if a video contains the Live Chat action button or not.

@0xrxL yes. There is no proper way currently to determine it. The only way would be to dig in the conversioncontext object (and possibly children) to check, if the action button is a share button for example

The problem is (from the first time I suggest this mod): the new Layout.

All the aforementioned three/four buttons have all the same infos, so you can't identify them individually.

[LisoUseInAIKyrios]

Does the order of the buttons change?

Different buttons appear/disappear. It's happens the most when the action buttons are scrolled to the right (so the like/dislike are not visible) and then scroll the action buttons bar up/down the screen so they become hidden and then reappear. Sometimes the share button disappears, and sometimes the previously hidden action buttons reappear (remix, thanks, etc).

[oSumAtrIX]

In that case the only solution is the one you provided for the time being. The protobuf message buffer could be read with an efficient algorithm and caching techniques to avoid having to dig in the conversioncontext objects children. Though likely that is the correct/mot efficient way since it avoids duplicating the entire buffer on each hook.

[oSumAtrIX]

If we figure out how to traverse componentcontext children recursively we can very quickly figure out every components structure. Question is if at the time we figure it out, it can still be hidden, the place we hook is a recursive call already thar builds the component and its children recursively by streaming the buffer. So at the time we know about the conversion context children, it is already too late to return an EmptyComponent to end the recursion and hide the component. An external hook outside of the recursion would be required. That way on calling of that hook, a second hook in the recursion can figure out the components children and structure and callback to the first hook, so that the first hook returns an EmptyComponent and effectively hides the original component.

[oSumAtrIX]

The componentcontext object overrides ToString and therefor its fields and members should be trivial to reverse.

[oSumAtrIX]

Reversing the necessary methods to for example read a childrens text components text is what would be the difficult part.

[oSumAtrIX]

It's happens the most when the action buttons are scrolled to the right

I was not able to trigger the bug by scrolling to the left or right, have you tried blocking the first occurrence of the action button path builder and checking if it hides the share button?

[LisoUseInAIKyrios]

You have to scroll to the right, and then scroll down/up so the entire bar goes off screen. When the bar reappears, different buttons are visible (and sometimes the share button is hidden when it should not be). You have to do this multiple times, but it will happen after just a few attempts.

The broken button backgrounds (empty circles) seems to happen more often when the screen is turned off/on.

[LisoUseInAIKyrios]

I tried selectively allowing the first action button encountered (and hiding the other action buttons), and it sometimes works (share button is visible, and other action buttons are hidden). Except the broken empty button circles is still present (and seems slightly worse), and sometimes the share button still gets hidden when scrolling the bar off/on screen.

I think the only solution to selectively allow the share button, is something like the more comprehensive path check you described.

[oSumAtrIX]

What is the explanation for the buttons to be partially being hidden? Have you tried only hiding the share button instead of only showing it? When you block an action button, the recursion stops and children stop rendering, then the next action button is rendered. It is odd that the action button is partially visible. It might be possible, that the children are rerendered without the button itself, so it would at first block at a child and therefore hide the buttons content only, but you were able to hide all buttons properly, so something along these lines there should be an explanation.

[LisoUseInAIKyrios]

I tried hiding just the share button (the first action button loaded), and it does not show broken empty buttons, but the end result is one of the action buttons is randomly hidden (especially when scrolling off/on screen).

It appears the buttons are loaded non-deterministically (ie: randomly):

The broken background buttons only happen when trying to hide based on counting the order of action buttons loading. I don't know for sure, but I think it's because litho is using more than 1 thread to load. So the child components of one button are being loaded concurrently while another button parent is also loading on a different thread. This can also cause the buttons to be loaded out of order, depending on how runtime is split up among the different threads. If litho is using more than 1 thread, then filtering based on the order of loading will never work 100% (which might be why the button backgrounds are only sometimes broken, since it's a race condition between the multiple threads loading different buttons and button components).

[oSumAtrIX]

Concurrency can't be a problem. The buffer is read sequentially for each component context. And the component context object is built recursively. While it might build components in multiple threads, each component itself is built sequentially/recursively, so it doesn't explain why the buttons are partially hidden.

[LisoUseInAIKyrios]

The current code counts the number of action button components that are loaded. If the share button is not hidden (and the remaining action buttons are hidden), then ButtonsPatch allows only the first 4 loads of an action button component.

But if two action buttons are loaded concurrently (ie: the share and remix button), and each button loads it's child components on it's own thread, then the loading of elements between the two buttons will happen independently of each other. So if counting out 4 elements, you may get 2 elements loaded from the share button, but then 2 elements from the remix button are loaded (and allowed to load). The remaining elements from the share button and remix are then blocked (since only 4 action button elements are allowed to load). The end result, is two partially loaded and incomplete buttons that are missing text/icons.

An alternative outcome, is the remix button wins the thread race and loads all it's sub components before the share button loads anything, in which case the remix button is then incorrectly shown (since it was the first 4 action button elements loaded), and the share button is incorrectly hidden since it's the 5th+ element to load.

I'm fairly sure this is what's going on with the current code, and why the broken background buttons only show up when trying to filter based on the order of loads.

[oSumAtrIX]

Makes sense, in that case the PR is a solution for now as is.