[webkit-changes] [WebKit/WebKit] 809cef: Versioning.

MyahCobbs noreply at github.com
Tue May 14 14:28:32 PDT 2024


  Branch: refs/heads/safari-7619.0.1-branch
  Home:   https://github.com/WebKit/WebKit
  Commit: 809cefc4f62ff3a1f08a8a0619bd99cd308f4d95
      https://github.com/WebKit/WebKit/commit/809cefc4f62ff3a1f08a8a0619bd99cd308f4d95
  Author: Dan Robson <dtr_bugzilla at apple.com>
  Date:   2024-01-10 (Wed, 10 Jan 2024)

  Changed paths:
    M Configurations/Version.xcconfig

  Log Message:
  -----------
  Versioning.

WebKit-619.0.1

Canonical link: https://commits.webkit.org/271831.78@safari-7619.0.1-branch


  Commit: 0abaf262ea36155da15c36d5d9f9887ec69df94a
      https://github.com/WebKit/WebKit/commit/0abaf262ea36155da15c36d5d9f9887ec69df94a
  Author: Dan Robson <dtr_bugzilla at apple.com>
  Date:   2024-01-10 (Wed, 10 Jan 2024)

  Changed paths:
    A LayoutTests/compositing/repaint/copy-forward-clear-rect-expected.html
    A LayoutTests/compositing/repaint/copy-forward-clear-rect.html
    M Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.cpp

  Log Message:
  -----------
  Cherry-pick 126e5bd39128. rdar://120666136

    Cherry-pick 272394 at main (5ce41d80d507). rdar://120666136

        Wikipedia video control icon backgrounds flicker.
        https://bugs.webkit.org/show_bug.cgi?id=266726
        <rdar://119868478>

        Reviewed by Simon Fraser.

        The previous code always required a full repaint of the layer whenever a buffer was allocated,
        so the copy-forward code didn't run on the second paint of a layer. This meant the copy-forward
        code, and the 'buffer is already clear' optimization were mutually exclusive.

        The new code uses copy-forward and partial repaints whenever possible, even if the front buffer
        was newly allocated (or existing, but purged).

        The copy-forward code tries to only copy pixels that won't be re-drawn this frame, but is rounded
        out to a single rectangle, not a complex region.

        If the copy-forwards ends up copying pixels that we'll also drawn this frame, we can no longer
        consider the buffer to be 'clear' and have to manually clear the paint region.

        * LayoutTests/compositing/repaint/copy-forward-clear-rect-expected.html: Added.
        * LayoutTests/compositing/repaint/copy-forward-clear-rect.html: Added.
        * Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.cpp:
        (WebKit::RemoteImageBufferSet::prepareBufferForDisplay):

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

Canonical link: https://commits.webkit.org/271831.79@safari-7619.0.1-branch


  Commit: a45d162a0c38b002526c361fe504fe55dd325cca
      https://github.com/WebKit/WebKit/commit/a45d162a0c38b002526c361fe504fe55dd325cca
  Author: Dan Robson <dtr_bugzilla at apple.com>
  Date:   2024-01-10 (Wed, 10 Jan 2024)

  Changed paths:
    R Source/WebKit/UIProcess/API/ios/WKSEDefinitions.h
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
    A Source/WebKit/UIProcess/ios/WKSEDefinitions.h
    M Source/WebKit/WebKit.xcodeproj/project.pbxproj
    M Tools/TestRunnerShared/spi/UIKitSPIForTesting.h
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/ImageAnalysisTests.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKContentViewEditingActions.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEditActions.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/iOSMouseSupport.mm
    M Tools/TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm
    M Tools/TestWebKitAPI/Tests/ios/EnterKeyHintTests.mm
    M Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm
    M Tools/TestWebKitAPI/Tests/ios/SelectionModifyByParagraphBoundary.mm
    M Tools/TestWebKitAPI/Tests/ios/TextServicesTests.mm
    M Tools/TestWebKitAPI/Tests/ios/WKScrollViewTests.mm
    M Tools/TestWebKitAPI/cocoa/TestWKWebView.h
    M Tools/TestWebKitAPI/cocoa/TestWKWebView.mm
    M Tools/WebKitTestRunner/Configurations/Base.xcconfig
    M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h
    M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm

  Log Message:
  -----------
  Cherry-pick 043e71bfb015. rdar://120812716

    [iOS] Prepare API tests for async text input enablement
    https://bugs.webkit.org/show_bug.cgi?id=266578
    rdar://119816733

    Reviewed by Aditya Keerthi.

    Prepare our API tests for async text input enablement on iOS, many of which currently call into
    legacy SPI methods that crash with the feature flag enabled. To avoid these release assertions, we
    refactor all tests which explicitly call into these codepaths, such that they'll invoke their
    `UIAsyncTextInput` counterparts when `UIKit/async_text_input` is enabled.

    See below for more details.

    * Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView moveInDirection:byGranularity:]):
    (-[WKContentView extendInDirection:byGranularity:]):

    Also drive-by fix an actual bug that was caught by `SelectionTests.ModifyByParagraphBoundary`.
    Instead of just moving backward or forward by paragraph granularity in the `UIAsyncTextInput` method
    `-extendInDirection:byGranularity:`, we need to additionally move backwards or forwards by character
    before doing so in order to maintain parity with `-_moveToEndOfParagraph:withHistory:` and
    `_moveToStartOfParagraph:withHistory:`.

    * Source/WebKit/UIProcess/ios/WKSEDefinitions.h: Renamed from Source/WebKit/UIProcess/API/ios/WKSEDefinitions.h.

    Also move `WKSEDefinitions.h` to `UIProcess/ios` instead of `UIProcess/API/ios`, since the latter
    just holds iOS-specific files related to WebKit API objects (in this case, only `WKWebView`).
    Putting this in `UIProcess/ios` seems more appropriate, and also allows us to include it directly in
    WebKitTestRunner.

    * Source/WebKit/WebKit.xcodeproj/project.pbxproj:
    * Tools/TestRunnerShared/spi/UIKitSPIForTesting.h:
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm:
    (-[TestWKWebView synchronouslyAdjustSelectionWithDelta:]): Deleted.
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/ImageAnalysisTests.mm:
    (TestWebKitAPI::simulateEditContextMenuAppearance):
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/WKContentViewEditingActions.mm:
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEditActions.mm:
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/iOSMouseSupport.mm:
    (TestWebKitAPI::simulateEditContextMenuAppearance):
    * Tools/TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm:
    (-[TestWKWebView autocorrectionRectsForString:]): Deleted.
    (-[TestWKWebView synchronouslyRequestAutocorrectionContext]): Deleted.
    * Tools/TestWebKitAPI/Tests/ios/EnterKeyHintTests.mm:
    (-[TestWKWebView test:enterKeyHint:returnKeyType:]):
    * Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:
    * Tools/TestWebKitAPI/Tests/ios/SelectionModifyByParagraphBoundary.mm:
    * Tools/TestWebKitAPI/Tests/ios/TextServicesTests.mm:
    * Tools/TestWebKitAPI/Tests/ios/WKScrollViewTests.mm:
    * Tools/TestWebKitAPI/cocoa/TestWKWebView.h:
    * Tools/TestWebKitAPI/cocoa/TestWKWebView.mm:

    Add a bunch of new category helpers on `WKWebView`, which replace many of the direct calls into
    `WKContentView` in our API tests when exercising various `UIWKInteractionViewProtocol` SPIs. These
    helper methods will call directly into these legacy SPIs when async text input is disabled, but will
    call into their new `UIAsyncTextInput` counterparts when async text input is enabled.

    (-[WKWebView defineSelection]):
    (-[WKWebView shareSelection]):
    (-[WKWebView hasAsyncTextInput]):
    (-[WKWebView selectionClipRect]):
    (-[WKWebView moveSelectionToStartOfParagraph]):
    (-[WKWebView extendSelectionToStartOfParagraph]):
    (-[WKWebView moveSelectionToEndOfParagraph]):
    (-[WKWebView extendSelectionToEndOfParagraph]):
    (-[WKWebView asyncTextInput]):
    (-[WKWebView extendedTextInputTraits]):
    (-[WKWebView autocorrectionRectsForString:]):
    (-[WKWebView autocorrectionContext]):
    (-[WKWebView effectiveTextInputTraits]):
    (-[WKWebView replaceText:withText:shouldUnderline:completion:]):
    (wrap):
    (unwrap):
    (-[WKWebView synchronouslyAdjustSelectionWithDelta:]):
    (-[WKWebView selectTextForContextMenuWithLocationInView:completion:]):
    (-[WKWebView handleKeyEvent:completion:]):
    * Tools/WebKitTestRunner/Configurations/Base.xcconfig:
    * Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h:
    * Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm:
    (WTR::UIScriptControllerIOS::asyncTextInput const):

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

Canonical link: https://commits.webkit.org/271831.80@safari-7619.0.1-branch


  Commit: e681ed9048cbff59186dca126cd2d7600752352f
      https://github.com/WebKit/WebKit/commit/e681ed9048cbff59186dca126cd2d7600752352f
  Author: Dan Robson <dtr_bugzilla at apple.com>
  Date:   2024-01-10 (Wed, 10 Jan 2024)

  Changed paths:
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
    M Tools/TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm

  Log Message:
  -----------
  Cherry-pick 1f6aecd2d650. rdar://120666173

    [UIAsyncTextInput] Fix several failing iOS API tests when async text input is enabled
    https://bugs.webkit.org/show_bug.cgi?id=267064
    rdar://120438466

    Reviewed by Megan Gardner.

    Fix 4 failing API tests, when async text input is enabled:

    • DragAndDropTests.ContentEditableToContentEditable
    • DragAndDropTests.ContentEditableToTextarea

    These two tests are failing because they expect WebKit to write RTF and/or FlatRTFD upon starting a
    drag. This is no longer the case when this feature is enabled, since the system now takes care of
    lazily coercing web archive and HTML data to RTF/FlatRTFD/`NSAttributedString` as needed.

    As such, we simply adjust this test to pass as long as HTML data is placed at a higher type fidelity
    than plain text.

    • KeyboardInputTests.IsSingleLineDocument

    This actually caught a real bug, where we're failing to actually set the `singleLineDocument`
    property on the extended traits delegate (`WKSEExtendedTextInputTraits`), since the call site is
    guarded by a `-respondsToSelector:` check for `-setIsSingleLineDocument:` (the legacy name on
    private text input traits) instead of `-setSingleLineDocument:` (the new property name on the
    extended traits).

    Fix the test by fixing `-_updateTextInputTraits:`.

    • KeyboardInputTests.EditableWebViewRequiresKeyboardWhenFirstResponder

    This test failure is due to the fact that, for a fully-editable web view (i.e. if the embedder sets
    `-[WKWebView _editable]` to `YES`), `-_requiresKeyboardWhenFirstResponder` now returns `YES` instead
    of `NO` when focusing a `readonly` text field.

    Address this and restore shipping behavior by only reverting to the superclass implementation in the
    case where the web view is not fully editable.

    * Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView _requiresKeyboardWhenFirstResponder]):
    (-[WKContentView _updateTextInputTraits:]):
    * Tools/TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm:
    (checkRichTextTypePrecedesPlainTextType):

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

Canonical link: https://commits.webkit.org/271831.81@safari-7619.0.1-branch


  Commit: 87806d1f74bad966e7653513a6879b7d46390704
      https://github.com/WebKit/WebKit/commit/87806d1f74bad966e7653513a6879b7d46390704
  Author: Dan Robson <dtr_bugzilla at apple.com>
  Date:   2024-01-10 (Wed, 10 Jan 2024)

  Changed paths:
    M LayoutTests/TestExpectations
    A LayoutTests/fast/scrolling/mac/keyboard-rubberband-expected.txt
    A LayoutTests/fast/scrolling/mac/keyboard-rubberband.html
    M LayoutTests/imported/w3c/web-platform-tests/css/css-scroll-anchoring/start-edge-in-block-layout-direction-expected.txt
    M Source/WebCore/page/scrolling/ScrollAnchoringController.cpp
    M Source/WebCore/platform/ScrollAnimator.cpp

  Log Message:
  -----------
  Cherry-pick 50c9dcae7344. rdar://120662157

    [scroll-anchoring] Keyboard scrolling into a rubberband leaves the page stuck at a bad scroll offset
    https://bugs.webkit.org/show_bug.cgi?id=267061
    rdar://120053910

    Reviewed by Simon Fraser.

    After https://commits.webkit.org/271957@main we disabled scroll anchoring adjustments while
    m_owningScrollableArea.isRubberBandInProgress() is true. However, this is not true during a
    keyboard scroll. A better solution to this is to invalidate the scroll anchoring element in
    ScrollAnimator::setCurrentPosition itself. Normally scroll position changes here would be sent
    down into the scrollable area via setScrollPositionFromAnimation, however while rubberbanding
    notify is NotifyScrollableArea::No, so we don't propagate the scroll position change to the
    scrollable area. Now that we properly notfiy the scroll anchoring controller of the scroll
    position change while rubberbanding, we can remove the old solution.

    * Source/WebCore/page/scrolling/ScrollAnchoringController.cpp:
    (WebCore::ScrollAnchoringController::adjustScrollPositionForAnchoring):
    * Source/WebCore/platform/ScrollAnimator.cpp:
    (WebCore::notifyScrollAnchoringControllerOfScroll):
    (WebCore::ScrollAnimator::setCurrentPosition):

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

Canonical link: https://commits.webkit.org/271831.82@safari-7619.0.1-branch


  Commit: c21d507f6a8708ced2c60745d3489ec2e082a631
      https://github.com/WebKit/WebKit/commit/c21d507f6a8708ced2c60745d3489ec2e082a631
  Author: Dan Robson <dtr_bugzilla at apple.com>
  Date:   2024-01-10 (Wed, 10 Jan 2024)

  Changed paths:
    M Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.cpp

  Log Message:
  -----------
  Apply patch. rdar://120666136

Canonical link: https://commits.webkit.org/271831.83@safari-7619.0.1-branch


  Commit: 078f3944a161d3afaf9a188743cd1cc9fb965169
      https://github.com/WebKit/WebKit/commit/078f3944a161d3afaf9a188743cd1cc9fb965169
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2024-01-12 (Fri, 12 Jan 2024)

  Changed paths:
    M Source/WebKit/Shared/Cocoa/ArgumentCodersCocoa.mm

  Log Message:
  -----------
  Cherry-pick 56991ea107a7. rdar://120431014

    Check framework availability for all soft linked frameworks in Core IPC code
    https://bugs.webkit.org/show_bug.cgi?id=267052
    rdar://120004741

    Reviewed by Andy Estes.

    If we softlink a framework, it stands to reason that it might be unavailable at runtime.
    So before looking up a `Class` that exists in such a framework, make sure the framework is available.

    * Source/WebKit/Shared/Cocoa/ArgumentCodersCocoa.mm:
    (IPC::typeFromObject):

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

Identifier: 270272.1643 at safari-7619.0.1-branch


  Commit: 7d1ede9ccf3c675ca660d6fb0342240c4e760a7e
      https://github.com/WebKit/WebKit/commit/7d1ede9ccf3c675ca660d6fb0342240c4e760a7e
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2024-01-12 (Fri, 12 Jan 2024)

  Changed paths:
    M LayoutTests/fast/scrolling/ios/scroll-anchoring-momentum-scroll.html
    A LayoutTests/fast/scrolling/ios/scroll-anchoring-when-revealing-focused-element-expected.txt
    A LayoutTests/fast/scrolling/ios/scroll-anchoring-when-revealing-focused-element.html
    M LayoutTests/resources/ui-helper.js
    M Source/WebCore/page/LocalFrameView.cpp
    M Source/WebKit/UIProcess/API/ios/WKWebViewPrivateForTestingIOS.h
    M Source/WebKit/UIProcess/API/ios/WKWebViewTestingIOS.mm
    M Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl
    M Tools/TestRunnerShared/UIScriptContext/UIScriptController.h
    M Tools/WebKitTestRunner/ios/TestControllerIOS.mm
    M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h
    M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm

  Log Message:
  -----------
  Cherry-pick 184aa40be65f. rdar://120887424

    [iOS] [scroll-anchoring] Software keyboard overlaps input field on webauthn.io
    https://bugs.webkit.org/show_bug.cgi?id=267440
    rdar://120753568

    Reviewed by Simon Fraser.

    It's possible for scroll anchoring to cause the scroll position to jump to the previously anchored
    element, when scrolling to reveal the focused element on top of the software keyboard on iOS. This
    scrolling (driven by `-_zoomToCenter:atScale:animated:` in the UI process) is bookended in Safari by
    calls to `-_(begin|end)InteractiveObscuredInsetsChange` while the keyboard is showing, which puts us
    in unstable state and also passes `ViewportRectStability::ChangingObscuredInsetsInteractively` into
    `AsyncScrollingCoordinator::reconcileScrollingState`. This, in turn, means we'll skip setting the
    layout viewport override rect when syncing the scroll position.

    This isn't normally an issue, because we'll eventually update the layout viewport once we end
    interactive obscured inset changes. However, in the context of scroll anchoring, the fact that the
    scroll position is updated but the layout viewport rect isn't (when reconciling scrolling state)
    means that it's possible for the scroll anchoring controller to adjust the layout viewport rect in
    the following codepath during layout:

    ```
    void LocalFrameView::updateLayoutViewport()
    {
        …
        if (m_layoutViewportOverrideRect) {
            if (currentScrollType() == ScrollType::Programmatic) {
                LOG_WITH_STREAM(Scrolling, stream << "computing new override layout viewport because of programmatic scrolling");
                LayoutPoint newOrigin = computeLayoutViewportOrigin(visualViewportRect(), minStableLayoutViewportOrigin(), maxStableLayoutViewportOrigin(), layoutViewport, StickToDocumentBounds);
                setLayoutViewportOverrideRect(LayoutRect(newOrigin, m_layoutViewportOverrideRect.value().size()));
            }
            layoutOrVisualViewportChanged();
            return;
        }
    ```

    ..._without_ having properly invalidated and updated the current scroll anchor. In turn, this makes
    it possible for us to compare the layout viewport after accounting for the keyboard scrolling amount
    against a stale `m_lastOffsetForAnchorElement`, causing the adjustment to overcompensate and jump
    back up to the top of the page in the middle of the keyboard scrolling animation.

    To fix this, we simply invalidate the anchor element on `ScrollAnchoringController` (along with the
    stale `m_lastOffsetForAnchorElement`) when the layout viewport changes.

    * LayoutTests/fast/scrolling/ios/scroll-anchoring-momentum-scroll.html:

    Drive-by fix: indentation.

    * LayoutTests/fast/scrolling/ios/scroll-anchoring-when-revealing-focused-element-expected.txt: Added.
    * LayoutTests/fast/scrolling/ios/scroll-anchoring-when-revealing-focused-element.html: Added.

    Add a new layout test that fails without this fix. While it doesn't precisely simulate the bug as it
    appears on webauthn.io, it exercises the same root cause by repeatedly triggering scroll anchoring
    adjustment while scrolling to reveal the focused element with the software keyboard, all in the
    scope of interactive obscured inset changes.

    * LayoutTests/resources/ui-helper.js:
    (window.UIHelper.beginInteractiveObscuredInsetsChange):
    (window.UIHelper.endInteractiveObscuredInsetsChange):
    (window.UIHelper.setObscuredInsets):

    Add new `UIHelper` methods to allow layout tests to adjust the obscured insets in the same way that
    Safari does when showing the software keyboard.

    * Source/WebCore/page/LocalFrameView.cpp:
    (WebCore::LocalFrameView::setLayoutViewportOverrideRect):

    See comments above for more detail.

    * Source/WebKit/UIProcess/API/ios/WKWebViewPrivateForTestingIOS.h:
    * Source/WebKit/UIProcess/API/ios/WKWebViewTestingIOS.mm:
    (-[WKWebView _resetObscuredInsetsForTesting]):

    Add a testing hook to reset the web view's obscured insets; used when resetting state in between
    layout tests.

    * Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:
    * Tools/TestRunnerShared/UIScriptContext/UIScriptController.h:
    (WTR::UIScriptController::beginInteractiveObscuredInsetsChange):
    (WTR::UIScriptController::endInteractiveObscuredInsetsChange):
    (WTR::UIScriptController::setObscuredInsets):

    Add boilerplate code to implement the new script controller helper methods.

    * Tools/WebKitTestRunner/ios/TestControllerIOS.mm:
    (WTR::TestController::platformResetStateToConsistentValues):
    * Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h:
    * Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm:
    (WTR::UIScriptControllerIOS::beginInteractiveObscuredInsetsChange):
    (WTR::UIScriptControllerIOS::setObscuredInsets):
    (WTR::UIScriptControllerIOS::endInteractiveObscuredInsetsChange):

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

Identifier: 270272.1644 at safari-7619.0.1-branch


  Commit: 20e2ad59fce4ffc7dbd499e4d78462b5224e61ef
      https://github.com/WebKit/WebKit/commit/20e2ad59fce4ffc7dbd499e4d78462b5224e61ef
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2024-01-18 (Thu, 18 Jan 2024)

  Changed paths:
    M Configurations/Version.xcconfig

  Log Message:
  -----------
  Versioning.

WebKit-7619.0.1.1

Identifier: 271831.86 at safari-7619.0.1-branch


  Commit: fa54c9c9ab747fc1b47ff6a285754fea39f4739a
      https://github.com/WebKit/WebKit/commit/fa54c9c9ab747fc1b47ff6a285754fea39f4739a
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2024-01-22 (Mon, 22 Jan 2024)

  Changed paths:
    M Configurations/Version.xcconfig

  Log Message:
  -----------
  Versioning.

WebKit-7619.0.1.2

Identifier: 271831.87 at safari-7619.0.1-branch


Compare: https://github.com/WebKit/WebKit/compare/809cefc4f62f%5E...fa54c9c9ab74

To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications


More information about the webkit-changes mailing list