Timeline



Jan 2, 2021:

11:18 PM Changeset in webkit [271124] by commit-queue@webkit.org
  • 14 edits in trunk/Source

Remove some FrameLoader::changeLocation parameters
​https://bugs.webkit.org/show_bug.cgi?id=220186

Patch by Rob Buis <​rbuis@igalia.com> on 2021-01-02
Reviewed by Darin Adler.

Source/WebCore:

In all cases changeLocation is called with the default
values for LockHistory and LockBackForwardList, so we
do not need to have these parameters.

  • html/HTMLAnchorElement.cpp:

(WebCore::HTMLAnchorElement::handleClick):

  • html/HTMLLinkElement.cpp:

(WebCore::HTMLLinkElement::handleClick):

  • loader/FrameLoader.cpp:

(WebCore::FrameLoader::changeLocation):

  • loader/FrameLoader.h:
  • loader/NavigationScheduler.cpp:
  • mathml/MathMLElement.cpp:

(WebCore::MathMLElement::defaultEventHandler):

  • svg/SVGAElement.cpp:

(WebCore::SVGAElement::defaultEventHandler):

Source/WebKit:

Adapt to API change.

  • WebProcess/Plugins/PDF/PDFPlugin.mm:

(WebKit::PDFPlugin::clickedLink):

  • WebProcess/WebCoreSupport/WebContextMenuClient.cpp:

(WebKit::WebContextMenuClient::searchWithGoogle):

  • WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::navigateToPDFLinkWithSimulatedClick):

Source/WebKitLegacy/win:

Adapt to API change.

  • WebCoreSupport/WebContextMenuClient.cpp:

(WebContextMenuClient::searchWithGoogle):

5:56 PM Changeset in webkit [271123] by Simon Fraser
  • 11 edits in trunk/Source/WebCore

[LFC Display] Rename Box::Flags to Box::TypeFlags
​https://bugs.webkit.org/show_bug.cgi?id=220223

Reviewed by Sam Weinig.

I'll be adding a separate OptionSet<> of flags that can change dynamically
on a Display::Box, so rename the existing flags to TypeFlags, and make the member
const. They will never change after construction.

  • display/css/DisplayBox.cpp:

(WebCore::Display::Box::Box):

  • display/css/DisplayBox.h:

(WebCore::Display::Box::Box):
(WebCore::Display::Box::isBoxModelBox const):
(WebCore::Display::Box::isContainerBox const):
(WebCore::Display::Box::isImageBox const):
(WebCore::Display::Box::isReplacedBox const):
(WebCore::Display::Box::isTextBox const):
(WebCore::Display::Box::isLineBreakBox const):

  • display/css/DisplayBoxFactory.cpp:

(WebCore::Display::BoxFactory::displayBoxForLayoutBox const):

  • display/css/DisplayBoxModelBox.cpp:

(WebCore::Display::BoxModelBox::BoxModelBox):

  • display/css/DisplayBoxModelBox.h:

(WebCore::Display::BoxModelBox::BoxModelBox):

  • display/css/DisplayContainerBox.cpp:

(WebCore::Display::ContainerBox::ContainerBox):

  • display/css/DisplayImageBox.cpp:

(WebCore::Display::ImageBox::ImageBox):

  • display/css/DisplayReplacedBox.cpp:

(WebCore::Display::ReplacedBox::ReplacedBox):

  • display/css/DisplayReplacedBox.h:
  • display/css/DisplayTextBox.cpp:

(WebCore::Display::TextBox::TextBox):

1:11 PM Changeset in webkit [271122] by Fujii Hironori
  • 2 edits in trunk/Source/WebKitLegacy/win

[Win][DumpRenderTree] Some JS tests are timing out only in Debug builds since r269157
​https://bugs.webkit.org/show_bug.cgi?id=220145
<rdar://problem/72756207>

Reviewed by Sam Weinig.

r269157 added new WebKit1 APIs to set a preference, and
DumpRenderTree uses them to reset all preferences after each
testing. However, it was too slow for large pages because the API
is causing resolveStyle for every preference. Some JS tests failed
as timeout in debug builds because they are generating large
pages.

  • WebPreferences.cpp:

(stringValueForPreferencesValue): Added.
(WebPreferences::setBoolPreferenceForTesting):
(WebPreferences::setUInt32PreferenceForTesting):
(WebPreferences::setDoublePreferenceForTesting):
(WebPreferences::setStringPreferenceForTesting):
Do nothing if the new preference value is same with the current
value.

12:46 PM Changeset in webkit [271121] by ysuzuki@apple.com
  • 4 edits
    1 add in trunk

[JSC] Remove unnecessary mov bytecodes when performing simple object pattern destructuring to variables
​https://bugs.webkit.org/show_bug.cgi?id=220219

Reviewed by Alexey Shvayka.

JSTests:

  • stress/object-pattern-simple-fast-path.js: Added.

(shouldBe):
(shouldThrow):
(test1):

Source/JavaScriptCore:

Currently, we are first puts object pattern's expression into temporary variable, and then, we store it into local variable register.

The following code

({ data } = object);

emits this kind of bytecode.

get_by_id dst:loc10, base:loc9, property:0
mov dst:loc6, src:loc10

However, this should be

get_by_id dst:loc6, base:loc9, property:0

We are emitting many unnecessary movs since this destructuring pattern is common. Increasing amount of mov (1) discourages inlining unnecessarily and (2) simply makes
bytecode memory large. Since this is very common pattern, we should carefully optimize it to remove such unnecessary movs.

This patch looks into pattern when performing object pattern destructuring. And avoid emitting mov when it is possible. There are some cases we cannot remove movs, so
this patch's writableDirectBindingIfPossible looks into whether this is possible (& profitable).

  • bytecompiler/NodesCodegen.cpp:

(JSC::ObjectPatternNode::bindValue const):
(JSC::BindingNode::writableDirectBindingIfPossible const):
(JSC::BindingNode::finishDirectBindingAssignment const):
(JSC::AssignmentElementNode::writableDirectBindingIfPossible const):
(JSC::AssignmentElementNode::finishDirectBindingAssignment const):

  • parser/Nodes.h:

(JSC::DestructuringPatternNode::writableDirectBindingIfPossible const):
(JSC::DestructuringPatternNode::finishDirectBindingAssignment const):

11:27 AM Changeset in webkit [271120] by Alexey Shvayka
  • 21 edits in trunk

Improve error message for uninitialized |this| in derived constructor
​https://bugs.webkit.org/show_bug.cgi?id=220221

Reviewed by Yusuke Suzuki.

JSTests:

  • stress/async-arrow-functions-lexical-binding-in-class.js:
  • stress/async-arrow-functions-lexical-super-binding.js:
  • stress/class-derived-from-null.js:
  • stress/generator-eval-this.js:
  • stress/super-property-access-tdz.js:

LayoutTests/imported/w3c:

  • web-platform-tests/custom-elements/parser/parser-fallsback-to-unknown-element-expected.txt:

Source/JavaScriptCore:

Since class constructors perform return this; by default, and derived
constructors require super() to be called before |this| access, regular
TDZ error message is quite confusing, given the following code:

new (class extends Object { constructor() { } });

Considering that currently op_check_tdz is called on thisRegister() only
in derived constructors, this patch modifies its slow path to throw a
helpful error message that covers |this| access and non-object returns.

V8 and SpiderMonkey have similar error messages, mentioning super().

slow_path_throw_tdz_error is merged into slow_path_check_tdz, which is
invoked from baseline JIT, so we can reliably acquire the bytecode and
avoid code duplication.

  • llint/LowLevelInterpreter32_64.asm:
  • llint/LowLevelInterpreter64.asm:
  • runtime/CommonSlowPaths.cpp:

(JSC::JSC_DEFINE_COMMON_SLOW_PATH):

  • runtime/CommonSlowPaths.h:

LayoutTests:

  • js/arrowfunction-supercall-expected.txt:
  • js/arrowfunction-superproperty-expected.txt:
  • js/class-syntax-extends-expected.txt:
  • js/class-syntax-super-expected.txt:
  • js/script-tests/arrowfunction-supercall.js:
  • js/script-tests/arrowfunction-superproperty.js:
  • js/script-tests/class-syntax-super.js:
10:41 AM Changeset in webkit [271119] by Alexey Shvayka
  • 9 edits
    1 add
    5 deletes in trunk

Don't throw if function.caller is a non-strict / generator / async function
​https://bugs.webkit.org/show_bug.cgi?id=220216

Reviewed by Yusuke Suzuki.

JSTests:

  • stress/function-caller-async-arrow-function-body.js: Removed.
  • stress/function-caller-async-function-body.js: Removed.
  • stress/function-caller-async-generator-body.js: Removed.
  • stress/function-caller-generator-body.js: Removed.
  • stress/function-caller-generator-method-body.js: Removed.
  • stress/function-hidden-as-caller.js: Added.
  • stress/polymorphic-access-exception-handler-should-not-clobber-used-register.js:
  • stress/tail-call-recognize.js:
  • test262/expectations.yaml: Mark 45 test cases as passing.

Source/JavaScriptCore:

The spec forbids [1] ES6+ and strict mode functions from having their own "caller"
property. r230662 went even further, throwing TypeError if function.caller attempts
to return non-strict / generator / async function, which doesn't contradict ECMA-262,
but diverges from V8 and SpiderMonkey (they just return the caller).

Since throwing TypeError causes quite a lot test262 failures and is a bit dangerous
(legacy library which uses function.caller is called from ES6 code), this patch
replaces it with null return.

Given that r230662 appears to be web-compatible, this change preserves its intent
to limit function.caller API as much as possible by returning null for all ES6+
functions, including methods, accessors, and arrow functions.

[1]: ​https://tc39.es/ecma262/#sec-forbidden-extensions (paragraphs 1-2)

  • runtime/JSFunction.cpp:

(JSC::JSC_DEFINE_CUSTOM_GETTER):

LayoutTests:

  • js/caller-property-expected.txt:
  • js/script-tests/caller-property.js:
12:09 AM Changeset in webkit [271118] by James Darpinian
  • 3 edits in trunk/Source/ThirdParty/ANGLE

Enable some ANGLE workarounds on iOS
​https://bugs.webkit.org/show_bug.cgi?id=220203

Reviewed by Kenneth Russell.

Running ANGLE's unit tests on iOS upstream exposed the need to enable a couple of existing
workaround flags. ​https://crrev.com/c/2601106 and ​https://crrev.com/c/2606657 are the
upstream changes corresponding to these fixes.

  • src/libANGLE/renderer/gl/FramebufferGL.cpp:

(rx::FramebufferGL::blit):

  • src/libANGLE/renderer/gl/renderergl_utils.cpp:

(rx::nativegl_gl::InitializeFeatures):

Dec 31, 2020:

7:38 PM Changeset in webkit [271117] by Alexey Shvayka
  • 3 edits
    1 add in trunk

JSFunction::deleteProperty() fails to delete a non-existent "prototype" property
​https://bugs.webkit.org/show_bug.cgi?id=220211

Reviewed by Yusuke Suzuki.

JSTests:

  • stress/function-delete-prototype.js: Added.

Source/JavaScriptCore:

This patch replaces arrow function check with hasPrototypeProperty() since there
are more functions without a "prototype" (accessors, methods, async functions),
aligning JSC with the spec, V8, and SpiderMonkey.

hasPrototypeProperty() is already used by JSFunction::getOwnPropertySlot().

  • runtime/JSFunction.cpp:

(JSC::JSFunction::deleteProperty):

8:29 AM Changeset in webkit [271116] by Alan Bujtas
  • 2 edits in trunk/Source/WebCore

[LFC][IFC] Horizontal padding/border makes the inline box non-empty
​https://bugs.webkit.org/show_bug.cgi?id=220208

Reviewed by Antti Koivisto.

<span style="padding-left: 1px"></span> makes this inline box non-empty and it stretches the line box.
(note that horizontal margin does not make the inline box non-empty)
(fast/inline/inline-padding-disables-text-quirk.html)

  • layout/inlineformatting/InlineFormattingContextGeometry.cpp:

(WebCore::Layout::LineBoxBuilder::constructInlineLevelBoxes):

Dec 30, 2020:

7:27 PM Changeset in webkit [271115] by ysuzuki@apple.com
  • 8 edits in trunk

[JSC] WebAssembly Table/Memory/Global should allow inheritance
​https://bugs.webkit.org/show_bug.cgi?id=220207

Reviewed by Alexey Shvayka.

LayoutTests/imported/w3c:

  • web-platform-tests/wasm/jsapi/proto-from-ctor-realm-expected.txt:
  • web-platform-tests/wasm/jsapi/prototypes.any-expected.txt:
  • web-platform-tests/wasm/jsapi/prototypes.any.worker-expected.txt:

Source/JavaScriptCore:

WebAssembly.{Table,Memory,Global} should accept inheritance by JS class syntax.
We need to create structure from new.target value.

  • wasm/js/WebAssemblyGlobalConstructor.cpp:

(JSC::JSC_DEFINE_HOST_FUNCTION):

  • wasm/js/WebAssemblyMemoryConstructor.cpp:

(JSC::JSC_DEFINE_HOST_FUNCTION):

  • wasm/js/WebAssemblyTableConstructor.cpp:

(JSC::JSC_DEFINE_HOST_FUNCTION):

7:20 PM Changeset in webkit [271114] by ysuzuki@apple.com
  • 3 edits
    1 add in trunk

Unreviewed, fix iteration count check
​https://bugs.webkit.org/show_bug.cgi?id=220206

JSTests:

  • wasm/stress/multivalue-iteration-count.js: Added.

(async let):

Source/JavaScriptCore:

We should have iterationCount variable to track iteration count since it can be larger than MarkedArgumentBuffer's size.

  • wasm/WasmOperations.cpp:

(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):

6:49 PM Changeset in webkit [271113] by ysuzuki@apple.com
  • 5 edits in trunk

[JSC] Wasm multivalue should iterate iterable result from JS function first before converting values
​https://bugs.webkit.org/show_bug.cgi?id=220206

Reviewed by Alexey Shvayka.

LayoutTests/imported/w3c:

  • web-platform-tests/wasm/jsapi/constructor/multi-value.any-expected.txt:
  • web-platform-tests/wasm/jsapi/constructor/multi-value.any.worker-expected.txt:

Source/JavaScriptCore:

When converting JS results to Wasm multivalue (result from JS when executing Wasm->JS calls), we should first iterate all results from iterable.
And then, we should convert each element into Wasm value. Currently, we are converting while iterating, this is not aligned to the spec.

  • wasm/WasmOperations.cpp:

(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):

4:04 PM Changeset in webkit [271112] by ysuzuki@apple.com
  • 17 edits
    1 add in trunk

[JSC] Update WebAssembly instance's exports object
​https://bugs.webkit.org/show_bug.cgi?id=220189

Reviewed by Alexey Shvayka.

JSTests:

  • stress/sampling-profiler-wasm-name-section.js:

(platformSupportsSamplingProfiler.vm.isWasmSupported):

  • stress/sampling-profiler-wasm.js:

(platformSupportsSamplingProfiler.vm.isWasmSupported):

  • wasm/js-api/test_basic_api.js:

(const.c.in.constructorProperties.switch):

  • wasm/stress/exports-object.js: Added.

(async try):
(catch):

LayoutTests/imported/w3c:

  • web-platform-tests/wasm/jsapi/constructor/instantiate.any-expected.txt:
  • web-platform-tests/wasm/jsapi/constructor/instantiate.any.worker-expected.txt:
  • web-platform-tests/wasm/jsapi/instance/constructor.any-expected.txt:
  • web-platform-tests/wasm/jsapi/instance/constructor.any.worker-expected.txt:
  • web-platform-tests/wasm/jsapi/table/grow-reftypes.tentative.any-expected.txt:

Source/JavaScriptCore:

This patch aligns the WebAssembly Instance's exports object to the updated spec.

  1. exports object is a plain object which Prototype is null[1]. We were using module namespace object. Also, the object should be frozen.
  2. exported functions' name should be index, according to the spec[2].

[1]: ​https://webassembly.github.io/spec/js-api/index.html#create-an-exports-object
[2]: ​https://webassembly.github.io/spec/js-api/index.html#exported-function-exotic-objects

  • wasm/js/JSWebAssembly.cpp:

(JSC::resolve):

  • wasm/js/JSWebAssemblyInstance.cpp:

(JSC::JSWebAssemblyInstance::finishCreation):
(JSC::JSWebAssemblyInstance::visitChildren):
(JSC::JSWebAssemblyInstance::finalizeCreation):
(JSC::JSWebAssemblyInstance::tryCreate):

  • wasm/js/JSWebAssemblyInstance.h:
  • wasm/js/WebAssemblyInstancePrototype.cpp:

(JSC::JSC_DEFINE_HOST_FUNCTION):

  • wasm/js/WebAssemblyModuleRecord.cpp:

(JSC::WebAssemblyModuleRecord::visitChildren):
(JSC::WebAssemblyModuleRecord::link):

  • wasm/js/WebAssemblyModuleRecord.h:
3:01 PM Changeset in webkit [271111] by Nikolas Zimmermann
  • 4 edits
    2 adds in trunk/Source/WebCore

Introduce RenderLayerScrollableArea
​https://bugs.webkit.org/show_bug.cgi?id=219808

Reviewed by Simon Fraser.

Overhaul RenderLayer:
The goal is to move all overflow/scroll/... handling
out of RenderLayer, to streamline its interface and
make it re-usable for layer types that do not need
nor support scrolling/overflow.

This patch introduces RenderLayerScrollableArea inheriting
from ScrollableArea, with a back-reference to RenderLayer --
that mimics the design of RenderLayerFilters.

Follow-up patches will land the actual implementation, this
only adds a stub and adds it to the build systems.

No functional change - no new tests needed.

  • Headers.cmake: Add RenderLayerScrollableArea.* to build.
  • Sources.txt: Ditto.
  • WebCore.xcodeproj/project.pbxproj: Ditto.
  • rendering/RenderLayerScrollableArea.cpp: Added.

(WebCore::RenderLayerScrollableArea::RenderLayerScrollableArea):
(WebCore::RenderLayerScrollableArea::~RenderLayerScrollableArea):
(WebCore::RenderLayerScrollableArea::shouldPlaceBlockDirectionScrollbarOnLeft const):

  • rendering/RenderLayerScrollableArea.h: Added.
2:31 PM Changeset in webkit [271110] by Alan Bujtas
  • 23 edits in trunk

[Legacy Line Layout] Remove unnecessary 'vertical-align: middle' integral rounding
​https://bugs.webkit.org/show_bug.cgi?id=220198

Reviewed by Antti Koivisto.

Source/WebCore:

Let's not do "random" rounding for 'vertical-align: middle'. Fix it for all the alignment types by
adjusting the logical top position when the inline box stretches the line.

  • rendering/InlineFlowBox.cpp:

(WebCore::InlineFlowBox::computeLogicalBoxHeights):

  • rendering/RootInlineBox.cpp:

(WebCore::RootInlineBox::verticalPositionForBox):

LayoutTests:

Added additional 'vertical-align' values.

  • fast/sub-pixel/vertical-align-middle-overflow.html:
1:30 PM Changeset in webkit [271109] by Simon Fraser
  • 4 edits
    3 adds in trunk

[LFC Display] Stacking item bounds were wrong in some cases
​https://bugs.webkit.org/show_bug.cgi?id=220201

Reviewed by Zalan Bujtas.

Source/WebCore:

Display::StackingItem were computed incorrectly for some content configurations,
such as:

  • inline non-container box
  • inline container box with no children
  • positioned inline non-container box
  • positioned inline container box with no children
  • positioned block non-container box

Fix by ensuring that when we create a StackingItem for a box with no children
to descend into, we run the same geometry logic that happens for
pushStateForBoxDescendants()/popState(). Also ensure that we call
accountForBoxPaintingExtent() for leaf boxes without a stacking item.

Test: fast/layoutformattingcontext/display/stacking-item-bounds.html

  • display/DisplayTreeBuilder.cpp:

(WebCore::Display::TreeBuilder::popState):
(WebCore::Display::TreeBuilder::didAppendNonContainerStackingItem):
(WebCore::Display::TreeBuilder::insertIntoTree):
(WebCore::Display::TreeBuilder::buildInlineDisplayTree):
(WebCore::Display::TreeBuilder::recursiveBuildDisplayTree):

  • display/DisplayTreeBuilder.h:

LayoutTests:

  • fast/layoutformattingcontext/display/stacking-item-bounds-expected.html: Added.
  • fast/layoutformattingcontext/display/stacking-item-bounds.html: Added.

Dec 29, 2020:

10:57 PM Changeset in webkit [271108] by Simon Fraser
  • 14 edits in trunk/Source/WebCore

[LFC Display] Clean up display tree dumping
​https://bugs.webkit.org/show_bug.cgi?id=220195

Reviewed by Daniel Bates.

Reduce redundant code in debugDescription() functions by having boxes
report their box type.

Improve the formatting of the tree dump.

  • display/DisplayTreeBuilder.cpp:

(WebCore::Display::outputStackingTree):
(WebCore::Display::displayTreeAsText):

  • display/css/DisplayBox.cpp:

(WebCore::Display::Box::boxName const):
(WebCore::Display::Box::debugDescription const):

  • display/css/DisplayBox.h:
  • display/css/DisplayBoxModelBox.cpp:

(WebCore::Display::BoxModelBox::boxName const):
(WebCore::Display::BoxModelBox::debugDescription const):

  • display/css/DisplayBoxModelBox.h:
  • display/css/DisplayContainerBox.cpp:

(WebCore::Display::ContainerBox::boxName const):
(WebCore::Display::ContainerBox::debugDescription const): Deleted.

  • display/css/DisplayContainerBox.h:
  • display/css/DisplayImageBox.cpp:

(WebCore::Display::ImageBox::boxName const):
(WebCore::Display::ImageBox::debugDescription const):

  • display/css/DisplayImageBox.h:
  • display/css/DisplayReplacedBox.cpp:

(WebCore::Display::ReplacedBox::boxName const):

  • display/css/DisplayReplacedBox.h:
  • display/css/DisplayTextBox.cpp:

(WebCore::Display::TextBox::boxName const):
(WebCore::Display::TextBox::debugDescription const):

  • display/css/DisplayTextBox.h:
3:18 PM Changeset in webkit [271107] by ysuzuki@apple.com
  • 2 edits in trunk/Source/WebCore

Fix compile error in non libressl WinCairo
​https://bugs.webkit.org/show_bug.cgi?id=220191

Reviewed by Don Olmstead.

  • platform/network/curl/CurlSSLVerifier.cpp:

(WebCore::CurlSSLVerifier::CurlSSLVerifier):

10:08 AM Changeset in webkit [271106] by Alan Bujtas
  • 2 edits in trunk/Source/WebCore

[LFC][IFC] Incorrectly positioned content with vertical-align: length/percentage
​https://bugs.webkit.org/show_bug.cgi?id=220193

Reviewed by Antti Koivisto.

vertical-align: length/percentage is a baseline shift. Let's use the inline level box's baseline and not its height
when adjusting the vertical position (css1/text_properties/vertical_align.html).

  • layout/inlineformatting/InlineFormattingContextGeometry.cpp:

(WebCore::Layout::LineBoxBuilder::computeLineBoxHeightAndAlignInlineLevelBoxesVertically):

Note: See TracTimeline for information about the timeline view.