Bug 1444489 will update the UI of the video/audio controls to make it easier to use on touch devices. The touch layout will only be enabled on Android. It probably makes sense to enable it on touch-only Windows devices too.
It would probably also make sense to switch to the touch layout when the touch density is selected in the toolbar customisation menu or the `browser.touchmode.auto` pref is enabled and Windows is in tablet mode.
The way that we have done this before, and what seems to work best, is to base the UI off of what the last event source was. So if the user has tapped on the screen (using touch), then show touch UI but otherwise if they click then we would show mouse UI. We shouldn't base this off of just if a mouse is plugged in. Touch screen laptops are prevalent and almost always have a trackpad connected.
Priority: -- → P3
This should use the event.mozInputSource API to change the UI based on the input source (mouse vs touch).
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #2) > The way that we have done this before, and what seems to work best, is to > base the UI off of what the last event source was. So if the user has tapped > on the screen (using touch), then show touch UI but otherwise if they click > then we would show mouse UI. The required changes will be a bit bigger in this case; we currently install event listeners and init the TouchUtils when the binding is constructed; this asks all the touch bits to be initialized but skipped until isTouchControls is switched to true dynamically. Also, we might not want the controls to change size while it's visible.
You need to log in before you can comment on or make changes to this bug.