The latest iOS and macOS releases have an updated look for media controls, and we need to implement it.
<rdar://problem/32571531>
Created attachment 312028 [details] Patch
Comment on attachment 312028 [details] Patch rs=me
Comment on attachment 312028 [details] Patch Attachment 312028 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/3877856 New failing tests: media/track/track-cue-overlap-snap-to-lines-not-set.html
Created attachment 312034 [details] Archive of layout-test-results from ews126 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews126 Port: ios-simulator-wk2 Platform: Mac OS X 10.12.5
Committed r217823: <http://trac.webkit.org/changeset/217823>
I have custom controls in my application which allow drag/drop of videos to stimulate program change, size change, etc. The resolution of this bug captures and cancels all dragenter events in the media-controls-container which overlays the entire video, thereby breaking my custom controls. Since this happens in a closed shadowDOM with no styling access via a pseudo class or reference to the event handler, I see no workaround that will allow me to drag and drop videos in my application. Is there another approach that would preserve the application's ability to drag the video element?
(In reply to Scott Steele from comment #7) > I have custom controls in my application which allow drag/drop of videos to > stimulate program change, size change, etc. The resolution of this bug > captures and cancels all dragenter events in the media-controls-container > which overlays the entire video, thereby breaking my custom controls. Since > this happens in a closed shadowDOM with no styling access via a pseudo class > or reference to the event handler, I see no workaround that will allow me to > drag and drop videos in my application. Is there another approach that > would preserve the application's ability to drag the video element? Thanks for the feedback Scott. Could you raise a separate bug about this? We need to track that as an individual issue and fix it so that we only prevent drag when the `controls` attribute is present on the media element.