Unable to access the url that you have provided.
could you please provide the other url to reproduce the issue.

Thanks.

Are you able to access the following URL?https://support.jwplayer.com/customer/portal/articles/1430261-aes-content-protection

This issue can be reproduced with any version of jwplayer using flash.

I am able to access both jwplayer.com and the pbs url in your post. And I am able to play video without any problem on Chrome 56.0.2902.0.
Can you upgrade to dev build and try again? 

 I do see it working properly in the dev build. Do you happen to know if their was some fix made that will be pushed to the beta build before production? I'm just curious if we should expect Chrome 55 to ship with or without the issue. 

I see that if I enable the Chrome flag "Prefer HTML over Flash" it starts playing on latest Chrome M55(55.0.2883.28). I assume that might be the case why it's playing in Dev(56.0.2902.0).

ericde@ can you please confirm that the feature is by default enabled on Dev.

Prefer HTML over Flash isn't enabled on the Beta channel, but I'm seeing the issue w/ Click to Play enabled.

Would it be possible to do a reserve bisect to see where it starts working on trunk?

I take back that very last line.  Turning off Site Engagement (i.e. forcing Flash to run), I'm still able to replicate the issue on Chrome 56.

A bisect would be useful here, assuming that there was a regression between 54 and 55.

Based on watching Prudhvi's tests, perhaps we are looking at two different issues, which may present the same way (or ultimately trigger the same problem).

In 55, after a component update, the issue seems to be present (i.e. clicking play does nothing), however after a restart the issue goes away.

In 56, the issue appears persistently.

Re: A bisect, it would likely be good to know what CL triggered it to happen persistently.

Unable to access the url in our region.Hence adding TE-NeedsTriageFromMTV label.

Thanks.

I've looked further into what's changed between Chrome 54 and Chrome 55 in jwplayer. It looks like PointerEvent is now defined and our feature detection attempts to use pointer events to handle clicks instead of mouse or touch events when present and these do not behave as expected over a swf object element.

On a 'pointerdown 'event we add a 'pointerup' handler on the object element's parent which received the down event. This 'pointerup' event fires in Edge. It does not in Chrome 55.

We do the same with mouse down and up events in Chrome successfully.

+input folk who I think is the right component for c#11.

Hey Rick,

Could you help us find an owner for this?

Removing 

Sounds like some Pointer Events behavior difference between Chrome and Edge is causing substantial breakage here.  Mustaq/Navid, can one of you please take a look?  Tentatively marking as a 55 blocker in case it's a broad issue or simple enough to get a fix merged to 55 still but it might be tough given the tight timeframe.

danny@ can you describe the impact if we can't get this fixed in time for the upcoming Chrome 55 stable release?  I.e. any idea how many sites are impacted?  Could you work around the issue, or are lots of sites embedding their own copy of the library?

**** Bulk edit -  please ignore if not applicable ****


A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Also due to Thanksgiving holidays in US, please make sure fix is ready and merged to M55 latest by 5:00 PM PT Friday, 11/18/16 (sooner the better).

@rbyers A lot of sites are embedding their own copy of the library. As far as the amount of sites it will impact may be difficult to provide as many JW customers are migrating away from flash, but popular sites such as PBS and Fox will be impacted.  

We took a look at our data logs for flash playback and its over 5000 domains with ~200M plays a day

danny@, laforge@
I tested this page
https://support.jwplayer.com/customer/portal/articles/1430261-aes-content-protection
with Canary 56.0.2919.0 with PointerEvents enabled (default) or disabled (from chrome://flags) and the two video in the page show the same behavior. The first one with one click starts playing and the second one with one click after a few seconds with this error in the console which I assume is unrelated to PE:

URL Blocked: This redirect failed because the redirect URI is not whitelisted in the app’s Client OAuth Settings. Make sure Client and Web OAuth Login are on and add all your app domains as Valid OAuth Redirect URIs.

When I test the same page with stable 54 both of the videos play just fine. I tested both on Win and Mac and the results are the same.

Anyhow, can you explain more a little what the expected behavior is in that page and what you do and what you see with and without PointerEvents enabled?

Was the video you watched using flash? One easy way to verify with jwplayer is when your right click on the player the menu that displays will display the Flash Version being used. The player will only show the Flash version in the menu when using flash.

Here is a repro that shows that a pointerup is not visible to a pdf <object>, unlike mouseup: http://output.jsbin.com/dufarop

For records: there is an old mouse event bug (Issue 61574) that suggests that mouse events on <object> are redundant---seems opposite to this one!

Here is a new repro for this bug (with flash object):
  http://output.jsbin.com/luzasa

(The repro in #22 is for a pdf object where the browsers are not consistent.)

I've found a work-around for using Pointer events. Adding 'pointer-events: all' to the element we want to receive "pointerup" events fixes the problem where we do not receive this event with 'pointer-events: auto'. Unfortunately that only takes care of sites that upgrade to the latest jwplayer. A large number of sites will still be impacted.

the css property pointer-events doesn't really have any relationship to PointerEvents as the DOM events.

I believe mustaq@ is working on a fix. We'd prefer that you wait before you roll out any patch to see if we can fix this interoperability issue in Chrome first.

I should mention that the above work-around works for elements on top of a swf, but not on the object element itself.

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Also due to Thanksgiving holidays in US, please make sure fix is ready and merged to M55 latest by 5:00 PM PT Friday, 11/18/16 (sooner the better).

A fix is out for review: https://codereview.chromium.org/2510763002/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b649bb81f5ea6d908cfb3db1506219678e654d33

commit b649bb81f5ea6d908cfb3db1506219678e654d33
Author: mustaq <mustaq@chromium.org>
Date: Thu Nov 17 16:21:28 2016

Fired PointerEvent from Node::dispatchMouseEvent() to fix a bug.

This is an urgent fix to make pointerups visible in M55 for sites
with flash objects. The ideal solution would be to remove all
direct event dispatches for plugins and PointerLocks, instead
route all PlaformMouseEvents through EventHandler.

BUG= 659670 

Review-Url: https://codereview.chromium.org/2510763002
Cr-Commit-Position: refs/heads/master@{#432889}

[add] https://crrev.com/b649bb81f5ea6d908cfb3db1506219678e654d33/third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-on-object.html
[modify] https://crrev.com/b649bb81f5ea6d908cfb3db1506219678e654d33/third_party/WebKit/Source/core/dom/Node.cpp
[modify] https://crrev.com/b649bb81f5ea6d908cfb3db1506219678e654d33/third_party/WebKit/Source/core/dom/Node.h

Verified this issue on Windows-7,8.1 & 10 using chrome latest Dev M56-56.0.2924.0 winpgo and win64 pgo builds by following steps mentioned below.

1. Switched to chrome://flags and disabled "prefer HTML over Flash"
2. Navigated to https://support.jwplayer.com/customer/portal/articles/1430261-aes-content-protection
3. Clicked on play video
4. Observed video plays with no issues

Note: Installed previous canary #56.0.2922.0 and observed the issue is still seen but not on #56.0.2924.0. Hence adding TE-Verified label.

Deleted: 659670.mp4 5.8 MB

	659670.mp4 5.8 MB View Download

Your change meets the bar and is auto-approved for M55 (branch: 2883)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e4c3bdcd1c1e247de81333f02242d7d2601deaf7

commit e4c3bdcd1c1e247de81333f02242d7d2601deaf7
Author: Mustaq Ahmed <mustaq@google.com>
Date: Fri Nov 18 16:27:33 2016

Fired PointerEvent from Node::dispatchMouseEvent() to fix a bug.

This is an urgent fix to make pointerups visible in M55 for sites
with flash objects. The ideal solution would be to remove all
direct event dispatches for plugins and PointerLocks, instead
route all PlaformMouseEvents through EventHandler.

BUG= 659670 

Review-Url: https://codereview.chromium.org/2510763002
Cr-Commit-Position: refs/heads/master@{#432889}
(cherry picked from commit b649bb81f5ea6d908cfb3db1506219678e654d33)

Review URL: https://codereview.chromium.org/2517603002 .

Cr-Commit-Position: refs/branch-heads/2883@{#609}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[add] https://crrev.com/e4c3bdcd1c1e247de81333f02242d7d2601deaf7/third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-on-object.html
[modify] https://crrev.com/e4c3bdcd1c1e247de81333f02242d7d2601deaf7/third_party/WebKit/Source/core/dom/Node.cpp
[modify] https://crrev.com/e4c3bdcd1c1e247de81333f02242d7d2601deaf7/third_party/WebKit/Source/core/dom/Node.h

Rechecked this issue on Windows-7,8.1 & 10 using chrome M55-Beta 55.0.2883.59 winpgo and win64 pgo builds. Followed the below steps:

1. Switched to chrome://flags and disabled "prefer HTML over Flash"
2. Navigated to https://support.jwplayer.com/customer/portal/articles/1430261-aes-content-protection
3. Clicked on play video
4. Observed video plays with no issues

Merge is working as intended, adding TE-Verified label.

Thanks.!