Closed Bug 1546954 Opened 5 years ago Closed 5 years ago

Picture-in-Picture player window can't be used with keyboard-only

Categories

(Toolkit :: Video/Audio Controls, defect, P2)

68 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla70
Tracking Status
firefox68 --- disabled
firefox69 --- wontfix
firefox70 --- verified
firefox71 --- verified

People

(Reporter: george.craciun, Assigned: mconley)

References

Details

(Keywords: access)

Attachments

(3 files, 1 obsolete file)

Steps to reproduce:

  1. Launch Nightly
  2. Go to Youtube https://youtube.com
  3. Select any video to play
  4. Use only the keyboard to enable the Picture-in-Picture window using the context menu or the toggle.

Expected Result:
The PiP should be accessible with keyboard only.

Actual Result:
The PiP can't be enabled using keyboard only.

Note:
If the PiP window is launched, the controls available in the PiP window can't be used with keyboard only.

Priority: -- → P2
Assignee: nobody → djustice

To clarify, the controls work fine when the focus is on the origin page, however when the pip window is focused we have no keyboard shortcuts.

We've made a design decision to keep most of the controls in the origin page. The only controls we carry over are "close", "un-pip", and "play/pause".

It's clear we should add "play/pause" control with the <space> bar. What do we feel about connecting <ctrl-w> to "close"? I'm unsure what "un-pip" should line up with

Flags: needinfo?(mconley)

(In reply to Dave Justice [:JSON_voorhees / :meandave] from comment #1)

It's clear we should add "play/pause" control with the <space> bar. What do we feel about connecting <ctrl-w> to "close"? I'm unsure what "un-pip" should line up with

That's a good question. I imagine we'd probably want to use patterns that are familiar, based on other media players... but I think we'd probably best confer with an expert.

Hey yzen, I mentioned PiP to you a few months back, and I think we talked about keyboard accessibility. What do you think is the right keyboard access method for the player window? Should there be keyboard shortcuts for the various commands, or should it be tabbing and hitting space for each of the commands, or a mixture, or something else entirely?

Flags: needinfo?(mconley) → needinfo?(yzenevich)

(In reply to Mike Conley (:mconley) (:⚙️) from comment #3)

(In reply to Dave Justice [:JSON_voorhees / :meandave] from comment #1)

It's clear we should add "play/pause" control with the <space> bar. What do we feel about connecting <ctrl-w> to "close"? I'm unsure what "un-pip" should line up with

That's a good question. I imagine we'd probably want to use patterns that are familiar, based on other media players... but I think we'd probably best confer with an expert.

Hey yzen, I mentioned PiP to you a few months back, and I think we talked about keyboard accessibility. What do you think is the right keyboard access method for the player window? Should there be keyboard shortcuts for the various commands, or should it be tabbing and hitting space for each of the commands, or a mixture, or something else entirely?

Hi, thanks for reaching out. Generally keyboard shortcuts and linear keyboard navigation (using tabs/space/enter) are not mutually exclusive. Primarily because the former are not discoverable. I would ensure that you can tab to and activate all interactive controls (as a must) and if there are existing patterns for keyboard shortcuts in other media player it would be a great if those were available too. Also, I'm sure that that's the case already, those interactive elements should have proper text labelling (text alternatives) and semantics.

Thanks

Flags: needinfo?(yzenevich)

Hey JSON_Voorhees, I started looking at this patch today, but I've noticed that nothing was added here for tabbing (see comment 4, specifically:

I would ensure that you can tab to and activate all interactive controls (as a must) and if there are existing patterns for keyboard shortcuts in other media player it would be a great if those were available too.
)

was there another patch here that didn't get committed?

Flags: needinfo?(djustice)

The normal window tabbing shortcuts work to access PIP in windows, with <alt> + <tab>. Let me know if this is insufficient and we need to find another way to access the PIP window

Flags: needinfo?(djustice) → needinfo?(mconley)

I'm confused... yes, I can certainly bring the player window into selection via Alt+Tab, but I can't choose any of the controls via Tab. In fact, if my mouse isn't over the player window, none of the controls are visible.

What I'd expect is that when the player window is focused, that hitting "Tab" would highlight the first control (probably play / pause), and would make the rest of the controls visible as well. Then I could Tab to the next one (unpip), and then Tab to close. Does that make sense?

Flags: needinfo?(mconley) → needinfo?(djustice)

You are correct, there was not tabbing added, I only tested that tabbing to, and <space> for play/pause worked. There will need to be additional work to get the tabbing working as described above. I agree that is the desired behavior, just misunderstood the ask. I'll start digging in to see what all needs to change for this. Sorry for the confusion!

Flags: needinfo?(djustice)

Any updates here, JSON_Voorhees?

Flags: needinfo?(djustice)

Stealing, per conversation with JSON_Voorhees.

Assignee: djustice → mconley
Flags: needinfo?(djustice)
Attachment #9077716 - Attachment description: Bug 1546954 - Clean up Picture-in-Picture keyboard support. r?JSON_Voorhees → Bug 1546954 - Clean up Picture-in-Picture keyboard support for the player window. r?JSON_Voorhees

Re-scoping this bug to mainly be about the player window. I'm going to create a new bug for accessing Picture-in-Picture via the keyboard.

Summary: Picture-in-Picture can't be accessed and used with keyboard-only → Picture-in-Picture player window can't be used with keyboard-only
Attachment #9071113 - Attachment is obsolete: true
Pushed by mconley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/081577b6ef92
Refactor player.js to break up large anonymous functions into smaller pieces. r=JSON_voorhees
https://hg.mozilla.org/integration/autoland/rev/826c969ee4d4
Switch to standard buttons in the Picture-in-Picture player window, and merge play and pause buttons. r=JSON_voorhees
https://hg.mozilla.org/integration/autoland/rev/e5793e33a5ca
Clean up Picture-in-Picture keyboard support for the player window. r=JSON_voorhees

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

I don't think this needs to get uplifted to 69, unless we decide that we desperately want to ship Picture-in-Picture to release in 69, which is not currently the case.

I filed bug 1566183 for making the toggle more keyboard accessible.

Build ID 20190902191027
User Agent Mozilla/5.0 (Windows NT 10.0; rv:70.0) Gecko/20100101 Firefox/70.0

Verified as fixed on the latest Beta build (v70b3) and on the latest Nightly build.

Status: RESOLVED → VERIFIED

If this bug really fixed?

For me, at least, using space to play/pause video in PiP sometimes only works if I at least once manually clicked on play/pause button in this window first. Just making sure that the PiP window is active by clicking on it in just random place does not help.

(In reply to User Dderss from comment #21)

For me, at least, using space to play/pause video in PiP sometimes only works if I at least once manually clicked on play/pause button in this window first. Just making sure that the PiP window is active by clicking on it in just random place does not help.

I wonder if that's another symptom of bug 1620899?

See Also: → 1620899

Judging by PiP window's structure the focus might sometimes be stuck with pane element (50033), where videos are played, which is IsKeyboardFocusable but does not have, obviously, any default invoke actions attached. By the logic of the software, the keyboard listener should be either attached right to the pane or the focus should reliably automatically move to "play/pause" button which both receives clicks and space bar presses but sometimes it does not happen.

The pane I mentioned has AutomationID assigned as "browser" which does not make much sense for this scenario if the pane does not have its own keyboard listener and meant to transfer key presses to "play/pause" button. Maybe AutomationID value should be cleared and IsKeyboardFocusable set to false so the keyboard input would "fall back" to "play/pause" button easier. But this is just my guessings so it might not be related to the issue at all.

Is there a compelling reason for the button tabindex attributes to be so out of order? It's not very intuitive, and at least for me it feels janky, in that my first assumption was that it was a bug. It's simultaneously inconsistent with both LTR and RTL conventions. The autofocus is fine but why override normal focus behavior for this player when we don't do that for other UAWidgets or the regular video player?

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: