Native html5 player in chrome 33/Windows 8.1

[michelt]

possible duplicate: #1052

[mmcc]

This one might be related to #1081 as well (the other is Firefox).

@michelt do you have a Windows 8 instance you can use to try and reproduce these? I can grab one off modern.ie if not.

[michelt]

Actually no, I'm on MacOS X and Windows 7. This is a bug report from product users. It appears all users that reported it have Chrome 33 and Windows 8.1 (seems to work with Windows 7 and Window 8.0)

[michelt]

I can't reproduce it with browserstack

[mmcc]

We can't reproduce in a VM either. Do you know if it was in Metro mode or classic? Were they seeing the problem on videojs.com?

[xoxoxo]

same here. windows 8.1 + chrome. windows classic mode. Same thing happens with my own implementation and videojs.com (or any other site with video.js).

ill post more details later today/tomorrow.

[xoxoxo]

its seems like its detected as mobile device

/* Hide on mobile devices. Remove when we stop using native controls
by default on mobile */
.vjs-default-skin.vjs-using-native-controls .vjs-big-play-button {
display: none;
}

windows 8.1
chrome 33.0.1750.154m
its ultrabook (asus N550LF)

[xoxoxo]

vjs.IS_CHROMEMOBILE = (/Android/i).test(vjs.USER_AGENT);

if (vjs.TOUCH_ENABLED && player.options()['nativeControlsForTouch'] !== false && vjs.IS_CHROMEMOBILE == true ) {

fixed it (kinda ;))

[heff]

I got a Win 8.1 Chrome 33 VM, and I'm not seeing the issue, but it's not on a touch device.

This makes sense if the user is on a device that supports touch events. Right now if we detect touch at all we use the native controls, because the mobile controls are in beta. Two things need to happen basically:

• We need to handle situations where mouse and touch events are possible, and adjust the UI based on which events are fired.
• We need to get mobile controls solid so we can just use them on mobile devices and not have this issue.

[lhwparis]

i can reproduce this issue too on windows8 touch device :( any solution?

[timomayer]

this is an anoying bug because windows 8 is an often used operating system and touch screens are the new defacto standard for windows 9 notebooks. please fix the detection you use and dont detect chrome/firefox and IE10 on windows8 touch systems as mobile browsers.

[heff]

One current work around for this is to set the 'nativeControlsForTouch' option to false.

videojs(my_id, { nativeControlsForTouch: false });

(or same in the data-setup options)

On one hand this isn't a simple change because it requires us to change how we detect touch support from something that's done when the library loads, to something that happens whenever touch or mouse events are fired.

On the other hand we hope to get the custom controls on native soon. We just need some more Android testing/work to be done.

[lhwparis]

sorry thats a bad fix :/ i cant give all my customers with a full windows 8 desktop PC no native controls only because he has a touchscreen :/
cant you do a more device or os specific detection like: when its windows and touch use custom controls? i know device and os detection is bad and feature detection prefered but thats a very special situation

[heff]

@lhwparis Setting that option to false will turn on the normal video.js controls on touch devices.

It's not just feature/device detection, it's that users of those devices can switch between using a mouse and finger at any point, and we have to be able to dynamically adapt when that switch happens.

[mbusch]

It's reproducible here with the following setup as well: Windows 8.1, Chrome 36, Notebook with Touchscreen.

[mmcc]

Yep, any Windows device with a touchscreen should trigger this. @heff's solution is probably the best bet until we can decide on a more specific solution.

[darkfrog26]

You cannot say this is a browser bug when Windows classifies itself as a touch device regardless of whether or not you have a touchscreen (I do not have a touchscreen and I'm seeing this). Rather, I think that VideoJS should be a bit smarter into how it determines when to show the custom controls.

[gkatsev]

If windows identifies itself as a touch device regardless then it's a browser bug.
Whether videojs should be able to detect a desktop device better is a separate issue.
We probably should be a bit smarter in identifying desktop/mobile devices or just turn on our custom controls everywhere (except iphones) by default.

[darkfrog26]

gkatsev, I agree with your last statement...I just assumed that would be what you would do anyway. It seems that making a list of exclusion cases makes more sense than an inclusion case.

[mmcc]

I'm with @gkatsev, incorrectly reporting features is the definition of a browser bug. I personally lean towards just turning on custom controls everywhere (sans iOS) by default. Is there anything specific we're waiting on at this point before doing so?

[darkfrog26]

I guess my response would be that it's irrelevant even if it is a browser bug. All of your competing video players don't have any issues with this, so they obviously handle the situation more gracefully. Sorry, not trying to be argumentative, it just seems strange that this issue would be closed without a proper resolution.

As for the resolution of custom controls everywhere I think that's a great resolution to this issue.

[gkatsev]

@mmcc we should turn them on for ipads. I know that the custom controls with the videojs skin haven't been tested much on mobile devices. It could be that the only thing that should happen is to add a css rule that changes the font-size for controls on mobile devices.

[mmcc]

@darkfrog This issue isn't closed...I simply closed your issue because it was a duplicate of this one. We're all on the same page that this isn't resolved yet.

@gkatsev Ah yes, particularly since it turned out that the emoji-controls thing turned out to be a non-issue. Seems like we could probably handle the mobile device font size using media queries and ship it.

[gkatsev]

@darkfrog26 it's always good to identify where an issue comes from, whether it was created by videojs or the browser or a third party. Videojs must consider the source of issues because there are some things (mainly browser bugs) that videojs can do nothing about. This is one of the browser bugs that can (and should) be addressed by videojs.

[darkfrog26]

Oh, sorry about that. I saw the reference to "closed" above and thought it meant this ticket.

[darkfrog26]

What is the status of this bug?

[H1D]

@heff I think best solution to detect if native controls needed or not should be based on physical size of the screen. Basically native controls needed only for small devices.

Real physical screen size can be calculated based on DPI and resolution. I know detecting real DPI might be a trick but it is possible http://www.infobyip.com/detectmonitordpi.php

[H1D]

@heff any ideas? What is the easiest workaround?

[mmcc]

@H1D Native controls are on by default now (as of 4.10), so this should be a non-issue now. Mind giving it a test before I close this?

Edit: Nope, just checked. nativeControlsForTouch is disabled everywhere, so this shouldn't be happening...it's weird that IE is causing unique problems </sacrasm>

[H1D]

@mmcc Well... I think we misunderstand each other.

The case:

1. a user have Win8 touch enabled 15" laptop
2. a website use video.js + some plugins (resolutions switcher + playback rate controls + subtitles switcher)
3. user navigates to site and sees native browser controls for video (no resolutions switcher, playback rates etc.) because video.js detected user's device as touch-enabled

and this is a problem IMHO

[gkatsev]

@H1D latest versions of videojs no longer (or shouldn't any longer) display native controls on touch detection, so, you should be seeing the custom controls.
What version of videojs are you using currently?

[mmcc]

@H1D No, we understand each other. It doesn't matter that Video.js is detecting the device as touch enabled, since custom controls are now enabled by default for everything, regardless of touch.

[mmcc]

@gkatsev I confirmed, the 4.11.1 does not show custom controls on a Surface.

[gkatsev]

Very weird.

[mmcc]

@gkatsev false alarm, looks like that was just a weird race condition due to being on a painfully slow network. Switched networks, reloaded, everything looks fine. Looks like this is fixed.

@H1D what version of Video.js are you using? Again, as of 4.10.0 this should no longer be an issue.

[H1D]

Now I'm totally confused =))

Native controls are on by default

I thought "native" it is those which rendered by OS, not videojs library. So phrase "Native controls are on by default" means that native controls rendered always =)

what version of Video.js are you using?

I'm testing 4.11.1. Problem is that I want native controls for iPad for example, but since you simply force custom (video.js) controls...

I believe that simply turning off native controls everywhere just because of a single strange use-case (touch enabled laptops) is bad very decision. Mobile device are very critical in terms of user input, so it's always better to let OS handle proper UI.

[gkatsev]

I think @mmcc misspoke above. Native controls are disabled everywhere.

As for letting the native os handle the control bar: that isn't really a great option in a lot of cases because we often want to show extra things on the control bar that we won't be able to show otherwise in the UI. The custom controls have been tested a lot also, so, most issues should have been ironed out by now.

[mmcc]

Yep, that was a typo, I meant the inverse.

[H1D]

@gkatsev

we often want to show extra things on the control bar that we won't be able to show otherwise in the UI

it makes sense.

But here is the most obvious problem: buttons in control bar are soooo tiny on 7". It is impossible to use them without stylus

[mmcc]

@H1D regarding size, we realize this is an issue. The plan is to try and identify touch devices and increase the font size for those devices. AFAIK nothing's been implemented yet (so contribution's welcome!), but that's the goal.

[H1D]

@mmcc OK. "Holywar" is over =)

[mmcc]

@H1D I'd love to get the mobile stuff out there sooner rather than later, since I totally see the pain point there. Mobile's hard...if only everyone would go back to using the web on their CRT desktop monitor, our lives would be so much easier :)

[H1D]

@mmcc yeah =) only 1024*768, only IE6