Timeline

Jul 25, 2021:

3:32 PM Changeset in webkit [280289] by Alexey Shvayka

• 36 edits
  2 adds in trunk

Partly implement Function.prototype.{caller,arguments} reflection proposal
​https://bugs.webkit.org/show_bug.cgi?id=158116

Reviewed by Yusuke Suzuki.

JSTests:

• ChakraCore/test/strict/19.function.baseline:
• ChakraCore/test/strict/22.callerCalleeArguments.baseline-jsc:
• microbenchmarks/function-prototype-get.js: Added.
• microbenchmarks/reflect-own-keys-function.js: Added.
• stress/for-in-shadow-non-enumerable.js:
• stress/function-hidden-as-caller.js:
• stress/has-own-property-arguments.js:
• stress/object-assign-fast-path.js:
• stress/put-to-proto-chain-overrides-put.js:
• stress/reflect-set.js:
• test262/config.yaml: Skip 3 test cases that are now incorrect.
• test262/expectations.yaml: Mark 2 test cases as passing.

Source/JavaScriptCore:

To ensure web-compatibility, only the safe subset of Function.prototype.{caller,arguments}
reflection proposal [1] is implemented, which is currently shipped in SpiderMonkey.

Complete list of differences from the proposed spec:

1. Cross-realm receiver function is allowed instead of throwing a TypeError.

Throwing is likely safe to ship, but #225997 needs to be fixed first for
custom properties to receive correct global object.

2. Cross-realm caller function is returned instead of null.

Hiding cross-realm caller may break things: we currently have a test for
the opposite behavior.

3. Defines "caller" and "arguments" setters that throw for disallowed receivers, instead failing silently in sloppy mode.

This is actually more restrictive than the spec, which is preferable,
and aligns with V8 and SM.

Most importantly, this patch removes own "caller" and "arguments" properties from
sloppy mode ES5 functions. They were non-configurable, making it harder to use
their holder as a ProxyTarget. They were also non-writable, with a constantly
changing Value, which violated the invariants of internal methods [2].

As a result, JSFunction methods are greatly simplified, especially defineOwnProperty()
and getOwnSpecialPropertyNames(). The latter is now 2.1x faster according to the
provided microbenchmark. Also, removes double "prototype" lookup from Get,
which is a 10% progression.

[1]: ​https://github.com/claudepache/es-legacy-function-reflection
[2]: ​https://tc39.es/ecma262/#sec-invariants-of-the-essential-internal-methods

• runtime/ClonedArguments.cpp:

(JSC::ClonedArguments::getOwnPropertySlot):
(JSC::ClonedArguments::materializeSpecials):

• runtime/FunctionExecutable.h:
• runtime/FunctionPrototype.cpp:

(JSC::FunctionPrototype::addFunctionProperties):
(JSC::isAllowedReceiverFunctionForCallerAndArguments):
(JSC::RetrieveArgumentsFunctor::RetrieveArgumentsFunctor):
(JSC::RetrieveArgumentsFunctor::result const):
(JSC::RetrieveArgumentsFunctor::operator() const):
(JSC::retrieveArguments):
(JSC::JSC_DEFINE_CUSTOM_GETTER):
(JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor):
(JSC::RetrieveCallerFunctionFunctor::result const):
(JSC::RetrieveCallerFunctionFunctor::operator() const):
(JSC::retrieveCallerFunction):
(JSC::JSC_DEFINE_CUSTOM_SETTER):
(JSC::FunctionPrototype::initRestrictedProperties): Deleted.

• runtime/FunctionPrototype.h:
• runtime/JSFunction.cpp:

(JSC::JSFunction::getOwnPropertySlot):
(JSC::JSFunction::getOwnSpecialPropertyNames):
(JSC::JSFunction::put):
(JSC::JSFunction::deleteProperty):
(JSC::JSFunction::defineOwnProperty):
(JSC::RetrieveArgumentsFunctor::RetrieveArgumentsFunctor): Deleted.
(JSC::RetrieveArgumentsFunctor::result const): Deleted.
(JSC::RetrieveArgumentsFunctor::operator() const): Deleted.
(JSC::retrieveArguments): Deleted.
(JSC::JSC_DEFINE_CUSTOM_GETTER): Deleted.
(JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor): Deleted.
(JSC::RetrieveCallerFunctionFunctor::result const): Deleted.
(JSC::RetrieveCallerFunctionFunctor::operator() const): Deleted.
(JSC::retrieveCallerFunction): Deleted.

• runtime/JSGlobalObject.cpp:

(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildrenImpl):

• runtime/JSGlobalObject.h:

Remove unused m_throwTypeErrorGetterSetter and make ThrowTypeError lazily-created.

• runtime/JSGlobalObjectFunctions.cpp:

(JSC::JSC_DEFINE_HOST_FUNCTION):

• runtime/JSGlobalObjectFunctions.h:
• runtime/JSObject.cpp:

(JSC::JSObject::putDirectCustomGetterSetterWithoutTransition):

• runtime/JSObject.h:

LayoutTests:

• inspector/model/remote-object-get-properties-expected.txt:
• inspector/runtime/getDisplayableProperties-expected.txt:
• inspector/runtime/getProperties-expected.txt:
• js/Object-getOwnPropertyNames-expected.txt:
• js/basic-strict-mode-expected.txt:
• js/kde/function_arguments-expected.txt:
• js/kde/script-tests/function_arguments.js:
• js/non-strict-function-properties-expected.txt:
• js/script-tests/Object-getOwnPropertyNames.js:
• js/script-tests/basic-strict-mode.js:
• js/script-tests/non-strict-function-properties.js:
• js/script-tests/throw-type-error-is-unique.js:

12:40 PM Changeset in webkit [280288] by Wenson Hsieh

• 20 edits
  2 adds in trunk

[iOS] Unified field is unselected after focusing URL bar if text was selected in a fixed position container
​https://bugs.webkit.org/show_bug.cgi?id=228269
rdar://80556392

Reviewed by Tim Horton.

Source/WebKit:

In Safari on iOS 15, if the selection (either ranged or caret) is inside a fixed position container when the
user taps on the unified field, we'll immediately clear the text selection inside the unified field upon
bringing up the keyboard. This happens because the tab pill in iOS 15 is lowered as the URL bar is focused,
which causes the web view to scroll slightly. This, in turn, induces a brief unstable scrolling tree state,
which then causes us to temporarily hide and show selection views while scrolling in unstable state (see
r209931) by calling -deactivateSelection and then -activateSelection on the text interaction assistant.
Calling -[UIWKTextInteractionAssistant activateSelection] then causes UIKit to dispatch a
UITextSelectionViewActivatedNotification; In the unified field, which is a UITextField subclass, UIKit code then
listens for this notification and responds to it by clearing the selection if the newly activated selection's
host view (WKContentView) is different than itself, thereby causing the bug.

To fix this, we simply make two (minor) adjustments to the logic for temporarily hiding and showing the
selection while performing an unstable scroll. See below for more details.

Test: editing/selection/ios/scrolling-with-fixed-selection-does-not-unselect-native-text-field.html

• UIProcess/ios/WKContentViewInteraction.mm:

(-[WKContentView shouldHideSelectionWhenScrolling]):

Only hide and (later) restore the selection in non-editable text if the selection is ranged. This is because
caret selections in non-editable content are not user-visible anyways, so there's no need to temporarily
suppress the selection.

(-[WKContentView _updateChangedSelection:]):

Only attempt to show the selection views again if doing so doesn't cause us to steal first responder status away
from the existing first responder; otherwise, we'll wait until we -becomeFirstResponder to -activateSelection.

(-[WKContentView selectionInteractionAssistant]): Deleted.

Tools:

We already have some very basic support for installing and removing native text fields in the view hierarchy,
through TestRunner::(add|remove)ChromeInputField(). In order to support the new layout test, we additionally
implement the ability to:

• Set text inside the native chrome input field that was installed using addChromeInputField().
• Select all text inside the chrome input field.
• Query the chrome input field for the currently selected text.

We only support iOS for the time being, with stubs on other platforms, since the new test that uses this
functionality is iOS-specific; if needed in the future for a similar test on other platforms, we can implement
the stubbed testing hooks on TestRunner and PlatformWebView as well.

• DumpRenderTree/TestRunner.h:
• DumpRenderTree/mac/TestRunnerMac.mm:

(TestRunner::setTextInChromeInputField):
(TestRunner::selectChromeInputField):
(TestRunner::getSelectedTextInChromeInputField):

• DumpRenderTree/win/TestRunnerWin.cpp:

(TestRunner::setTextInChromeInputField):
(TestRunner::selectChromeInputField):
(TestRunner::getSelectedTextInChromeInputField):

• WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl:
• WebKitTestRunner/InjectedBundle/InjectedBundle.cpp:

(WTR::InjectedBundle::didReceiveMessageToPage):
(WTR::InjectedBundle::postSetTextInChromeInputField):
(WTR::InjectedBundle::postSelectChromeInputField):
(WTR::InjectedBundle::postGetSelectedTextInChromeInputField):

• WebKitTestRunner/InjectedBundle/InjectedBundle.h:
• WebKitTestRunner/InjectedBundle/TestRunner.cpp:

(WTR::TestRunner::setTextInChromeInputField):
(WTR::TestRunner::selectChromeInputField):
(WTR::TestRunner::getSelectedTextInChromeInputField):
(WTR::TestRunner::callSetTextInChromeInputFieldCallback):
(WTR::TestRunner::callSelectChromeInputFieldCallback):
(WTR::TestRunner::callGetSelectedTextInChromeInputFieldCallback):

• WebKitTestRunner/InjectedBundle/TestRunner.h:
• WebKitTestRunner/PlatformWebView.h:
• WebKitTestRunner/TestInvocation.cpp:

(WTR::TestInvocation::didReceiveMessageFromInjectedBundle):

• WebKitTestRunner/gtk/PlatformWebViewGtk.cpp:

(WTR::PlatformWebView::setTextInChromeInputField):
(WTR::PlatformWebView::selectChromeInputField):
(WTR::PlatformWebView::getSelectedTextInChromeInputField):

• WebKitTestRunner/ios/PlatformWebViewIOS.mm:

(WTR::chromeInputField):

Additionally do some light refactoring by pulling out logic for grabbing the chrome input field (i.e. a view
with a tag of 1 under the window) out into a separate helper method. Use this helper in a few places below.

(WTR::PlatformWebView::addChromeInputField):
(WTR::PlatformWebView::setTextInChromeInputField):
(WTR::PlatformWebView::selectChromeInputField):
(WTR::PlatformWebView::getSelectedTextInChromeInputField):
(WTR::PlatformWebView::removeChromeInputField):

• WebKitTestRunner/mac/PlatformWebViewMac.mm:

(WTR::PlatformWebView::setTextInChromeInputField):
(WTR::PlatformWebView::selectChromeInputField):
(WTR::PlatformWebView::getSelectedTextInChromeInputField):

• WebKitTestRunner/win/PlatformWebViewWin.cpp:

(WTR::PlatformWebView::setTextInChromeInputField):
(WTR::PlatformWebView::selectChromeInputField):
(WTR::PlatformWebView::getSelectedTextInChromeInputField):

• WebKitTestRunner/wpe/PlatformWebViewWPE.cpp:

(WTR::PlatformWebView::setTextInChromeInputField):
(WTR::PlatformWebView::selectChromeInputField):
(WTR::PlatformWebView::getSelectedTextInChromeInputField):

LayoutTests:

Add a new layout test that installs, focuses, and selects text inside a native UITextField (simulating Safari's
URL field) while the DOM selection is inside a fixed position container, and then scrolls the web view a bit to
temporarily induce an unstable scrolling tree state. After this, we verify that the text selection inside the
native text field has not been cleared.

See Tools/ changes for more details.

• editing/selection/ios/scrolling-with-fixed-selection-does-not-unselect-native-text-field-expected.txt: Added.
• editing/selection/ios/scrolling-with-fixed-selection-does-not-unselect-native-text-field.html: Added.
• resources/ui-helper.js:

(window.UIHelper.addChromeInputField):
(window.UIHelper.removeChromeInputField):
(window.UIHelper.setTextInChromeInputField):
(window.UIHelper.selectChromeInputField):
(window.UIHelper.getSelectedTextInChromeInputField):
(window.UIHelper):

11:55 AM WebKitGTK/2.32.x edited by Adrian Perez de Castro

(diff)

11:29 AM Changeset in webkit [280287] by commit-queue@webkit.org

• 2 edits in trunk

[GTK] USE_OPENGL_OR_ES should not be an automagic feature
​https://bugs.webkit.org/show_bug.cgi?id=228266

Patch by Michael Catanzaro <Michael Catanzaro> on 2021-07-25
Reviewed by Fujii Hironori.

The USE_OPENGL_OR_ES feature flag added in r271220 is currently automagic: that is, if
neither OpenGL nor OpenGL ES is available at build time, it gets silently disabled. This is
not OK because it makes it easy for distributors to accidentally fail to enable OpenGL
support. We should require manually disabling the feature with -DUSE_OPENGL_OR_ES=OFF in
order to build with OpenGL disabled.

• Source/cmake/OptionsGTK.cmake:

6:00 AM Changeset in webkit [280286] by cathiechen

• 1 edit
  1 add in trunk/PerformanceTests

[Performance test][css-contain] Add test to contain: size layout
​https://bugs.webkit.org/show_bug.cgi?id=227948

Reviewed by Ryosuke Niwa.

This test emulates the scenario that a small part of the page is changed. If it's applied contain: size layout,
the performance should be improved. This test is a transform of the test [1] in blink.

[1] third_party/blink/perf_tests/layout/css-contain-change-text.html

• Layout/css-contain-change-size.html: Added.

Jul 24, 2021:

1:11 PM Changeset in webkit [280285] by ysuzuki@apple.com

• 12 edits in trunk/Source/JavaScriptCore

[JSC] Change most of enum in Yarr to enum-class
​https://bugs.webkit.org/show_bug.cgi?id=228264

Reviewed by Mark Lam.

This patch simply changes most of enum to enum-class in Yarr.
We also remove YarrJIT YarrGenerator's template parameter since
it is not worth doubling code. We can just hold Yarr::JITCompileMode as m_compileMode.

• runtime/RegExp.cpp:

(JSC::RegExp::compile):
(JSC::RegExp::matchConcurrently):
(JSC::RegExp::compileMatchOnly):

• runtime/RegExp.h:
• runtime/RegExpInlines.h:

(JSC::RegExp::hasCodeFor):
(JSC::RegExp::compileIfNecessary):
(JSC::RegExp::matchInline):
(JSC::RegExp::hasMatchOnlyCodeFor):
(JSC::RegExp::compileIfNecessaryMatchOnly):

• yarr/Yarr.h:

(): Deleted.

• yarr/YarrInterpreter.cpp:

(JSC::Yarr::Interpreter::backtrackPatternCharacter):
(JSC::Yarr::Interpreter::backtrackPatternCasedCharacter):
(JSC::Yarr::Interpreter::matchCharacterClass):
(JSC::Yarr::Interpreter::backtrackCharacterClass):
(JSC::Yarr::Interpreter::matchBackReference):
(JSC::Yarr::Interpreter::backtrackBackReference):
(JSC::Yarr::Interpreter::parenthesesDoBacktrack):
(JSC::Yarr::Interpreter::matchParenthesesOnceBegin):
(JSC::Yarr::Interpreter::matchParenthesesOnceEnd):
(JSC::Yarr::Interpreter::backtrackParenthesesOnceBegin):
(JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd):
(JSC::Yarr::Interpreter::matchParenthesesTerminalBegin):
(JSC::Yarr::Interpreter::matchParenthesesTerminalEnd):
(JSC::Yarr::Interpreter::backtrackParenthesesTerminalBegin):
(JSC::Yarr::Interpreter::matchParentheticalAssertionBegin):
(JSC::Yarr::Interpreter::matchParentheticalAssertionEnd):
(JSC::Yarr::Interpreter::backtrackParentheticalAssertionBegin):
(JSC::Yarr::Interpreter::backtrackParentheticalAssertionEnd):
(JSC::Yarr::Interpreter::matchParentheses):
(JSC::Yarr::Interpreter::backtrackParentheses):
(JSC::Yarr::Interpreter::matchDisjunction):
(JSC::Yarr::Interpreter::matchNonZeroDisjunction):
(JSC::Yarr::ByteCompiler::atomParenthesesOnceBegin):
(JSC::Yarr::ByteCompiler::atomParenthesesTerminalBegin):
(JSC::Yarr::ByteCompiler::atomParenthesesSubpatternBegin):
(JSC::Yarr::ByteCompiler::atomParentheticalAssertionBegin):
(JSC::Yarr::ByteCompiler::atomParentheticalAssertionEnd):
(JSC::Yarr::ByteCompiler::closeAlternative):
(JSC::Yarr::ByteCompiler::closeBodyAlternative):
(JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
(JSC::Yarr::ByteCompiler::atomParenthesesOnceEnd):
(JSC::Yarr::ByteCompiler::atomParenthesesTerminalEnd):
(JSC::Yarr::ByteCompiler::emitDisjunction):
(JSC::Yarr::ByteCompiler::dumpDisjunction):

• yarr/YarrInterpreter.h:

(JSC::Yarr::ByteTerm::ByteTerm):
(JSC::Yarr::ByteTerm::BOL):
(JSC::Yarr::ByteTerm::CheckInput):
(JSC::Yarr::ByteTerm::UncheckInput):
(JSC::Yarr::ByteTerm::EOL):
(JSC::Yarr::ByteTerm::WordBoundary):
(JSC::Yarr::ByteTerm::BackReference):
(JSC::Yarr::ByteTerm::BodyAlternativeBegin):
(JSC::Yarr::ByteTerm::BodyAlternativeDisjunction):
(JSC::Yarr::ByteTerm::BodyAlternativeEnd):
(JSC::Yarr::ByteTerm::AlternativeBegin):
(JSC::Yarr::ByteTerm::AlternativeDisjunction):
(JSC::Yarr::ByteTerm::AlternativeEnd):
(JSC::Yarr::ByteTerm::SubpatternBegin):
(JSC::Yarr::ByteTerm::SubpatternEnd):
(JSC::Yarr::ByteTerm::DotStarEnclosure):

• yarr/YarrJIT.cpp:

(JSC::Yarr::jitCompile):

• yarr/YarrJIT.h:
• yarr/YarrParser.h:

(JSC::Yarr::Parser::CharacterClassParserDelegate::CharacterClassParserDelegate):
(JSC::Yarr::Parser::CharacterClassParserDelegate::atomPatternCharacter):
(JSC::Yarr::Parser::CharacterClassParserDelegate::atomBuiltInCharacterClass):
(JSC::Yarr::Parser::CharacterClassParserDelegate::end):

• yarr/YarrPattern.cpp:

(JSC::Yarr::YarrPatternConstructor::atomParenthesesSubpatternBegin):
(JSC::Yarr::YarrPatternConstructor::atomParentheticalAssertionBegin):
(JSC::Yarr::YarrPatternConstructor::atomBackReference):
(JSC::Yarr::YarrPatternConstructor::copyTerm):
(JSC::Yarr::YarrPatternConstructor::quantifyAtom):
(JSC::Yarr::YarrPatternConstructor::checkForTerminalParentheses):
(JSC::Yarr::YarrPatternConstructor::containsCapturingTerms):
(JSC::Yarr::YarrPatternConstructor::optimizeDotStarWrappedExpressions):
(JSC::Yarr::PatternTerm::dumpQuantifier):
(JSC::Yarr::PatternTerm::dump):

• yarr/YarrPattern.h:

(JSC::Yarr::PatternTerm::PatternTerm):
(JSC::Yarr::PatternTerm::ForwardReference):
(JSC::Yarr::PatternTerm::BOL):
(JSC::Yarr::PatternTerm::EOL):
(JSC::Yarr::PatternTerm::WordBoundary):
(JSC::Yarr::PatternTerm::isFixedWidthCharacterClass const):
(JSC::Yarr::PatternTerm::containsAnyCaptures):
(JSC::Yarr::PatternTerm::quantify):

1:23 AM Changeset in webkit [280284] by Devin Rousso

• 8 edits
  2 copies
  4 adds in trunk

[Apple Pay] Do not add coupon code ApplePayErrorCode values for systems that do not support it
​https://bugs.webkit.org/show_bug.cgi?id=228243

Reviewed by Wenson Hsieh.

Source/WebCore:

Test: http/tests/ssl/applepay/ApplePayError.html

• Modules/applepay/ApplePayErrorCode.idl:
• Modules/applepay/ApplePayErrorCode.h:

Source/WebKit:

• Platform/cocoa/PaymentAuthorizationPresenter.mm:

(WebKit::toPKPaymentErrorCode):

LayoutTests:

• http/tests/ssl/applepay/ApplePayError.html:
• http/tests/ssl/applepay/ApplePayError-expected.txt:
• platform/ios-14-wk2/http/tests/ssl/applepay/ApplePayError-expected.txt: Added.
• platform/mac-bigsur-wk2/http/tests/ssl/applepay/ApplePayError-expected.txt: Added.

1:20 AM Changeset in webkit [280283] by Devin Rousso

• 4 edits in trunk

[iOS] REGRESSION(r277505): -[WKWebView underPageBackgroundColor] also changes the scroll bar color
​https://bugs.webkit.org/show_bug.cgi?id=228259
<rdar://problem/80116822>

Reviewed by Tim Horton.

Source/WebKit:

If an application overrides the -underPageBackgroundColor with a dark color on a page that
has a light background color, the scroll bar will appear light to match the overridden value
of -underPageBackgroundColor instead of dark to match the page's background color.

Test: WKWebViewUnderPageBackgroundColor.MatchesScrollView

• UIProcess/API/ios/WKWebViewIOS.mm:

(baseScrollViewBackgroundColor):
(scrollViewBackgroundColor):
(-[WKWebView _updateScrollViewBackground]):
Add a flag to indicate whether the underPageBackgroundColor (which can be overridden by
API) or pageExtendedBackgroundColor should be used when calculating the value provided to
-[UIScrollView setBackgroundColor:] and -[UIScrollView setIndicatorStyle:]. The former
uses the underPageBackgroundColor since that is why that API exists and the latter uses
the pageExtendedBackgroundColor` since it is based on what is shown in the page, which is
what the scroll bar is drawn on top of.

Tools:

• TestWebKitAPI/Tests/WebKitCocoa/WKWebViewUnderPageBackgroundColor.mm:

(TEST.WKWebViewUnderPageBackgroundColor.MatchesScrollView):