⚠ Archived content — this site is no longer maintained.   Current WebKit documentation is at docs.webkit.org.

Timeline



Feb 14, 2021:

6:08 PM Changeset in webkit [272842] by Peng Liu
  • 46 edits in trunk

[GPUP] Move UseGPUProcessForMediaEnabled from WebPreferencesInternal to WebPreferencesExperimental
​https://bugs.webkit.org/show_bug.cgi?id=221310

Reviewed by Eric Carlson.

Source/WTF:

Move UseGPUProcessForMediaEnabled from WebPreferencesInternal to WebPreferencesExperimental,
so that the WebKitTestRunner will turn it on by default.

  • Scripts/Preferences/WebPreferencesExperimental.yaml:
  • Scripts/Preferences/WebPreferencesInternal.yaml:

Tools:

  • TestWebKitAPI/Tests/WebKitCocoa/GPUProcess.mm:

(TEST):
Use WKPreferencesSetBoolValueForKeyForTesting() to set the preference for testing.
It works no matter the preference is internal or experimental.

LayoutTests:

Update expectations of the tests which are affected by the "Media In GPUProcess" feature
(WebKitTestRunner will enable the feature by default). Also set "UseGPUProcessForMediaEnabled=false"
for some webrtc tests.

  • platform/ios-wk2/TestExpectations:
  • platform/mac-wk2/TestExpectations:
  • platform/mac/TestExpectations:
  • platform/mac/webrtc/captureCanvas-webrtc-software-encoder.html:
  • platform/wk2/TestExpectations:
  • webrtc/captureCanvas-webrtc-software-h264-baseline.html:
  • webrtc/captureCanvas-webrtc-software-h264-high.html:
  • webrtc/captureCanvas-webrtc.html:
  • webrtc/concurrentVideoPlayback2.html:
  • webrtc/direction-change.html:
  • webrtc/disable-encryption.html:
  • webrtc/h264-baseline.html:
  • webrtc/h264-high.html:
  • webrtc/multi-audio.html:
  • webrtc/multi-video.html:
  • webrtc/peer-connection-track-end.html:
  • webrtc/peerconnection-page-cache-long.html:
  • webrtc/peerconnection-page-cache.html:
  • webrtc/remove-track.html:
  • webrtc/utf8-sdp.html:
  • webrtc/video-addTrack.html:
  • webrtc/video-addTransceiver.html:
  • webrtc/video-autoplay.html:
  • webrtc/video-disabled-black.html:
  • webrtc/video-h264.html:
  • webrtc/video-interruption.html:
  • webrtc/video-mediastreamtrack-stats.html:
  • webrtc/video-mute.html:
  • webrtc/video-remote-mute.html:
  • webrtc/video-replace-muted-track.html:
  • webrtc/video-replace-track-to-null.html:
  • webrtc/video-replace-track.html:
  • webrtc/video-rotation-no-cvo.html:
  • webrtc/video-rotation.html:
  • webrtc/video-setDirection.html:
  • webrtc/video-sframe.html:
  • webrtc/video-stats.html:
  • webrtc/video-unmute.html:
  • webrtc/video-with-data-channel.html:
  • webrtc/video.html:
12:51 PM Changeset in webkit [272841] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WebCore

[iOS] MobileSafari crashes at WebCore: WebCore::VideoFullscreenInterfaceAVKit::doEnterFullscreen
​https://bugs.webkit.org/show_bug.cgi?id=221863
<rdar://73861140>

Patch by Jean-Yves Avenard <Jean-Yves Avenard> on 2021-02-14
Reviewed by Darin Adler.

On iPad, it's possible for AVKit to fail due to racing requests to exit full screen and enter full screen. The enterFullscreenHandler would attempt to immediately re-enter full screen.
For now we bail-out early to avoid the crash. In a follow-up patch we will ensure that the condition to enter fullscreen while there's a pending operation to exit fullscreen can't occur.
No new tests, can't reproduce. Analysis has been entirely theoretical.

  • platform/ios/VideoFullscreenInterfaceAVKit.mm:

(VideoFullscreenInterfaceAVKit::enterFullscreenHandler):
Exit early if error returned.

11:06 AM Changeset in webkit [272840] by commit-queue@webkit.org
  • 2 edits in trunk/JSTests

JSC stress test stress/copy-data-properties-fast-path.js.default fails on s390x and ppc64le
​https://bugs.webkit.org/show_bug.cgi?id=221557
<rdar://problem/74311603>

Unreviewed, unskip this test since it seems Yusuke has already fixed it.

Patch by Michael Catanzaro <Michael Catanzaro> on 2021-02-14

  • stress/copy-data-properties-fast-path.js:
9:18 AM Changeset in webkit [272839] by Darin Adler
  • 3 edits
    2 adds in trunk

Crash calling replaceTrack on a sender that outlives its RTCPeerConnection
​https://bugs.webkit.org/show_bug.cgi?id=221870

Reviewed by Youenn Fablet.

Source/WebCore:

Test: fast/mediastream/RTCRtpSender-outlives-RTCPeerConnection.html

  • Modules/mediastream/RTCRtpSender.cpp:

(WebCore::RTCRtpSender::replaceTrack): Added a null check for m_connection.
It's already using WeakPtr, so null check is all we need.

LayoutTests:

  • fast/mediastream/RTCRtpSender-outlives-RTCPeerConnection-expected.txt: Added.
  • fast/mediastream/RTCRtpSender-outlives-RTCPeerConnection.html: Added.

Feb 13, 2021:

7:04 PM Changeset in webkit [272838] by Alexey Shvayka
  • 5 edits
    1 add in trunk

Proxy's GetOwnProperty should complete trap result descriptor before validation
​https://bugs.webkit.org/show_bug.cgi?id=221772

Reviewed by Yusuke Suzuki.

JSTests:

  • stress/proxy-get-own-property.js:
  • stress/proxy-returning-incomplete-property-descriptor-error.js: Added.

Source/JavaScriptCore:

This patch implements CompletePropertyDescriptor abstract op and utilizes it in
Proxy's GetOwnProperty, right before IsCompatiblePropertyDescriptor check
as per spec [1].

This change tightens trap result validation rules for properties that are
non-configurable on ProxyTarget, aligning JSC with V8 and SpiderMonkey.

It's impossible to prefill trap result descriptor: toPropertyDescriptor() throws
on malformed descriptors, thus it expects the argument to be an empty descriptor
(added an assert).

Property descriptors returned to userland are unaffected as they were implicitly
completed when filling PropertySlot (see PropertyDescriptor::defaultAttributes).

[1]: ​https://tc39.es/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-getownproperty-p (step 14)

  • runtime/ObjectConstructor.cpp:

(JSC::toPropertyDescriptor):

  • runtime/ProxyObject.cpp:

(JSC::completePropertyDescriptor):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):

4:05 PM Changeset in webkit [272837] by weinig@apple.com
  • 5 edits in trunk/Source/WebCore

Reduce requirements for color types to only conversion to their reference color
​https://bugs.webkit.org/show_bug.cgi?id=221868

Reviewed by Darin Adler.

We currently require every new color type to define a conversion to/from xyz and then perhaps
some more conversions to reference colors to avoid unnecessary trips through XYZ. For example,
if every conversion from HSL to sRGB went through XYZ it would be very silly and inefficient,
and the fact that we require the boiler plate for HSL -> XYZ, even though it's always going to
convert to SRGB first seems unfortunate. We can do better.

At first I thought we could model color conversion as DAG, with XYZ at the root, and each color
type declaring a "reference color" that would get them closer to XYZ. So, HSL would have a
"reference color" of sRGB, sRGB would have a "reference color" of linearSRGB, and linearSRGB
would have a "reference color" XYZ. Then, as long as there was a defined conversion to/from the
"reference color", we could do a least common ancestor graph search between the two color types
being converted between to find the optimal set of conversions needed.

That almost works, but the relationships between the four color types that make up each RGB type
(bounded-gamma-encoded, bounded-linear-encoded, extended-gamma-encoded, extended-linear-encoded)
make it not quite ideal, since a conversion from something like sRGB to ExtendedSRGB would wind
up going through XYZ (since the "reference color" for sRGB is LinearSRGB and the "reference color"
for ExtendedSRGB is LinearExtendedSRGB, and both either "reference colors" are XYZ).

Ultimately, the depth of the type graph is not all that large (though the ASCII art I made is
quite big, though I did remove A98RGB and Rec2020 as they are same as DisplayP3 here):

┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┼ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐

Matrix Conversions ┌───────────┐│┌───────────┐

│ │ XYZ (D50) │││ XYZ (D65) │ │

└─────▲─────┘│└─────▲─────┘

│ │ │ │ │

┌─────────────────────────┬───────────┘ │ └───────────┬───────────────────────────────┐
│ │ │ │ │ │ │
│ │ │ │ │
│ │ │ │ │ │ │
│ ProPhotoRGB───────────────────┐ │ SRGB──────────────────────────┐ DisplayP3─────────────────────┐
│ │ │┌────────┐ ┌────────────────┐│ │ │┌────────┐ ┌────────────────┐│ │┌────────┐ ┌────────────────┐│ │
│ ││ Linear │ │ LinearExtended ││ │ ││ Linear │ │ LinearExtended ││ ││ Linear │ │ LinearExtended ││
│ │ │└────────┘ └────────────────┘│ │ │└────────┘ └────────────────┘│ │└────────┘ └────────────────┘│ │
│ ─│─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│─ ─│─ ─│─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│─│─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│─

┌───────────┐ │┌────────┐ ┌────────────────┐│ │ │┌────────┐ ┌────────────────┐│ │┌────────┐ ┌────────────────┐│
│ Lab │ ││ Gamma │ │ GammaExtended ││ │ ││ Gamma │ │ GammaExtended ││ ││ Gamma │ │ GammaExtended ││
└─────▲─────┘ │└────────┘ └────────────────┘│ │ │└────▲───┘ └────────────────┘│ │└────────┘ └────────────────┘│

│ └─────────────────────────────┘ │ └─────┼───────────────────────┘ └─────────────────────────────┘
│ │ ┌──┴──────────┬─────────────┐
│ │ │ │ │

┌───────────┐ │┌───────────┐ ┌───────────┐┌─────────────┐
│ LCH │ ││ HSL │ │ HWB ││SRGB<uint8_t>│
└───────────┘ │└───────────┘ └───────────┘└─────────────┘

From this, it turns out you can handle all the cases in about 5 steps, with most peeling off a
conversion from the front or back or the path and using recursion to continue on. It ultimately
leaves a final step where only matrix conversions remain, which can potentially be further
optimized in another patch to concatenate the matrices at compile time.

  1. Handle the special case SRGBA<uint8_t> for Input and Output, and recursively call conversion.
  1. Handle all color types that are not IsRGBType<T> or IsXYZA<T> for Input and Output. For all these other color types, we can uncondtionally convert them to their "reference" color, as either they have already been handled by a ColorConversion specialization or this will get us closer to the final conversion, and recursively call conversion.
  1. Handle conversions within a RGBFamily (e.g. all have the same descriptor). This will conclude the conversion.
  1. Handle any gamma conversions for the Input and Output, recursively call conversion
  1. At this point, Input and Output are each either Linear-RGB types (of different familes) or XYZA and therefore all additional conversion can happen via matrix transformation. This will conclude the conversion.

With these steps, we group the color types into 3 distinct groups.

  1. RGB types.

These inherit from the RGBType struct and are defined in terms of their xyzToLinear / linearToXYZ
matrices, their transfer function, whether they are bounded or extended and their white point. New
RGB color types can be added without any new conversion code being required, as long as they specify
those properties.

  1. The XYZ type.

This is the root type, and only varies on its white point. If other white points beside D50 and D65
are ever needed, we will need to extend the ChromaticAdapation specializations to also have conversion
matrices between those.

  1. All other types.

All other types (e.g. Lab, LCHA, HSLA, HWBA (and SRGBA<uint8_t>, kind of, it's a special flower) are
the set currently) have their conversions defined in terms of single reference color and require
explicit specialization of the ColorConversion struct to work.

  • platform/graphics/ColorConversion.cpp:

(WebCore::Lab<float>>::convert):
(WebCore::WhitePoint::D50>>::convert):
(): Deleted.
(WebCore::WhitePoint::D65>>::convert): Deleted.
(WebCore::toLinear): Deleted.
(WebCore::toGammaEncoded): Deleted.
(WebCore::A98RGB<float>>::convert): Deleted.
(WebCore::LinearA98RGB<float>>::convert): Deleted.
(WebCore::DisplayP3<float>>::convert): Deleted.
(WebCore::LinearDisplayP3<float>>::convert): Deleted.
(WebCore::ExtendedSRGBA<float>>::convert): Deleted.
(WebCore::LinearExtendedSRGBA<float>>::convert): Deleted.
(WebCore::ProPhotoRGB<float>>::convert): Deleted.
(WebCore::LinearProPhotoRGB<float>>::convert): Deleted.
(WebCore::Rec2020<float>>::convert): Deleted.
(WebCore::LinearRec2020<float>>::convert): Deleted.
(WebCore::LinearSRGBA<float>>::convert): Deleted.
(WebCore::xyzToLinear): Deleted.
(WebCore::linearToXYZ): Deleted.
(WebCore::XYZFor<LinearA98RGB<float>>>::convert): Deleted.
(WebCore::XYZFor<LinearDisplayP3<float>>>::convert): Deleted.
(WebCore::XYZFor<LinearExtendedSRGBA<float>>>::convert): Deleted.
(WebCore::XYZFor<LinearProPhotoRGB<float>>>::convert): Deleted.
(WebCore::XYZFor<LinearRec2020<float>>>::convert): Deleted.
(WebCore::XYZFor<LinearSRGBA<float>>>::convert): Deleted.
(WebCore::XYZFor<Lab<float>>>::convert): Deleted.
(WebCore::XYZFor<A98RGB<float>>>::convert): Deleted.
(WebCore::XYZFor<DisplayP3<float>>>::convert): Deleted.
(WebCore::XYZFor<ExtendedSRGBA<float>>>::convert): Deleted.
(WebCore::XYZFor<HSLA<float>>>::convert): Deleted.
(WebCore::XYZFor<HWBA<float>>>::convert): Deleted.
(WebCore::XYZFor<LCHA<float>>>::convert): Deleted.
(WebCore::XYZFor<ProPhotoRGB<float>>>::convert): Deleted.
(WebCore::XYZFor<Rec2020<float>>>::convert): Deleted.
(WebCore::XYZFor<SRGBA<float>>>::convert): Deleted.

  • platform/graphics/ColorConversion.h:

(WebCore::ColorConversion::convert):
(WebCore::ColorConversion::toLinearEncoded):
(WebCore::ColorConversion::toGammaEncoded):
(WebCore::ColorConversion::toExtended):
(WebCore::ColorConversion::toBounded):
(WebCore::ColorConversion::handleRGBFamilyConversion):
(WebCore::ColorConversion::handleMatrixConversion):

  • platform/graphics/ColorMatrix.h:

(WebCore::operator==):
(WebCore::operator!=):
(WebCore::applyMatricesToColorComponents):

  • platform/graphics/ColorTypes.h:
12:35 PM Changeset in webkit [272836] by ap@apple.com
  • 2 edits in trunk/Source/WebKit

Unreviewed build fix.

  • UIProcess/ios/WKContentViewInteraction.mm:

(-[WKContentView pointerInteraction:styleForRegion:]):

11:13 AM Changeset in webkit [272835] by Darin Adler
  • 2 edits in trunk/Source/WebCore

Improve computed style handling in degenerate grid cases, sizes and lengths of zero
​https://bugs.webkit.org/show_bug.cgi?id=221856

Reviewed by Anders Carlsson.

  • css/CSSComputedStyleDeclaration.cpp:

(WebCore::valueForImageSliceSide): Handle "auto", which can come up with sizes of zero.
(WebCore::valueForNinePieceImage): Simplify by not putting Ref<> results into RefPtr<> locals.
(WebCore::valueForGridTrackList): Clamp insertion point to the actual size of the tracks,
since it can be set to an arbitrary larger value.

11:07 AM Changeset in webkit [272834] by Alan Bujtas
  • 5 edits in trunk/Source/WebCore

[LFC][Integration] Not every inline box contributes to line overflow
​https://bugs.webkit.org/show_bug.cgi?id=221867

Reviewed by Antti Koivisto.

Consider the follow content:
<div style="font-size: 20px;">content<span style="font-size: 200px;"><img></span></div>

In quirks mode, the inline box (<span>) does not stretch the line box vertically. What it means in practice is
that the inline box's descent is ignored. While the inline box has a relatively large descent and
in theory it overflows the line (since it is larger than the root inline box's descent)
it should not be taken into account when computing the scrollable overflow.
However adding "padding: 1px" to the <span> will make the inline box stretch the line and now this "1px padding" will
contribute to the scrollable overflow.

  • layout/integration/LayoutIntegrationInlineContentBuilder.cpp:

(WebCore::LayoutIntegration::InlineContentBuilder::build const):
(WebCore::LayoutIntegration::InlineContentBuilder::createDisplayLines const):
(WebCore::LayoutIntegration::InlineContentBuilder::createDisplayNonRootInlineBoxes const):

  • layout/integration/LayoutIntegrationInlineContentBuilder.h:
  • layout/integration/LayoutIntegrationLine.h:

(WebCore::LayoutIntegration::NonRootInlineBox::NonRootInlineBox):
(WebCore::LayoutIntegration::NonRootInlineBox::canContributeToLineOverflow const):

  • layout/integration/LayoutIntegrationLineLayout.cpp:

(WebCore::LayoutIntegration::LineLayout::constructContent):

10:18 AM Changeset in webkit [272833] by commit-queue@webkit.org
  • 2 edits in trunk/JSTests

JSC stress test stress/copy-data-properties-fast-path.js.default fails on s390x and ppc64le
​https://bugs.webkit.org/show_bug.cgi?id=221557

Patch by Michael Catanzaro <Michael Catanzaro> on 2021-02-13
Reviewed by Saam Barati.

Skip the test on these architectures. I don't know what else to do with it.

  • stress/copy-data-properties-fast-path.js:
2:59 AM Changeset in webkit [272832] by ysuzuki@apple.com
  • 2 edits in trunk/JSTests

Unreviewed, fix stress/copy-data-properties-fast-path.js occasional failure

Wrap it with try-catch since stack-overflow RangeError in JS can happen.

  • stress/copy-data-properties-fast-path.js:
2:12 AM Changeset in webkit [272831] by ysuzuki@apple.com
  • 9 edits
    1 copy
    1 add
    2 deletes in trunk/Source

[JSC] Enable JITCage on macOS
​https://bugs.webkit.org/show_bug.cgi?id=221805
<rdar://problem/74153806>

Reviewed by Mark Lam.

Source/JavaScriptCore:

We enable JITCage too on macOS if it is ARM64E.
We need to add this entitlement only when building it on macOS 120000 or higher version.
Otherwise, we cannot launch the process. This means that we need to dynamically generate entitlements file
because we must not attach this entitlement when building JSC for non 120000 macOS.

This patch follows r248164's way: we must not use CODE_SIGN_ENTITLEMENTS because XCode inserts implicit code-signing
and it breaks our pipeline. We need to disable this XCode's implicit behavior by setting CODE_SIGN_INJECT_BASE_ENTITLEMENTS.

And we also create TestAPI.xcconfig to apply generated entitlements only to testapi and jsc shell.

  • Configurations/Base.xcconfig:
  • Configurations/JSC.xcconfig:
  • Configurations/TestAPI.xcconfig: Copied from Source/JavaScriptCore/Configurations/ToolExecutable.xcconfig.
  • Configurations/ToolExecutable.xcconfig:
  • JavaScriptCore.xcodeproj/project.pbxproj:
  • Scripts/process-entitlements.sh: Added.
  • allow-jit-macOS.entitlements: Removed.
  • testapi.entitlements: Removed.

Source/WebKit:

We need to add this entitlement only when building it on macOS 120000 or higher version.
Otherwise, we cannot launch the process. And we attach this entitlement only when building processes
with Apple Internal SDKs.

  • Scripts/process-entitlements.sh:

Source/WTF:

Enable JIT_CAGE when macOS is 120000 or higher with ARM64E.

  • wtf/PlatformEnable.h:
Note: See TracTimeline for information about the timeline view.