Timeline
Jan 15, 2017:
- 4:14 PM Changeset in webkit [210784] by
-
- 2 edits in trunk/Websites/perf.webkit.org
Add the build fix for browsers that don't yet support custom elements SPI.
It was supposedly to be a part of the previous commit.
- public/v3/components/base.js:
(ComponentBase.defineElement):
- 4:12 PM Changeset in webkit [210783] by
-
- 8 edits3 adds in trunk/Websites/perf.webkit.org
Adopt custom elements API in perf dashboard
https://bugs.webkit.org/show_bug.cgi?id=167045
Reviewed by Darin Adler.
Adopt custom elements API in ComponentBase, and create the shadow tree lazily in content() and render()
instead of eagerly creating it inside the constructor.
For now, create a separate element class for each component in ComponentBase.defineElement instead of
making ComponentBase inherit from HTMLElement to preserve the semantics we have as well as to test
the boundaries of what custom elements API allows for framework authors.
In order to ensure one-to-one correspondence between elements and their components, we use a static map,
ComponentBase._currentlyConstructedByInterface, to remember which element or component is being created
and use that in custom element's constructor to update element.component() and this._element.
Also dropped the support for not having attachShadow as we've shipped this feature in Safari 10.
Finally, added tests to be ran inside a browser to test the front end code in browser-tests.
- browser-tests/component-base-tests.js: Added. Basic tests for ComponentBase.
- browser-tests/index.html: Added.
- public/v3/components/base.js:
(ComponentBase): Don't create the shadow tree. Use the currently constructed element as this._element if
there is one (the custom element's constructor is getting called). Otherwise create a new element but
store this component in the map to avoid creating a new component in the custom element's constructor.
(ComponentBase.prototype.content): Lazily create the shadow tree now.
(ComponentBase.prototype.render): Ditto.
(ComponentBase.prototype._ensureShadowTree): Renamed from _constructShadowTree. Dropped the support for
not having shadow DOM API. This is now required. Also use importNode instead of cloneNode in cloning
the template content since the latter would not get upgraded.
(ComponentBase.prototype._recursivelyReplaceUnknownElementsByComponents): Modernized the code. Don't
re-create a component if its element had already been upgraded by its custom element constructor.
(ComponentBase.defineElement): Add this component to the static maps. _componentByName is used by
_recursivelyReplaceUnknownElementsByComponents to instantiate new components in the browsers that don't
support custom elements API and _componentByClass is used by ComponentBase's constructor to lookup the
element name. The latter should go away once all components fully adopt ComponentBase.defineElement.
(ComponentBase.defineElement.elementClass): A class to define a custom element for the component.
We need to reconfigure the property since class's name is not writable but configurable.
- public/v3/components/button-base.js:
(ButtonBase.htmlTemplate): Added. Extracted the common code from CloseButton and WarningIcon.
(ButtonBase.buttonContent): Added. An abstract method overridden by CloseButton and WarningIcon.
(ButtonBase.sizeFactor): Added. Overridden by WarningIcon.
(ButtonBase.cssTemplate): Updated to use :host.
- public/v3/components/close-button.js:
(CloseButton.buttonContent): Renamed from htmlTemplate.
- public/v3/components/spinner-icon.js:
(SpinnerIcon.cssTemplate): Removed webkit prefixed properties, and updated it to animate stroke instead
of opacity to reduce the power usage.
(SpinnerIcon.htmlTemplate): Factored stroke, stroke-width, and stroke-linecap into cssTemplate.
- public/v3/components/warning-icon.js:
(WarningIcon.cssTemplate): Deleted.
(WarningIcon.sizeFactor): Added.
(WarningIcon.buttonContent): Renamed from htmlTemplate.
- public/v3/pages/summary-page.js:
(SummaryPage._constructRatioGraph): Fixed a bug that we were not never calling spinner.updateRendering().
(SummaryPage.prototype._renderCell):
- 3:02 PM WebInspectorCodingStyleGuide edited by
- (diff)
- 2:42 PM Changeset in webkit [210782] by
-
- 2 edits in trunk/Tools
Unreviewed, remove stale comment.
This test was fixed by r163173.
- TestWebKitAPI/Tests/WebKit2/PageLoadBasic.cpp:
- 1:01 PM Changeset in webkit [210781] by
-
- 2 edits in trunk/Source/WebCore
[SOUP] SoupNetworkSession constructor should be explicit
https://bugs.webkit.org/show_bug.cgi?id=167069
Reviewed by Darin Adler.
- platform/network/soup/SoupNetworkSession.h:
- 12:05 PM Changeset in webkit [210780] by
-
- 23 edits3 deletes in trunk
[WebIDL] Remove custom bindings for HTMLInputElement, HTMLFrameElement, HTMLMediaElement and HTMLOptionsCollection
https://bugs.webkit.org/show_bug.cgi?id=167039
Patch by Sam Weinig <sam@webkit.org> on 2017-01-15
Reviewed by Darin Adler.
Source/WebCore:
- CMakeLists.txt:
- WebCore.xcodeproj/project.pbxproj:
- bindings/js/JSBindingsAllInOne.cpp:
- bindings/js/JSHTMLFrameElementCustom.cpp: Removed.
- bindings/js/JSHTMLInputElementCustom.cpp: Removed.
- bindings/js/JSHTMLMediaElementCustom.cpp: Removed.
Remove files.
- html/HTMLOptionsCollection.idl:
- bindings/js/JSHTMLOptionsCollectionCustom.cpp:
(WebCore::JSHTMLOptionsCollection::setLength): Deleted.
Remove custom setLength. The bindings generator can handle this now.
- html/HTMLFrameElement.idl:
Resort to match spec. Replace custom annotation for location with SetterCallWith=ScriptState.
- html/HTMLFrameElementBase.cpp:
(WebCore::HTMLFrameElementBase::setLocation):
- html/HTMLFrameElementBase.h:
Add implementation of setLocation.
- html/HTMLInputElement.cpp:
(WebCore::HTMLInputElement::selectionStartForBindings):
(WebCore::HTMLInputElement::setSelectionStartForBindings):
(WebCore::HTMLInputElement::selectionEndForBindings):
(WebCore::HTMLInputElement::setSelectionEndForBindings):
(WebCore::HTMLInputElement::selectionDirectionForBindings):
(WebCore::HTMLInputElement::setSelectionDirectionForBindings):
(WebCore::HTMLInputElement::setSelectionRangeForBindings):
- html/HTMLInputElement.h:
- html/HTMLInputElement.idl:
Add variants of the selection properties that throw using the 'forBindings' suffix to differentiate.
- html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::setControllerForBindings):
- html/HTMLMediaElement.h:
(WebCore::HTMLMediaElement::controllerForBindings):
- html/HTMLMediaElement.idl:
Add a variant of the controller property that unsets the media group, using the 'forBindings' suffix to differentiate.
- html/HTMLSelectElement.cpp:
(WebCore::HTMLSelectElement::setLength):
Match other implementations by ignoring attempts to set large lengths (> 10000) rather than clamping.
LayoutTests:
- fast/dom/HTMLSelectElement/select-selectedIndex-expected.txt:
- fast/dom/HTMLSelectElement/select-selectedIndex-multiple-expected.txt:
- fast/dom/HTMLSelectElement/select-selectedIndex-multiple.html:
- fast/dom/HTMLSelectElement/select-selectedIndex.html:
Update tests / results now that negative lengths don't throw, but do log due to be converted
to a large number.
- fast/forms/select-max-length-expected.txt:
Update result now that a large length is not clamped, but rather, ignored.
- 11:39 AM Changeset in webkit [210779] by
-
- 8 edits in trunk/Source
De-duplicate more (nearly) identical code in Editor(Mac|IOS).mm
https://bugs.webkit.org/show_bug.cgi?id=167063
Reviewed by Dan Bernstein.
Source/WebCore:
No new tests, just refactoring.
- editing/Editor.h:
Adjust to fontAttributesForSelectionStart returning a RetainPtr.
- editing/cocoa/EditorCocoa.mm:
(WebCore::Editor::getTextDecorationAttributesRespectingTypingStyle):
Make use of more Obj-C literals (for NSNumber).
(WebCore::Editor::fontAttributesForSelectionStart):
Merge this from EditorMac and EditorIOS. There are a number of attributes
that are currently only extracted on Mac, and it's not clear why (and
probably should be shared).
(WebCore::Editor::stringSelectionForPasteboard):
(WebCore::Editor::stringSelectionForPasteboardWithImageAltText):
Merge these functions from EditorMac and EditorIOS. The iOS implementation
was missing a reasonable bug fix from r161925.
(WebCore::Editor::createFragmentAndAddResources):
Merge this from EditorMac and EditorIOS. The Mac implementation was missing
a reasonable bug fix from r203482.
- editing/ios/EditorIOS.mm:
(WebCore::Editor::fontAttributesForSelectionStart): Deleted.
(WebCore::Editor::stringSelectionForPasteboardWithImageAltText): Deleted.
(WebCore::Editor::createFragmentAndAddResources): Deleted.
- editing/mac/EditorMac.mm:
(WebCore::Editor::fontAttributesForSelectionStart): Deleted.
(WebCore::Editor::stringSelectionForPasteboard): Deleted.
(WebCore::Editor::stringSelectionForPasteboardWithImageAltText): Deleted.
(WebCore::Editor::createFragmentAndAddResources): Deleted.
Source/WebKit/mac:
- WebView/WebHTMLView.mm:
(-[WebHTMLView _selectionStartFontAttributesAsRTF]):
(-[WebHTMLView _updateFontPanel]):
- WebView/WebView.mm:
(-[WebView typingAttributes]):
Adjust to fontAttributesForSelectionStart returning a RetainPtr.
- 9:47 AM Changeset in webkit [210778] by
-
- 7 edits in trunk/Source/WebCore
[Cocoa] Unify FontPlatformData's hashing and equality operators
https://bugs.webkit.org/show_bug.cgi?id=167061
Reviewed by Darin Adler.
On iOS, we were using CFEqual() and CFHash(), while on macOS
we were using pointer hashing and pointer equality. Instead,
we should be consistent about these operators.
Right now, FontPlatformData holds two internal CTFontRefs, and
switching to these higher-level CFEqual() and CFHash()
functions is required for eliminating one of these two
internal font objects.
No new tests because there is no behavior change.
- platform/graphics/FontPlatformData.h:
(WebCore::FontPlatformData::hash): Deleted.
- platform/graphics/cocoa/FontPlatformDataCocoa.mm:
(WebCore::FontPlatformData::hash):
(WebCore::FontPlatformData::platformIsEqual):
(WebCore::cascadeToLastResortAttributesDictionary):
- platform/graphics/freetype/FontPlatformDataFreeType.cpp:
(WebCore::FontPlatformData::hash):
- platform/graphics/win/FontPlatformDataCGWin.cpp:
(WebCore::FontPlatformData::hash):
- platform/graphics/win/FontPlatformDataCairoWin.cpp:
(WebCore::FontPlatformData::hash):
- platform/graphics/win/FontPlatformDataDirect2D.cpp:
(WebCore::FontPlatformData::hash):
- 2:48 AM Changeset in webkit [210777] by
-
- 7 edits in trunk/Source/WebCore
FrameView shouldn't keep dangling pointers into dead render trees.
<https://webkit.org/b/167011>
Reviewed by Antti Koivisto.
Added some pretty paranoid assertions to FrameView that verify all of its raw pointers
into the render tree are gone after the render tree has been destroyed.
They immediately caught two bugs, also fixed in this patch.
- page/FrameView.h:
- page/FrameView.cpp:
(WebCore::FrameView::willDestroyRenderTree):
(WebCore::FrameView::didDestroyRenderTree): Added these two callbacks for before/after
Document tears down its render tree. The former clears the layout root, and detaches
custom scrollbars. The latter contains a bunch of sanity assertions that pointers into
the now-destroyed render tree are gone.
- dom/Document.cpp:
(WebCore::Document::destroyRenderTree): Notify FrameView before/after teardown.
- page/animation/AnimationController.h:
- page/animation/AnimationController.cpp:
(WebCore::AnimationController::hasAnimations): Added a helper to check if there are
any composite animations around, as these contain raw pointers to renderers.
- rendering/RenderElement.cpp:
(WebCore::RenderElement::willBeRemovedFromTree):
(WebCore::RenderElement::willBeDestroyed): Moved slow repaint object unregistration
from willBeRemovedFromTree() to willBeDestroyed(). The willBeRemovedFromTree() callback
is skipped as an optimization during full tree teardown, but willBeDestroyed() always
gets called. This fixes a bug where we'd fail to remove dangling pointers.
- 12:23 AM Changeset in webkit [210776] by
-
- 5 edits in trunk/Source/WebCore
[Cocoa] Unify font fallback between macOS and iOS for when the font-family list is exhausted
https://bugs.webkit.org/show_bug.cgi?id=167056
Reviewed by Darin Adler.
When performing font fallback, each item in the font-family list is examined.
If no appropriate fonts are found, WebKit asks the system for an appropriate
font. As of a few years ago, both macOS and iOS used platform calls to
produce a font; however, each platform used a different platform call. This
patch migrates both platforms to use a shared function which uses only
one of the platform calls (which means the other platform call is never used).
There are still some behavior differences between macOS and iOS (which are now
hidden behind a PLATFORM() guard), but I'd like to minimize and eliminate these
in the future. Using a shared function is a step toward this goal.
No new tests because there is no behavior change.
- platform/graphics/FontCache.h:
- platform/graphics/cocoa/FontCacheCoreText.cpp:
(WebCore::lookupFallbackFont):
(WebCore::FontCache::systemFallbackForCharacters):
- platform/graphics/ios/FontCacheIOS.mm:
(WebCore::getSystemFontFallbackForCharacters): Deleted.
(WebCore::platformLookupFallbackFont): Deleted.
- platform/graphics/mac/FontCacheMac.mm:
(WebCore::platformLookupFallbackFont): Deleted.
Jan 14, 2017:
- 11:22 PM Changeset in webkit [210775] by
-
- 17 edits in trunk
Annotate large string tests with largeHeap
https://bugs.webkit.org/show_bug.cgi?id=167054
Reviewed by Filip Pizlo.
JSTests:
- microbenchmarks/dense-set.js:
- microbenchmarks/lots-of-fields.js:
- stress/joined-strings-should-not-exceed-max-string-length.js:
- stress/make-large-string-jit-strcat.js:
- stress/make-large-string-jit.js:
- stress/make-large-string-strcat.js:
- stress/make-large-string.js:
- stress/string-joining-long-strings-should-not-crash.js:
- stress/string-prototype-replace-should-throw-out-of-memory-error-when-using-too-much-memory.js:
Tools:
- Scripts/run-javascriptcore-tests:
- Scripts/run-jsc-stress-tests:
LayoutTests:
- js/script-tests/stringimpl-to-jsstring-on-large-strings-1.js:
- js/script-tests/stringimpl-to-jsstring-on-large-strings-2.js:
- js/script-tests/stringimpl-to-jsstring-on-large-strings-3.js:
- 10:59 PM Changeset in webkit [210774] by
-
- 7 edits in trunk/Source/WebCore
Report CPU usage of tabs after they become non-visible using diagnostic logging
https://bugs.webkit.org/show_bug.cgi?id=167019
<rdar://problem/30019773>
Reviewed by Darin Adler.
Report CPU usage of tabs after they become non-visible using diagnostic logging.
We start measure CPU usage 5 seconds after a tab goes to the background, for 5
minutes and report how much CPU the tab used during those 5 minutes. We will
not log if the tab gets closed or moved to the foreground during those 5
minutes.
- page/DiagnosticLoggingKeys.cpp:
(WebCore::DiagnosticLoggingKeys::postPageBackgroundingKey):
- page/DiagnosticLoggingKeys.h:
- page/Page.cpp:
(WebCore::Page::Page):
(WebCore::Page::didStartProvisionalLoad):
(WebCore::Page::didFinishLoad):
(WebCore::foregroundCPUUsageToDiagnosticLogginKey):
(WebCore::Page::measurePostLoadCPUUsage):
(WebCore::backgroundCPUUsageToDiagnosticLogginKey):
(WebCore::Page::measurePostBackgroundingCPUUsage):
(WebCore::Page::setIsVisibleInternal):
- page/Page.h:
- page/Settings.cpp:
(WebCore::Settings::isPostBackgroundingCPUUsageMeasurementEnabled):
- page/Settings.h:
- 10:45 PM Changeset in webkit [210773] by
-
- 7 edits in trunk/Source/WebCore
De-duplicate some (nearly) identical code in Editor(Mac|IOS).mm
https://bugs.webkit.org/show_bug.cgi?id=167062
Reviewed by Dan Bernstein.
No new tests, just refactoring.
- editing/Editor.cpp:
(WebCore::Editor::fontForSelection):
(WebCore::Editor::styleForSelectionStart):
(WebCore::Editor::adjustedSelectionRange):
- editing/Editor.h:
Move these three functions to Editor and unguard them, because they're
not Cocoa specific.
- platform/spi/cocoa/NSAttributedStringSPI.h:
Move some iOS-only NSAttributedString IPI (so no Internal SDK switch)
to NSAttributedStringSPI.h.
- editing/cocoa/EditorCocoa.mm:
(WebCore::Editor::writeSelectionToPasteboard):
(WebCore::Editor::selectionInWebArchiveFormat):
(WebCore::Editor::replaceSelectionWithAttributedString):
(WebCore::Editor::createFragmentForImageResourceAndAddResource):
(WebCore::Editor::dataInRTFDFormat):
(WebCore::Editor::dataInRTFFormat):
Move these six functions here.
selectionInWebArchiveFormat and replaceSelectionWithAttributedString are
entirely identical; writeSelectionToPasteboard and createFragment...
both have slightly suspicious-looking differences that I left intact
and wrote comments about (especially createFragment..., the other one
is somewhat explicable). The two dataInRTF(D)Format functions used to
be static functions, but for now are required from both EditorCocoa
and Editor(Mac|IOS), so we'll make them static member functions.
- editing/ios/EditorIOS.mm:
(WebCore::Editor::fontForSelection): Deleted.
(WebCore::Editor::selectionInWebArchiveFormat): Deleted.
(WebCore::dataInRTFDFormat): Deleted.
(WebCore::dataInRTFFormat): Deleted.
(WebCore::Editor::writeSelectionToPasteboard): Deleted.
(WebCore::Editor::createFragmentForImageResourceAndAddResource): Deleted.
(WebCore::Editor::replaceSelectionWithAttributedString): Deleted.
- editing/mac/EditorMac.mm:
(WebCore::Editor::fontForSelection): Deleted.
(WebCore::Editor::selectionInWebArchiveFormat): Deleted.
(WebCore::dataInRTFDFormat): Deleted.
(WebCore::dataInRTFFormat): Deleted.
(WebCore::Editor::writeSelectionToPasteboard): Deleted.
(WebCore::Editor::createFragmentForImageResourceAndAddResource): Deleted.
(WebCore::Editor::replaceSelectionWithAttributedString): Deleted.
- 10:27 PM Changeset in webkit [210772] by
-
- 2 edits in trunk/Source/WebInspectorUI
Web Inspector: Cmd-, should open Settings tab
https://bugs.webkit.org/show_bug.cgi?id=167028
Patch by Devin Rousso <Devin Rousso> on 2017-01-14
Reviewed by Timothy Hatcher.
- UserInterface/Base/Main.js:
(WebInspector.contentLoaded):
(WebInspector._showSettingsTab): Added.
- 9:06 PM Changeset in webkit [210771] by
-
- 5 edits in trunk
Remove stale references to ENABLE_ES6_GENERATORS and ENABLE_PROMISES
https://bugs.webkit.org/show_bug.cgi?id=167043
Patch by Joseph Pecoraro <Joseph Pecoraro> on 2017-01-14
Reviewed by Darin Adler.
.:
- Source/cmake/tools/vsprops/FeatureDefines.props:
- Source/cmake/tools/vsprops/FeatureDefinesCairo.props:
Tools:
- Scripts/webkitperl/FeatureList.pm:
- 8:44 PM WebKitGTK/2.14.x edited by
- Propose r209821 (diff)
- 8:35 PM WebKitGTK/2.14.x edited by
- Propose bug #165073 (diff)
- 11:59 AM Changeset in webkit [210770] by
-
- 2 edits in trunk/Source/WebCore
Small code cleanup after r210760
https://bugs.webkit.org/show_bug.cgi?id=167047
Reviewed by Sam Weinig.
No change in functionality.
- rendering/RenderLayer.cpp:
(WebCore::RenderLayer::updateLayerPosition):
- 11:35 AM Changeset in webkit [210769] by
-
- 6 edits in trunk/Source
WebAssembly: Suppress warnings & errors in GCC
https://bugs.webkit.org/show_bug.cgi?id=167049
Reviewed by Sam Weinig.
Source/JavaScriptCore:
- wasm/WasmFunctionParser.h:
Add missing { } after the switch. Ideally, it is not necessary.
But in GCC, it is required. Since this function is fairly large,
I think the code generated by this does not cause performance
regression.
- wasm/WasmPageCount.h:
UINT_MAX is defined in limits.h.
- wasm/generateWasmValidateInlinesHeader.py:
On the other hand, we use this suppress pragma here to solve the
same problem in wasm/WasmFunctionParser.h. Since the load function
is fairly small, the additionalreturn { };may generate some
suboptimal code. See bug 150794 for more detail.
Source/WTF:
- wtf/LEBDecoder.h:
(WTF::LEBDecoder::decodeInt):
If T = int, it performs-1 << shift. It causes
warning in GCC. Instead, we first cast it to the
UnsignedT, perform operation and re-cast to the
T.
- 10:45 AM Changeset in webkit [210768] by
-
- 23 edits in trunk/Source/WebCore
Renderers should have a simple way to access Settings.
https://bugs.webkit.org/show_bug.cgi?id=167048
Now that RenderObjects can never outlive the Page, we can just access the Settings
through Page instead of Document::settings/Frame::settings.
Reviewed by Andreas Kling.
No change in functionality.
- rendering/RenderBlock.cpp:
(WebCore::RenderBlock::paintCaret):
(WebCore::RenderBlock::shouldPaintSelectionGaps):
- rendering/RenderBlockFlow.cpp:
(WebCore::needsAppleMailPaginationQuirk):
- rendering/RenderBlockLineLayout.cpp:
(WebCore::RenderBlockFlow::startAlignedOffsetForLine):
- rendering/RenderBox.cpp:
(WebCore::RenderBox::layoutOverflowRectForPropagation):
- rendering/RenderBoxModelObject.cpp:
(WebCore::RenderBoxModelObject::paintFillLayerExtended):
(WebCore::RenderBoxModelObject::calculateBackgroundImageGeometry):
- rendering/RenderElement.cpp:
(WebCore::RenderElement::styleWillChange):
(WebCore::RenderElement::willBeRemovedFromTree):
(WebCore::RenderElement::shouldRespectImageOrientation):
- rendering/RenderEmbeddedObject.cpp:
(WebCore::RenderEmbeddedObject::getReplacementTextGeometry):
- rendering/RenderFrameSet.cpp:
(WebCore::RenderFrameSet::flattenFrameSet):
- rendering/RenderIFrame.cpp:
(WebCore::RenderIFrame::flattenFrame):
- rendering/RenderImage.cpp:
(WebCore::RenderImage::paintIntoRect):
- rendering/RenderInline.cpp:
(WebCore::RenderInline::addChildIgnoringContinuation):
- rendering/RenderLayer.cpp:
(WebCore::RenderLayer::acceleratedCompositingForOverflowScrollEnabled):
(WebCore::RenderLayer::forceUpdateScrollbarsOnMainThreadForPerformanceTesting):
(WebCore::RenderLayer::hasAcceleratedTouchScrolling):
(WebCore::RenderLayer::getRectToExpose):
(WebCore::RenderLayer::overhangAmount):
(WebCore::RenderLayer::setHasHorizontalScrollbar):
(WebCore::RenderLayer::setHasVerticalScrollbar):
(WebCore::RenderLayer::calculateClipRects):
- rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::RenderLayerBacking):
(WebCore::RenderLayerBacking::shouldAggressivelyRetainTiles):
(WebCore::RenderLayerBacking::shouldTemporarilyRetainTileCohorts):
(WebCore::RenderLayerBacking::useGiantTiles):
(WebCore::RenderLayerBacking::startAnimation):
- rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::cacheAcceleratedCompositingFlags):
(WebCore::RenderLayerCompositor::updateBacking):
(WebCore::RenderLayerCompositor::addToOverlapMap):
(WebCore::RenderLayerCompositor::requiresCompositingForPosition):
(WebCore::RenderLayerCompositor::needsFixedRootBackgroundLayer):
(WebCore::RenderLayerCompositor::requiresContentShadowLayer):
(WebCore::RenderLayerCompositor::updateOverflowControlsLayers):
- rendering/RenderLayerModelObject.cpp:
(WebCore::RenderLayerModelObject::shouldPlaceBlockDirectionScrollbarOnLeft):
- rendering/RenderListBox.cpp:
(WebCore::RenderListBox::forceUpdateScrollbarsOnMainThreadForPerformanceTesting):
- rendering/RenderObject.h:
(WebCore::RenderObject::settings):
- rendering/RenderText.cpp:
(WebCore::SecureTextTimer::restart):
- rendering/RenderView.cpp:
(WebCore::RenderView::clientLogicalWidthForFixedPosition):
(WebCore::RenderView::clientLogicalHeightForFixedPosition):
(WebCore::RenderView::paintBoxDecorations):
- rendering/SimpleLineLayout.cpp:
(WebCore::SimpleLineLayout::canUseForWithReason):
- rendering/SimpleLineLayoutFunctions.cpp:
(WebCore::SimpleLineLayout::paintFlow):
- rendering/svg/RenderSVGResourceFilter.cpp:
(WebCore::RenderSVGResourceFilter::applyResource):
- 9:35 AM Changeset in webkit [210767] by
-
- 9 edits2 adds in trunk
Align the innerText setter with the HTML spec and Gecko
https://bugs.webkit.org/show_bug.cgi?id=160971
Reviewed by Alex Christensen.
LayoutTests/imported/w3c:
Rebaseline several W3C tests now that more checks are passing.
- web-platform-tests/domparsing/createContextualFragment-expected.txt:
- web-platform-tests/innerText/setter-expected.txt:
Source/WebCore:
Align the innerText setter and createContextualFragment() with the
HTML specification and Gecko. In particular, they no longer throw
when the context element is a void element. This behavior was there
to match an old IE behavior but Edge dropped this behavior.
Test: fast/dom/br-set-outerText.html
- dom/Element.cpp:
- dom/Element.h:
- editing/markup.cpp:
(WebCore::createContextualFragment):
- html/HTMLElement.cpp:
(WebCore::HTMLElement::setInnerText):
(WebCore::HTMLElement::setOuterText):
LayoutTests:
Add test coverage for outerText, which is non-standard.
- fast/dom/br-set-outerText-expected.txt: Added.
- fast/dom/br-set-outerText.html: Added.
- 8:19 AM Changeset in webkit [210766] by
-
- 3 edits1 add in trunk
Reserve capacity for StringBuilder in unescape
https://bugs.webkit.org/show_bug.cgi?id=167008
Reviewed by Sam Weinig.
JSTests:
- stress/unescape.js: Added.
(shouldBe):
Source/JavaScriptCore:
unescapefunction is frequently called in Kraken sha256-iterative.
This patch just reserves the capacity for the StringBuilder.
Currently, we select the length of the string for the reserved capacity.
It improves the performance 2.73%.
Benchmark report for Kraken on sakura-trick.
VMs tested:
"baseline" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/untot/Release/bin/jsc
"patched" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/un/Release/bin/jsc
Collected 100 samples per benchmark/VM, with 100 VM invocations per benchmark. Emitted a call to gc() between
sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime()
function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in
milliseconds.
baseline patched
stanford-crypto-sha256-iterative 51.609+-0.672 50.237+-0.860 might be 1.0273x faster
<arithmetic> 51.609+-0.672 50.237+-0.860 might be 1.0273x faster
- runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncUnescape):
- 1:01 AM Changeset in webkit [210765] by
-
- 3 edits in trunk/Source/WebKit2
Remove unused WKView initializer parameter
https://bugs.webkit.org/show_bug.cgi?id=167046
Reviewed by Dan Bernstein.
- UIProcess/API/mac/WKView.mm:
(-[WKView initWithFrame:processPool:configuration:]):
(-[WKView initWithFrame:contextRef:pageGroupRef:relatedToPage:]):
(-[WKView initWithFrame:configurationRef:]):
(-[WKView initWithFrame:processPool:configuration:webView:]): Deleted.
- UIProcess/API/mac/WKViewInternal.h:
Ever since WKWebView stopped having WKView inside it, this parameter
has never been used. Now, it only leads to confusion.
