Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

"player control" component behaves differently between TalkBack (Accessibility) on and off #8627

Closed
ryxryx opened this issue Feb 24, 2021 · 4 comments
Closed

"player control" component behaves differently between TalkBack (Accessibility) on and off #8627

ryxryx opened this issue Feb 24, 2021 · 4 comments
Assignees
@ojw28
Labels
bug

Comments

@ryxryx
Copy link

ryxryx commented Feb 24, 2021

Steps to reproduce

  • Enable "TalkBack" on your Android device
  • Run exoplayer demo app
  • Go to play any video
  • Tap on player area -> TalkBack says "show player controls"
  • Activate it (by double tap or however you set up accessibility on your device) -> Player controls are shown
  • While player controls are still shown, activate again -> video is paused
  • While player controls are still shown, activate again -> video is played

This is different behaviour compared with when Talkback is off:

  • While video is play, tap player area -> Player controls are shown
  • While player controls are still shown, tap player area -> Player controls are hidden

This is causing confusion to our users who use TalkBack. When player controls are shown and TalkBack focus is still on the player, and then users activate, what should happen is player controls get hidden. The key thing here is that TalkBack focus is still on the player, so the action should not apply onto the play/pause button. User with accessibility might not see why this is happening.

  • ExoPlayer version number: using demo app
  • Android version: Android 10
  • Android device: Samsung Tab A
  • Also tested on older version 2.11.3 on Android 7 on Nexus 9
@Samrobbo Samrobbo self-assigned this Mar 1, 2021
@Samrobbo
Copy link
Contributor

Samrobbo commented Jul 19, 2021 •
edited
Loading

This issue slipped through the cracks, sorry about that.

I can confirm this exact issue is happening on my device.

@ojw28 is this something you can look into? I'm conscious there seems to be a few other Talkback related issues, such as it repeatedly 'saying' the current progress time? Is that expected behaviour?

It could be worth a full dive into the UI talkback situation?

@Samrobbo Samrobbo assigned ojw28 and unassigned Samrobbo Jul 19, 2021
@ojw28
Copy link
Contributor

ojw28 commented Jul 19, 2021

I did take a look at this a while back, and was able to reproduce the issue. I wasn't able to figure out the root cause though. It felt like it was more likely to be a problem with talkback itself than a problem with ExoPlayer's UI components. It seems quite likely there exists a way we could work around whatever the underlying problem is. We'll need to carve out some more time to try and figure out how to do that.

@ojw28 ojw28 mentioned this issue Mar 7, 2022
Closed
@ojw28
Copy link
Contributor

ojw28 commented Mar 7, 2022

This seems to be related to StyledPlayerView overriding onTouchEvent. It may be possible to fix it whilst fixing #9605 and #9861.

icbaker pushed a commit to androidx/media that referenced this issue Mar 9, 2022
@ojw28 @icbaker
Fix PlayerView touch handling
aa22bc2 
Overriding onTouchEvent was causing multiple issues, and
appears to be unnecessary. Removing the override fixes:

1. StyledPlayerView accessibility issue where "hide player
   controls" actually toggled play/pause.
2. Delivery of events to a registered OnClickListener when
   useController is false.
3. Delivery of events to a registered OnLongClickListener
   in all configurations.
4. Incorrectly treating a sequence of touch events that
   exit the bounds of the view before ACTION_UP as a click,
   both for delivery to OnClickListener and for toggling
   the controls.

Note: After this change, control visibility will not be
toggled if the application developer explicitly sets the
view to be non-clickable. I think that's probably working
as intended though. It seems correct that a non-clickable
view would not respond to clicks.

Issue: google/ExoPlayer#8627
Issue: google/ExoPlayer#9605
Issue: google/ExoPlayer#9861
PiperOrigin-RevId: 433016626
icbaker pushed a commit that referenced this issue Mar 9, 2022
@ojw28 @icbaker
Fix PlayerView touch handling
2028215 
Overriding onTouchEvent was causing multiple issues, and
appears to be unnecessary. Removing the override fixes:

1. StyledPlayerView accessibility issue where "hide player
   controls" actually toggled play/pause.
2. Delivery of events to a registered OnClickListener when
   useController is false.
3. Delivery of events to a registered OnLongClickListener
   in all configurations.
4. Incorrectly treating a sequence of touch events that
   exit the bounds of the view before ACTION_UP as a click,
   both for delivery to OnClickListener and for toggling
   the controls.

Note: After this change, control visibility will not be
toggled if the application developer explicitly sets the
view to be non-clickable. I think that's probably working
as intended though. It seems correct that a non-clickable
view would not respond to clicks.

Issue: #8627
Issue: #9605
Issue: #9861
PiperOrigin-RevId: 433016626
@ojw28
Copy link
Contributor

ojw28 commented Mar 15, 2022

Fixed in dev-v2. The fix will be included in 2.18.

@ojw28 ojw28 closed this as completed Mar 15, 2022
@google google locked and limited conversation to collaborators May 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@ojw28 ojw28

Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ojw28 @Samrobbo @ryxryx