Mute / Unmute button next to volume slider control is broken

[loicraux]

Have you read the FAQ and checked for duplicate open issues?
Yes

If the problem is related to FairPlay, have you read the tutorial?
N/A

What version of Shaka Player are you using?
Latest version v4.15.4

Can you reproduce the issue with our latest release version?
Yes

Can you reproduce the issue with the latest code from main?
Yes

Are you using the demo app or your own custom app?
Both

If custom app, can you reproduce the issue using our demo app?
Yes

What browser and OS are you using?
N/A

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
N/A

What are the manifest and license server URIs?
N/A

What configuration are you using? What is the output of player.getNonDefaultConfiguration()?
Default configuration

What did you do?
Hover the mute/unmute button

What did you expect to happen?
Volume slider control smoothly appears

What actually happened?
There is some sort of flickering. Also more problems listed below.

List of problems when the 'mute' & 'volume' controls are next to each other

• Flickering when hovering the mute/unmute button in some situations, as you can see on this screen capture :
  

• If 'mute' & 'volume' controls are next to each other on the right side of the controls (after a spacer), when hovering the mute button to click on it and mute the video, the button is moved on the left and is not under the mouse anymore. This is very annoying. See this screen capture :
  

We might think this is fixable by simply inverting the 'mute' & 'volume' controls in the right side controls so that the volume slider control 'volume' comes first in the list, followed by the mute/unmute toggle button 'mute'. But this does not work, since this functionality of the volume slider appearing when the mute button is hovered is implemented using a CSS adjacent sibling combinator + : basically .mute + .volume. See below.

• Keyboard Accessibility of the volume slider control is broken. See other ticket [a11y] Volume slider control is not accessible by keyboard since v4.15 UI overhaul #8798

Suggestions for a fix
Today the volume slider control appearing when the mute/unmute toggle button is hovered works only if the 'volume' control follows the 'mute' control since it is implemented with CSS, using the adjacent sibling combinator +. I think it would be nice to introduce a new control named 'sound' for example, that would combine these 2 controls, so that people would still be able to have ['mute', 'volume'] in their UI configuration, without the volume slider appearing/disappearing automatically when the mute/unmute toggle button is hovered. Any other solution is welcome, too.

Note : as a workaround meanwhile, I had to create such a dummy control and use it between the and the controls, so that the CSS rule .mute + .volume does not apply :

import * as shaka from 'shaka-player-ui';

export const dummyControlName = 'dummy_control';

class DummyControl extends shaka.ui.Element {
    public constructor(parent: HTMLElement, controls: shaka.ui.Controls) {
        super(parent, controls);
        const dummyElement = document.createElement('span');
        dummyElement.style.display = 'none';
        this.parent?.appendChild(dummyElement);
    }
}

class DummyControlFactory {
    public create(rootElement: HTMLElement, controls: shaka.ui.Controls): shaka.extern.IUIElement {
        return new DummyControl(rootElement, controls);
    }
}

shaka.ui.Controls.registerElement(dummyControlName, new DummyControlFactory());

And use it like this :

controlPanelElements = [
                'play_pause',
                'rewind',
                'fast_forward',
                'time_and_duration',
                'spacer',
                'mute',
                dummyControlName,
                'volume',
                'captions',
                'fullscreen',
                'playback_rate'
            ]

Thanks to this workaround, I can have the volume slider next to the mute/unmute toggle button, and independant from each other, and all accessible :

Are you planning to send a PR to fix it?
Most probably not.

[loicraux]

AFAIC, most of the problems listed in this issue are solved by PR #8807 , so I am fine with this ticket being closed.

[avelad]

Thanks @loicraux !