Timeline



Jan 3, 2021:

11:25 AM Changeset in webkit [271127] by commit-queue@webkit.org
  • 9 edits in trunk

Use UTF-8 encoding for empty main resource loads
https://bugs.webkit.org/show_bug.cgi?id=220227

Patch by Rob Buis <rbuis@igalia.com> on 2021-01-03
Reviewed by Sam Weinig.

LayoutTests/imported/w3c:

Update improved test results.

  • web-platform-tests/html/browsers/the-window-object/apis-for-creating-and-navigating-browsing-contexts-by-name/creating_browsing_context_test_01-expected.txt:
  • web-platform-tests/html/browsers/windows/browsing-context-expected.txt:

Source/WebCore:

Unless specified otherwise, documents have UTF-8 encoding [1]. Since [2]
does not mention encoding, use UTF-8 encoding explicitly for empty main
loads.

[1] https://dom.spec.whatwg.org/#concept-document-type
[2] https://html.spec.whatwg.org/#initialise-the-document-object (Step 7)

Tests: imported/w3c/web-platform-tests/html/browsers/the-window-object/apis-for-creating-and-navigating-browsing-contexts-by-name/creating_browsing_context_test_01.html

imported/w3c/web-platform-tests/html/browsers/windows/browsing-context.html
http/wpt/html/browsers/windows/browsing-context.html

Behavior matches Chrome and Firefox.

  • loader/DocumentLoader.cpp:

(WebCore::DocumentLoader::maybeLoadEmpty):

LayoutTests:

Update improved test results.

  • http/wpt/html/browsers/windows/browsing-context-expected.txt:
  • platform/mac/webarchive/archive-empty-frame-source-expected.png:
  • webarchive/archive-empty-frame-source-expected.webarchive:
10:43 AM Changeset in webkit [271126] by Beth Dakin
  • 4 edits in trunk/PerformanceTests

Remove non-inclusive language from JetStream 2.0
https://bugs.webkit.org/show_bug.cgi?id=220109

Reviewed by Anders Carlsson.

  • JetStream2/code-load/inspector-payload.js:

(WebInspector.DOMNode.WebInspector.Resource.WebInspector.ConsoleMessageView.prototype._formatWithSubstitutionString.styleFormatter):
(WebInspector.DOMNode.WebInspector.Resource.WebInspector.ConsoleMessageView.prototype._formatWithSubstitutionString.isAllowlistedProperty):
(WebInspector.DOMNode.WebInspector.Resource.WebInspector.ConsoleMessageView.prototype._formatWithSubstitutionString.isWhitelistedProperty): Deleted.

  • JetStream2/web-tooling-benchmark/cli.js:
5:47 AM Changeset in webkit [271125] by commit-queue@webkit.org
  • 4 edits in trunk/Source/WebCore

Share meta refresh logic
https://bugs.webkit.org/show_bug.cgi?id=220179

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

Share meta refresh logic between Document and FrameLoader.

  • dom/Document.cpp:

(WebCore::Document::processHttpEquiv):

  • loader/FrameLoader.cpp:

(WebCore::FrameLoader::receivedFirstData):
(WebCore::FrameLoader::scheduleRefreshIfNeeded):

  • loader/FrameLoader.h:

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.
Note: See TracTimeline for information about the timeline view.