Bug 186258 - Simplify and remove some unused video element code (helpful for ARC-compatibility)
Summary: Simplify and remove some unused video element code (helpful for ARC-compatibi...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Darin Adler
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-06-03 22:01 PDT by Darin Adler
Modified: 2018-06-05 12:45 PDT (History)
3 users (show)

See Also:


Attachments
Patch (63.52 KB, patch)
2018-06-03 22:27 PDT, Darin Adler
dbates: review+
Details | Formatted Diff | Diff
Patch (70.32 KB, patch)
2018-06-04 22:01 PDT, Darin Adler
ews-watchlist: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ews205 for win-future (12.73 MB, application/zip)
2018-06-05 00:05 PDT, EWS Watchlist
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Adler 2018-06-03 22:01:47 PDT
Simplify and remove some unused video element code (helpful for ARC-compatibility)
Comment 1 Darin Adler 2018-06-03 22:27:59 PDT
Created attachment 341893 [details]
Patch
Comment 2 Daniel Bates 2018-06-04 00:27:35 PDT
Comment on attachment 341893 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=341893&action=review

> Source/WebCore/platform/graphics/MediaPlayer.h:211
> +    virtual Vector<RefPtr<PlatformTextTrack>> outOfBandTrackSources() { return Vector<RefPtr<PlatformTextTrack>>(); }

return { };

> Source/WebCore/platform/graphics/MediaPlayer.h:588
> +    bool m_visible { false };

Can we swap the order of this line and the one below to achieve better structure packing?

> Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.h:76
> +    unsigned totalVideoFrames() { return m_totalVideoFrames; }

Make this member function const?

> Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.h:77
> +    unsigned droppedVideoFrames() { return m_droppedVideoFrames; }

Ditto.

> Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.h:78
> +    unsigned corruptedVideoFrames() { return m_corruptedVideoFrames; }

Ditto.

> Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.h:79
>      MediaTime totalFrameDelay() { return m_totalFrameDelay; }

Ditto even though it is not part of the patch.

> Source/WebKitLegacy/mac/WebView/WebVideoFullscreenController.mm:115
> +// called once each time we enter full screen. So it should have a differena name.

differena => different

> Source/WebKitLegacy/mac/WebView/WebVideoFullscreenController.mm:-126
> -        if (_videoElement->platformMedia().type == PlatformMedia::AVFoundationMediaPlayerType) {

Should we assert this?
Comment 3 Darin Adler 2018-06-04 21:34:26 PDT
Comment on attachment 341893 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=341893&action=review

>> Source/WebKitLegacy/mac/WebView/WebVideoFullscreenController.mm:-126
>> -        if (_videoElement->platformMedia().type == PlatformMedia::AVFoundationMediaPlayerType) {
> 
> Should we assert this?

There is no such thing as platformMedia().type any more, so we couldn’t assert *this*, exactly. We can’t assert what type of media player we have without adding functions to the MediaPlayerPrivate class since there are currently no type checking functions. Any MediaPlayerPrivate classes other than MediaPlayerPrivateAVFoundationObjC will return nil from the avPlayer function (renamed to objCAVFoundationAVPlayer in the updated version of my patch to be precise and avoid a name conflict).

The old code would silently do nothing if the video element had a different/wrong type and the new  code will still do that. It seems a bit like asking for trouble for me to do that when doing this refactoring. On the other hand, I have no idea why it’s OK to just fail to make the "full screening" work due to an unexpected media player type, so it does seem that someone could return and tighten this up a bit. I am also unsure about race conditions when the video element is set before the window is loaded and then the window is loaded later. The code goes out of its way to do nothing if isWindowLoaded is NO, but seems to implicitly assume that it cannot be loaded later. I am unsure this cases is tested. None of this should be affected by my refactoring.
Comment 4 Darin Adler 2018-06-04 22:01:49 PDT
Created attachment 341953 [details]
Patch
Comment 5 EWS Watchlist 2018-06-05 00:05:30 PDT
Comment on attachment 341953 [details]
Patch

Attachment 341953 [details] did not pass win-ews (win):
Output: http://webkit-queues.webkit.org/results/7996193

New failing tests:
http/tests/security/contentSecurityPolicy/userAgentShadowDOM/allow-audio.html
Comment 6 EWS Watchlist 2018-06-05 00:05:41 PDT
Created attachment 341957 [details]
Archive of layout-test-results from ews205 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews205  Port: win-future  Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit
Comment 7 Darin Adler 2018-06-05 09:14:43 PDT
Committed r232510: <https://trac.webkit.org/changeset/232510>
Comment 8 Radar WebKit Bug Importer 2018-06-05 09:16:38 PDT
<rdar://problem/40810185>
Comment 9 Darin Adler 2018-06-05 12:45:05 PDT
Looking at naming conventions in the code, maybe instead of objCAVFoundationAVPlayer I should have named this function something like playerAVFObjC?