We shouldn't blindly assume that the Mach Send Right we receive from the UIProcess in WebPage::setTopContentInsetFenced (and VideoFullscreenManager::setVideoLayerFrameFenced) will have the expected MACH_MSG_TYPE_MOVE_SEND disposition. Instead, we should check that it meets expectations. If we discover a discrepancy, we should discard the message without touching the mach port contents.
<rdar://problem/37814171>
Created attachment 341800 [details] Patch
Comment on attachment 341800 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=341800&action=review r=me > Source/WebKit/WebProcess/WebPage/WebPage.cpp:2664 > + // Check for invalid message receipt. If this is not a send right, something has > + // gone wrong and we should discard this message. I don't think this comment adds anything. It just kind of restates the code below. > Source/WebKit/WebProcess/cocoa/VideoFullscreenManager.mm:568 > + // Check for invalid message receipt. If this is not a send right, something has > + // gone wrong and we should discard this message. Ditto.
Comment on attachment 341800 [details] Patch Attachment 341800 [details] did not pass win-ews (win): Output: http://webkit-queues.webkit.org/results/7941653 New failing tests: http/tests/security/canvas-remote-read-remote-video-localhost.html
Created attachment 341837 [details] Archive of layout-test-results from ews206 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews206 Port: win-future Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit
Created attachment 341867 [details] Patch for landing
Comment on attachment 341867 [details] Patch for landing Clearing flags on attachment: 341867 Committed r232451: <https://trac.webkit.org/changeset/232451>
All reviewed patches have been landed. Closing bug.