guancio/ChromeOsSubtitle

Control bars disappear

Closed this issue · 9 comments

Steps to reproduce:

  1. Open a random video file (eg. by using "Files" app and open with subtitle videoplayer;
    or alternatively open the app, hit Ctrl-O and navigate with the file open dialog)
  2. Press +
  3. Wait ~1 second.

Expected results:

  • Video would jump forward 10 seconds.

Perceived results:

  • Video jumps forward 10 seconds
  • Control bar fades away
  • Mouse becomes invisible in the area of the video window.

Bonus observation:
However, you can bring the control bars for a second by eg hitting alt-rightarrow again
(they stay around for only a second though, so you have to be quick).

Speculation on the causes:
There's probably something funny with the mouse handling routine / fullscreen behavior
where you would expect the control bars to disappear, but them coming back with mouse tracking
is not working the way one would expect.

I am not able to reproduce this bug on macOS/ChromeOS/Xubuntu. Neither can
@guancio. The only thing that bugs me is that I introduced a minor change
to hide the mouse cursor alone with the controls bar so that people can
enjoy the video without the cursor getting in the way. Maybe this is
working well on some Chrome version and messing things up in others
versions. I don't know, I can only speculate. I will keep looking.

Could you also specify your version of Chrome and also your OS. Also, is
this bug only with Alt seeking or with all kinds of seeking (Shift and
clicking on the progress bar).

On Mac (El Capitan), my Chrome Version is 54.0.2840.71 (64-bit)

On Tue, Nov 15, 2016 at 3:54 AM, ttimonen notifications@github.com wrote:

Steps to reproduce:

  1. Open a random video file (eg. by using "Files" app and open with
    subtitle videoplayer;
    or alternatively open the app, hit Ctrl-O and navigate with the file
    open dialog)
  2. Press +
  3. Wait ~1 second.

Expected results:

  • Video would jump forward 10 seconds.

Perceived results:

  • Video jumps forward 10 seconds
  • Control bar fades away
  • Mouse becomes invisible in the area of the video window.

Bonus observation:
However, you can bring the control bars for a second by eg hitting
alt-rightarrow again
(they stay around for only a second though, so you have to be quick).

Speculation on the causes:
There's probably something funny with the mouse handling routine /
fullscreen behavior
where you would expect the control bars to disappear, but them coming back
with mouse tracking
is not working the way one would expect.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#85, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AHkl-pYnFSdpq09i-1NJy4HQSMhOf5uIks5q-N-tgaJpZM4Kx4uU
.

This is a Pixel2 device running ChromeOS.
Dump from the about page in the end.

For other ways to trigger this issue:

  • ctrl and arrow keys triggers this issue
  • seeking by clicking the bar with a mouse triggers this issue.
  • Clicking stop (and play again) triggers this issue
  • Clicking pause, play or changing to fullscreen or other controls like volume level setting does not trigger this issue.

---------- copypaste ---------
Version 53.0.2785.154 (64-bit)
Platform 8530.96.0 (Official Build) stable-channel samus
ARC Version 3322987
Firmware Google_Samus.6300.174.0

Channel
Currently on stable channel.

WebKit
537.36 (@0)

V8
5.3.332.47

User Agent
Mozilla/5.0 (X11; CrOS x86_64 8530.96.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.154 Safari/537.36

Command Line
/opt/google/chrome/chrome --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so --ppapi-flash-version=23.0.0.162-r1 --ppapi-flash-args=enable_hw_video_decode=1 --ui-prioritize-in-gpu-process --use-gl=egl --enable-native-gpu-memory-buffers --gpu-sandbox-failures-fatal=yes --enable-arc --enable-logging --log-level=1 --use-cras --enable-wayland-server --user-data-dir=/home/chronos --max-unused-resource-memory-usage-percentage=5 --login-profile=user --enable-natural-scroll-default --has-chromeos-keyboard --default-wallpaper-large=/usr/share/chromeos-assets/wallpaper/default_large.jpg --default-wallpaper-small=/usr/share/chromeos-assets/wallpaper/default_small.jpg --child-wallpaper-large=/usr/share/chromeos-assets/wallpaper/child_large.jpg --child-wallpaper-small=/usr/share/chromeos-assets/wallpaper/child_small.jpg --guest-wallpaper-large=/usr/share/chromeos-assets/wallpaper/guest_large.jpg --guest-wallpaper-small=/usr/share/chromeos-assets/wallpaper/guest_small.jpg --enable-prefixed-encrypted-media --enterprise-enrollment-initial-modulus=15 --enterprise-enrollment-modulus-limit=19 --vmodule=screen_locker=2,webui_screen_locker=2,lock_state_controller=2,webui_login_view=2,power_button_observer=2,ui/display/chromeos=1,ash/display=1,ui/ozone=1,zygote=1,plugin=2,chromeos/login/=1,arc/=1 --login-manager

Build Date
Tuesday, October 4, 2016

Could you do this test?

In src/js/mep-player.js
@120 and @131

comment out those two lines and test the app now as a unpacked extension
(Chrome developer mode).

On Wed, Nov 16, 2016 at 8:27 AM, ttimonen notifications@github.com wrote:

This is a Pixel2 device running ChromeOS.
Dump from the about page in the end.

For other ways to trigger this issue:

  • ctrl and arrow keys triggers this issue
  • seeking by clicking the bar with a mouse triggers this issue.
  • Clicking stop (and play again) triggers this issue
  • Clicking pause, play or changing to fullscreen or other controls
    like volume level setting does not trigger this issue.

---------- copypaste ---------
Version 53.0.2785.154 (64-bit)
Platform 8530.96.0 (Official Build) stable-channel samus
ARC Version 3322987
Firmware Google_Samus.6300.174.0

Channel
Currently on stable channel.

WebKit
537.36 (@0 https://github.com/0)

V8
5.3.332.47

User Agent
Mozilla/5.0 (X11; CrOS x86_64 8530.96.0) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/53.0.2785.154 Safari/537.36

Command Line
/opt/google/chrome/chrome --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so
--ppapi-flash-version=23.0.0.162-r1 --ppapi-flash-args=enable_hw_video_decode=1
--ui-prioritize-in-gpu-process --use-gl=egl --enable-native-gpu-memory-buffers
--gpu-sandbox-failures-fatal=yes --enable-arc --enable-logging
--log-level=1 --use-cras --enable-wayland-server
--user-data-dir=/home/chronos --max-unused-resource-memory-usage-percentage=5
--login-profile=user --enable-natural-scroll-default
--has-chromeos-keyboard --default-wallpaper-large=/
usr/share/chromeos-assets/wallpaper/default_large.jpg
--default-wallpaper-small=/usr/share/chromeos-assets/wallpaper/default_small.jpg
--child-wallpaper-large=/usr/share/chromeos-assets/wallpaper/child_large.jpg
--child-wallpaper-small=/usr/share/chromeos-assets/wallpaper/child_small.jpg
--guest-wallpaper-large=/usr/share/chromeos-assets/wallpaper/guest_large.jpg
--guest-wallpaper-small=/usr/share/chromeos-assets/wallpaper/guest_small.jpg
--enable-prefixed-encrypted-media --enterprise-enrollment-initial-modulus=15
--enterprise-enrollment-modulus-limit=19 --vmodule=screen_locker=2,
webui_screen_locker=2,lock_state_controller=2,webui_
login_view=2,power_button_observer=2,ui/display/chromeos=1,ash/display
=1,ui/ozone=1,zygote=1,plugin=2,chromeos/login/=1,arc/=1
--login-manager

Build Date
Tuesday, October 4, 2016


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#85 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHkl-vcJ3ah-x7q-SSQ0-ZceNmjFm4Iyks5q-nEggaJpZM4Kx4uU
.

Sorry for the delay; my day-job + travel kept me busy for the last 10 days.

Commented out the $(document.body).css({ 'cursor': 'pointer' }); and the corresponding 'none' lines,
and the behavior changed, but only a bit.
What happens now is that cursor doesn't disappear anymore. The controls do disappear as before though, and they come back only with keystrokes. It is as if the mouse event handler wouldn't get any events or something.

Ok, found the issue, at some level. Problem is with the touch screen handling.
Namely, the line 70 in src/js/mep-player.js has the condition to check for 'ontouchstart' in window,
which seems to be true for my device.

Making the first condition to be always false makes things working mostly fine.

Filed a pull request #86 that has a one-liner fix to address the issue.

Okay, merged both of your pulls. Can you test the app now and ensure that the controls bar doesn't fly away? Also, if time permits, can you do a general test as well? Close the issue if everything is cool and I will release the new app.

Seems to work fine with these patches.