[webkit-changes] [WebKit/WebKit] fecd1d: Cherry-pick a6fb71355a3d. rdar://problem/102650207

[Alex Christensen]

  Branch: refs/heads/safari-7615.1.14-branch
  Home:   https://github.com/WebKit/WebKit
  Commit: fecd1dbdadbfbc08ac38ea1b8126823dc2f3dbca
      https://github.com/WebKit/WebKit/commit/fecd1dbdadbfbc08ac38ea1b8126823dc2f3dbca
  Author: Razvan Caliman <rcaliman at apple.com>
  Date:   2022-12-08 (Thu, 08 Dec 2022)

  Changed paths:
    M LayoutTests/inspector/css/css-property-expected.txt
    M LayoutTests/inspector/css/css-property.html
    M Source/WebCore/inspector/InspectorStyleSheet.cpp

  Log Message:
  -----------
  Cherry-pick a6fb71355a3d. rdar://problem/102650207

    Web Inspector: REGRESSION(r256223 at main) Styles Panel: All CSS variables marked as unsupported
    https://bugs.webkit.org/show_bug.cgi?id=248314

    Reviewed by Darin Adler.

    Querying `WebCore::cssPropertyID()` defined in `CSSPropertyParser.cpp`
    with a CSS custom property name (aka CSS variable) mistakenly returns
    `CSSPropertyID::CSSPropertyInvalid` instead of `CSSPropertyID::CSSPropertyCustom`.

    This was also the case before https://github.com/WebKit/WebKit/pull/5986 landed,
    so this wasn't regressed by it.

    What the refactoring in https://github.com/WebKit/WebKit/pull/5986 did was to
    introduce stricter checks in `PropertySetCSSStyleDeclaration::isExposed()`
    and in `WebCore::isExposed()` declared in the generated file `CSSPropertyNames.cpp`
    to return `false` when encountering `CSSPropertyID::CSSPropertyInvalid`.

    The specific `CSSPropertyID` wasn't of particular importance for Web Inspector so the
    wrong id didn't cause issues previously.

    But `InspectorStyle::styleWithProperties()` makes use of the `isExposed()` check to
    mark a CSS custom property as `property->setParsedOk(false)` which ultimately marks it
    as unsupported in the Web Inspector frontend.

    Now that the check is more strict, compounded with the effect of the mistaken
    `CSSPropertyID::CSSPropertyInvalid`, causes CSS custom properties to be incorrectly
    marked as unsupported.

    To mitigate this:

    - explicitly check if the property is a custom property and assign it the correct id of
    `CSSPropertyID::CSSPropertyCustom`.

    - since `WebCore::nameString()` can't return an arbitrary CSS custom property name
    even if it were provided the correct `CSSPropertyID`, we guard for this before calling the method.

    There are many callers of `WebCore::cssPropertyID()` and only some of them
    manually check for `WebCore::isCustomPropertyName()` to take special action.
    Fixing the root issue so that it correctly returns `CSSPropertyID::CSSPropertyCustom`
    will be done in another patch to account for any regressions it may introduce.

    * LayoutTests/inspector/css/css-property-expected.txt:
    * LayoutTests/inspector/css/css-property.html:

    Added a check that CSS custom properties are valid.
    `Protocol::CSS::CSSProperty::parsedOk` maps to `WI.CSSProperty.valid`.

    * Source/WebCore/inspector/InspectorStyleSheet.cpp:
    (WebCore::InspectorStyle::styleWithProperties const):

    Canonical link: https://commits.webkit.org/257564@main

Canonical link: https://commits.webkit.org/257350.6@safari-7615.1.14-branch


  Commit: 85272a0e3a2be85e32dd6b20b9819dbc3a1d55b8
      https://github.com/WebKit/WebKit/commit/85272a0e3a2be85e32dd6b20b9819dbc3a1d55b8
  Author: Alex Christensen <achristensen at apple.com>
  Date:   2022-12-08 (Thu, 08 Dec 2022)

  Changed paths:
    M Source/WebKit/Scripts/generate-serializers.py
    M Source/WebKit/Scripts/webkit/tests/GeneratedSerializers.cpp
    M Source/WebKit/Scripts/webkit/tests/GeneratedSerializers.h
    M Source/WebKit/Scripts/webkit/tests/SerializedTypeInfo.cpp
    M Source/WebKit/Scripts/webkit/tests/TestSerializedType.serialization.in
    M Source/WebKit/Shared/mac/WebHitTestResultPlatformData.serialization.in

  Log Message:
  -----------
  Cherry-pick 5e92b798c222. rdar://problem/103099864

    Don't call getDDActionContextClass if we don't have a DDActionContext to decode
    https://bugs.webkit.org/show_bug.cgi?id=248931
    rdar://103099864

    Reviewed by Aditya Keerthi.

    This fixes a regression from 257087 at main, before which we would only call getDDActionContextClass
    if hasActionContext was true.  This restores equivalent behavior by supporting the Nullable attribute
    when encoding soft linked ObjC classes.

    * Source/WebKit/Scripts/generate-serializers.py:
    (decode_type):
    * Source/WebKit/Scripts/webkit/tests/GeneratedSerializers.cpp:
    (IPC::ArgumentCoder<NullableSoftLinkedMember>::encode):
    (IPC::ArgumentCoder<NullableSoftLinkedMember>::decode):
    * Source/WebKit/Scripts/webkit/tests/GeneratedSerializers.h:
    * Source/WebKit/Scripts/webkit/tests/SerializedTypeInfo.cpp:
    (WebKit::allSerializedTypes):
    * Source/WebKit/Scripts/webkit/tests/TestSerializedType.serialization.in:
    * Source/WebKit/Shared/mac/WebHitTestResultPlatformData.serialization.in:

    Canonical link: https://commits.webkit.org/257575@main

Canonical link: https://commits.webkit.org/257350.7@safari-7615.1.14-branch


Compare: https://github.com/WebKit/WebKit/compare/17c70727628c...85272a0e3a2b