Timeline



Sep 28, 2014:

8:42 PM Changeset in webkit [174052] by mmaxfield@apple.com
  • 13 edits
    1 add in trunk/Source

Replace wkGetGlyphsForCharacters() with CGFontGetGlyphsForUnichars()
​https://bugs.webkit.org/show_bug.cgi?id=137197

Reviewed by Alexey Proskuryakov.

No new tests because there is no behavior change.

Source/WebCore:

  • WebCore.exp.in:
  • WebCore.order:
  • WebCore.xcodeproj/project.pbxproj:
  • platform/graphics/mac/GlyphPageTreeNodeMac.cpp:

(WebCore::GlyphPage::fill): Use SPI call instead of WKSI call

  • platform/mac/WebCoreSystemInterface.h:
  • platform/mac/WebCoreSystemInterface.mm:
  • platform/spi/cocoa/CGFontUnicodeSupport.h: Added for SPI call.

Source/WebKit:

  • mac/WebCoreSupport/WebSystemInterface.mm:

(InitWebCoreSystemInterface):

  • WebKit.order:

Source/WebKit2:

  • WebProcess/WebCoreSupport/mac/WebSystemInterface.mm:

(InitWebCoreSystemInterface):

  • mac/WebKit2.order:
8:02 PM Changeset in webkit [174051] by mmaxfield@apple.com
  • 3 edits in trunk/Tools

Allow webkit-patch upload to respect the --directory argument with git checkouts
​https://bugs.webkit.org/show_bug.cgi?id=137166

Reviewed by Darin Adler.

We simply hadn't plumbed it through.

  • Scripts/webkitpy/common/checkout/scm/detection.py:

(SCMDetector.detect_scm_system):

  • Scripts/webkitpy/common/checkout/scm/git.py:

(Git.init):
(Git.changed_files):

7:13 PM Changeset in webkit [174050] by Chris Dumez
  • 32 edits
    2 copies in trunk/Source/WebCore

Automatically generate template specializations for most Elements
​https://bugs.webkit.org/show_bug.cgi?id=137174

Reviewed by Darin Adler.

Previously, the template specializations to make is<>() / downcast<>()
work for HTML/SVG/MathML elements were only generated if
"generateTypeHelpers" parameter was explicitly specified for the
corresponding tag name in the *Tags.in file.

We are however able to generate the template specializations for most
types so this patch drops the "generateTypeHelpers" parameter and
generates those template specializations by default.

One case we cannot generate the specialization ifor is when a class is
associated to several tag names but this patch updates the
make_names.pl script to detect this and skip those classes.

No new tests, no behavior change.

  • CMakeLists.txt:
  • WebCore.xcodeproj/project.pbxproj:
  • dom/make_names.pl:

(defaultTagPropertyHash):
(printTypeHelpers):

  • html/HTMLTagNames.in:
  • mathml/mathtags.in:
  • svg/SVGAllInOne.cpp:
  • svg/SVGAnimateColorElement.cpp:

(WebCore::SVGAnimateColorElement::SVGAnimateColorElement):
(WebCore::SVGAnimateColorElement::determinePropertyValueTypes):

  • svg/SVGAnimateColorElement.h:
  • svg/SVGAnimateElement.cpp:

(WebCore::SVGAnimateElement::SVGAnimateElement):
(WebCore::SVGAnimateElement::~SVGAnimateElement): Deleted.
(WebCore::SVGAnimateElement::hasValidAttributeType): Deleted.
(WebCore::SVGAnimateElement::determineAnimatedPropertyType): Deleted.
(WebCore::SVGAnimateElement::calculateAnimatedValue): Deleted.
(WebCore::SVGAnimateElement::calculateToAtEndOfDurationValue): Deleted.
(WebCore::SVGAnimateElement::calculateFromAndToValues): Deleted.
(WebCore::SVGAnimateElement::calculateFromAndByValues): Deleted.
(WebCore::propertyTypesAreConsistent): Deleted.
(WebCore::SVGAnimateElement::resetAnimatedType): Deleted.
(WebCore::applyCSSPropertyToTarget): Deleted.
(WebCore::removeCSSPropertyFromTarget): Deleted.
(WebCore::applyCSSPropertyToTargetAndInstances): Deleted.
(WebCore::removeCSSPropertyFromTargetAndInstances): Deleted.
(WebCore::notifyTargetAboutAnimValChange): Deleted.
(WebCore::notifyTargetAndInstancesAboutAnimValChange): Deleted.
(WebCore::SVGAnimateElement::clearAnimatedType): Deleted.
(WebCore::SVGAnimateElement::applyResultsToTarget): Deleted.
(WebCore::SVGAnimateElement::animatedPropertyTypeSupportsAddition): Deleted.
(WebCore::SVGAnimateElement::isAdditive): Deleted.
(WebCore::SVGAnimateElement::calculateDistance): Deleted.
(WebCore::SVGAnimateElement::setTargetElement): Deleted.
(WebCore::SVGAnimateElement::setAttributeName): Deleted.
(WebCore::SVGAnimateElement::resetAnimatedPropertyType): Deleted.
(WebCore::SVGAnimateElement::ensureAnimator): Deleted.

  • svg/SVGAnimateElement.h:

(WebCore::isSVGAnimateElement): Deleted.

  • svg/SVGAnimateElementBase.cpp: Copied from Source/WebCore/svg/SVGAnimateElement.cpp.

(WebCore::SVGAnimateElementBase::SVGAnimateElementBase):
(WebCore::SVGAnimateElementBase::~SVGAnimateElementBase):
(WebCore::SVGAnimateElementBase::hasValidAttributeType):
(WebCore::SVGAnimateElementBase::determineAnimatedPropertyType):
(WebCore::SVGAnimateElementBase::calculateAnimatedValue):
(WebCore::SVGAnimateElementBase::calculateToAtEndOfDurationValue):
(WebCore::SVGAnimateElementBase::calculateFromAndToValues):
(WebCore::SVGAnimateElementBase::calculateFromAndByValues):
(WebCore::propertyTypesAreConsistent):
(WebCore::SVGAnimateElementBase::resetAnimatedType):
(WebCore::applyCSSPropertyToTarget):
(WebCore::removeCSSPropertyFromTarget):
(WebCore::applyCSSPropertyToTargetAndInstances):
(WebCore::removeCSSPropertyFromTargetAndInstances):
(WebCore::notifyTargetAboutAnimValChange):
(WebCore::notifyTargetAndInstancesAboutAnimValChange):
(WebCore::SVGAnimateElementBase::clearAnimatedType):
(WebCore::SVGAnimateElementBase::applyResultsToTarget):
(WebCore::SVGAnimateElementBase::animatedPropertyTypeSupportsAddition):
(WebCore::SVGAnimateElementBase::isAdditive):
(WebCore::SVGAnimateElementBase::calculateDistance):
(WebCore::SVGAnimateElementBase::setTargetElement):
(WebCore::SVGAnimateElementBase::setAttributeName):
(WebCore::SVGAnimateElementBase::resetAnimatedPropertyType):
(WebCore::SVGAnimateElementBase::ensureAnimator):

  • svg/SVGAnimateElementBase.h: Copied from Source/WebCore/svg/SVGAnimateElement.h.

(WebCore::isSVGAnimateElementBase):

  • svg/SVGAnimateTransformElement.cpp:

(WebCore::SVGAnimateTransformElement::SVGAnimateTransformElement):
(WebCore::SVGAnimateTransformElement::parseAttribute):

  • svg/SVGAnimateTransformElement.h:
  • svg/SVGAnimatedAngle.cpp:
  • svg/SVGAnimatedBoolean.cpp:
  • svg/SVGAnimatedColor.cpp:
  • svg/SVGAnimatedInteger.cpp:
  • svg/SVGAnimatedIntegerOptionalInteger.cpp:
  • svg/SVGAnimatedLength.cpp:
  • svg/SVGAnimatedLengthList.cpp:
  • svg/SVGAnimatedNumber.cpp:
  • svg/SVGAnimatedNumberList.cpp:
  • svg/SVGAnimatedNumberOptionalNumber.cpp:
  • svg/SVGAnimatedPath.cpp:
  • svg/SVGAnimatedPointList.cpp:
  • svg/SVGAnimatedPreserveAspectRatio.cpp:
  • svg/SVGAnimatedRect.cpp:
  • svg/SVGAnimatedString.cpp:
  • svg/SVGAnimationElement.cpp:

(WebCore::SVGAnimationElement::currentValuesForValuesAnimation):

  • svg/SVGSetElement.cpp:

(WebCore::SVGSetElement::SVGSetElement):

  • svg/SVGSetElement.h:
  • svg/svgtags.in:
6:52 PM Changeset in webkit [174049] by commit-queue@webkit.org
  • 7 edits
    3 adds in trunk

Simple ES6 feature: Number constructor extras
​https://bugs.webkit.org/show_bug.cgi?id=131707

Patch by Diego Pino Garcia <Diego Pino Garcia> on 2014-09-28
Reviewed by Darin Adler.

Source/JavaScriptCore:

  • runtime/CommonIdentifiers.h:
  • runtime/NumberConstructor.cpp:

(JSC::NumberConstructor::finishCreation): Setup constants and
functions.
(JSC::numberConstructorFuncIsFinite): Added.
(JSC::numberConstructorFuncIsInteger): Added.
(JSC::numberConstructorFuncIsNaN): Added.
(JSC::numberConstructorFuncIsSafeInteger): Added.
(JSC::NumberConstructor::getOwnPropertySlot): Deleted.
(JSC::numberConstructorNaNValue): Deleted.
(JSC::numberConstructorNegInfinity): Deleted.
(JSC::numberConstructorPosInfinity): Deleted.
(JSC::numberConstructorMaxValue): Deleted.
(JSC::numberConstructorMinValue): Deleted.

  • runtime/NumberConstructor.h:

LayoutTests:

  • js/Object-getOwnPropertyNames-expected.txt:
  • js/number-constructor-expected.txt: Added.
  • js/number-constructor.html: Added.
  • js/script-tests/Object-getOwnPropertyNames.js:
  • js/script-tests/number-constructor.js: Added.
6:18 PM Changeset in webkit [174048] by gyuyoung.kim@samsung.com
  • 12 edits in trunk/Source

Use std::unique_ptr for ContextMenuController
​https://bugs.webkit.org/show_bug.cgi?id=137178

Reviewed by Darin Adler.

Switch to using std::unique_ptr instead of OwnPtr and PassOwnPtr
for ContextMenuController class. Inherited class is changed by this use as well.

Source/WebCore:

No new tests, no behavior changes.

  • loader/EmptyClients.cpp:

(WebCore::EmptyContextMenuClient::customizeMenu):

  • loader/EmptyClients.h:
  • page/ContextMenuClient.h:
  • page/ContextMenuController.cpp:

(WebCore::ContextMenuController::clearContextMenu):
(WebCore::ContextMenuController::maybeCreateContextMenu):
(WebCore::ContextMenuController::showContextMenu):

  • page/ContextMenuController.h:

Source/WebKit/win:

  • WebCoreSupport/WebContextMenuClient.cpp:

(WebContextMenuClient::customizeMenu):

  • WebCoreSupport/WebContextMenuClient.h:

Source/WebKit2:

  • WebProcess/WebCoreSupport/WebContextMenuClient.cpp:

(WebKit::WebContextMenuClient::customizeMenu):

  • WebProcess/WebCoreSupport/WebContextMenuClient.h:
6:04 PM Changeset in webkit [174047] by gyuyoung.kim@samsung.com
  • 14 edits in trunk/Source

Move ColorInputType class to std::unique_ptr
​https://bugs.webkit.org/show_bug.cgi?id=137173

Reviewed by Darin Adler.

Replace uses of PassOwnPtr in code under ColorInputType class with std::unique_ptr.
Child classes follow this change as well.

Source/WebCore:

No new tests, no behavior changes.

  • html/ColorInputType.cpp:

(WebCore::ColorInputType::didEndChooser):

  • html/ColorInputType.h:
  • loader/EmptyClients.cpp:

(WebCore::EmptyChromeClient::createColorChooser):

  • loader/EmptyClients.h:
  • page/Chrome.cpp:

(WebCore::Chrome::createColorChooser):

  • page/Chrome.h:
  • page/ChromeClient.h:

Source/WebKit/mac:

  • WebCoreSupport/WebChromeClient.h:
  • WebCoreSupport/WebChromeClient.mm:

(WebChromeClient::createColorChooser):

Source/WebKit2:

  • WebProcess/WebCoreSupport/WebChromeClient.cpp:

(WebKit::WebChromeClient::createColorChooser):

  • WebProcess/WebCoreSupport/WebChromeClient.h:
4:18 PM Changeset in webkit [174046] by commit-queue@webkit.org
  • 16 edits in trunk

Fix some minor typos: psuedo -> pseudo
​https://bugs.webkit.org/show_bug.cgi?id=137192

Patch by Sungmann Cho <​sungmann.cho@navercorp.com> on 2014-09-28
Reviewed by Alexey Proskuryakov.

PerformanceTests:

  • Speedometer/resources/todomvc/architecture-examples/emberjs/bower_components/handlebars/handlebars.js:

Source/WebCore:

No new tests, no behavior change.

  • css/CSSSelector.cpp:

(WebCore::CSSSelector::specificityForOneSelector):

LayoutTests:

  • fast/dom/Window/getMatchedCSSRules-with-invalid-pseudo-elements-expected.txt:
  • fast/dom/Window/getMatchedCSSRules-with-invalid-pseudo-elements.html:
  • fast/dom/Window/getMatchedCSSRules-with-pseudo-elements-expected.txt:
  • fast/dom/Window/getMatchedCSSRules-with-pseudo-elements.html:
  • fast/selectors/159.html:
  • fast/selectors/160.html:
  • fast/selectors/166.html:
  • platform/efl/fast/selectors/166-expected.txt:
  • platform/gtk/fast/selectors/166-expected.txt:
  • platform/ios-sim/fast/selectors/166-expected.txt:
  • platform/mac/fast/selectors/166-expected.txt:
1:59 PM Changeset in webkit [174045] by weinig@apple.com
  • 17 edits
    1 move
    1 delete in trunk

Replace OSObjectPtr with RetainPtr/adoptOS
​https://bugs.webkit.org/show_bug.cgi?id=137158

Reviewed by Dan Bernstein.

Source/WebKit2:

  • DatabaseProcess/EntryPoint/mac/XPCService/DatabaseServiceEntryPoint.mm:

(DatabaseServiceInitializer):

  • NetworkProcess/EntryPoint/mac/XPCService/NetworkServiceEntryPoint.mm:

(WebKit::NetworkServiceInitializerDelegate::NetworkServiceInitializerDelegate):
(NetworkServiceInitializer):

  • Platform/IPC/Connection.h:

(IPC::Connection::Identifier::Identifier):

  • Platform/IPC/mac/ConnectionMac.mm:

(IPC::ConnectionTerminationWatchdog::createConnectionTerminationWatchdog):
(IPC::ConnectionTerminationWatchdog::ConnectionTerminationWatchdog):

  • PluginProcess/EntryPoint/mac/XPCService/PluginServiceEntryPoint.mm:

(WebKit::PluginServiceInitializerDelegate::PluginServiceInitializerDelegate):
(PluginServiceInitializer):

  • Shared/EntryPointUtilities/mac/XPCService/XPCServiceEntryPoint.h:

(WebKit::XPCServiceInitializerDelegate::XPCServiceInitializerDelegate):
(WebKit::XPCServiceInitializer):

  • Shared/EntryPointUtilities/mac/XPCService/XPCServiceEntryPoint.mm:

(WebKit::XPCServiceInitializerDelegate::checkEntitlements):
(WebKit::XPCServiceInitializerDelegate::hasEntitlement):

  • Shared/EntryPointUtilities/mac/XPCService/XPCServiceMain.Development.mm:

(WebKit::XPCServiceEventHandler):

  • Shared/EntryPointUtilities/mac/XPCService/XPCServiceMain.mm:

(WebKit::XPCServiceEventHandler):

  • UIProcess/Launcher/mac/ProcessLauncherMac.mm:

(WebKit::connectToService):
(WebKit::connectToReExecService):

  • WebProcess/EntryPoint/mac/XPCService/WebContentServiceEntryPoint.mm:

(WebContentServiceInitializer):

Source/WTF:

  • WTF.xcodeproj/project.pbxproj:
  • wtf/OSObjectPtr.h: Removed.
  • wtf/RetainPtr.h:

(WTF::adoptOS):
Added. This adopt function is slightly different than both adoptCF and adoptNS,
in that unlike adoptCF(), it can be passed an Objective-C type (since OS objects
are sometimes Objective-C objects, but not always), and unlike adoptNS() it doesn't
require us to jump through hoops to appease GC (since OS objects are not Objective-C
objects if GC is enabled).

Tools:

  • TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
  • TestWebKitAPI/Tests/WTF/darwin/OSObjectPtr.cpp: Removed.
  • TestWebKitAPI/Tests/WTF/darwin/RetainPtrOSObject.cpp: Copied from Tools/TestWebKitAPI/Tests/WTF/darwin/OSObjectPtr.cpp.

Rename and change test to use RetainPtr. Remove now unneeded part testing WTF::retainOSObject/WTF::releaseOSObject.

7:07 AM WebKitGTK/2.6.x edited by berto@igalia.com
(diff)
1:23 AM Changeset in webkit [174044] by Carlos Garcia Campos
  • 1 edit
    1 move in trunk/Source/WebCore

Unreviewed. Move RenderThemeGtk.h from platform/gtk to rendering.

I forgot to move this file in r173111.

  • rendering/RenderThemeGtk.h: Renamed from Source/WebCore/platform/gtk/RenderThemeGtk.h.
1:18 AM Changeset in webkit [174043] by Carlos Garcia Campos
  • 4 edits in trunk/Source/WebCore

[ATK] WebKitAccessibleWrapperAtk should not depend on GTK
​https://bugs.webkit.org/show_bug.cgi?id=137177

Reviewed by Martin Robinson.

It's used to get the web view widget, but there's no GtkWidget in
the web process and platformPageClient is always NULL.

  • PlatformGTK.cmake: Move accessibility sources to the WebCore

sources list.

  • accessibility/atk/WebKitAccessibleWrapperAtk.cpp:

(atkParentOfRootObject): Remove code to get view GtkWidget.

  • editing/atk/FrameSelectionAtk.cpp: Remove unneeded header include.
1:14 AM Changeset in webkit [174042] by Carlos Garcia Campos
  • 2 edits
    2 deletes in trunk/Source/WebCore

[GTK] Remove unused GtkPluginWidget
​https://bugs.webkit.org/show_bug.cgi?id=137176

Reviewed by Csaba Osztrogonác.

It was only used by WebKit1.

  • PlatformGTK.cmake:
  • platform/gtk/GtkPluginWidget.cpp: Removed.
  • platform/gtk/GtkPluginWidget.h: Removed.
1:06 AM Changeset in webkit [174041] by Carlos Garcia Campos
  • 5 edits in trunk/Source/WebCore

[cairo] GraphicsContext should not depend on GTK+
​https://bugs.webkit.org/show_bug.cgi?id=137175

Reviewed by Martin Robinson.

Remove the unused methods depending on GDK and simplify
GraphicsContext::drawFocusRing() using only cairo API.

  • PlatformGTK.cmake: Move GraphicsContextCairo.cpp to the webcore sources.
  • platform/graphics/GraphicsContext.h:
  • platform/graphics/cairo/GraphicsContextCairo.cpp:

(WebCore::GraphicsContext::drawFocusRing): Iterate the rectangles
instead of creating a region for the rectangles and call gdk_cairo_region().
(WebCore::GraphicsContext::setGdkExposeEvent): Deleted.
(WebCore::GraphicsContext::gdkExposeEvent): Deleted.
(WebCore::GraphicsContext::gdkWindow): Deleted.

  • platform/graphics/cairo/GraphicsContextPlatformPrivateCairo.h:

(WebCore::GraphicsContextPlatformPrivate::GraphicsContextPlatformPrivate):

Sep 27, 2014:

10:57 PM Changeset in webkit [174040] by Chris Dumez
  • 11 edits in trunk/Source/WebCore

HTMLPlugInElement::isUserObservable() is causing layout
​https://bugs.webkit.org/show_bug.cgi?id=137156

Reviewed by Ryosuke Niwa.

While profiling the page load of nytimes.com, I noticed that we were
spending ~4-5% of cpu time in HTMLPlugInElement::isUserObservable().
The reason is that the function calls pluginWidget(), which causes a
layout update in HTMLObjectElement::renderWidgetForJSBindings(), to
make sure the plugin is loaded and its renderer is created.

HTMLPlugInElement::isUserObservable() shouldn't need to do a layout.
This patch does the following to address the problem:

  • Rename renderWidgetForJSBindings() to renderWidgetLoadingPlugin() because this function is not always called from the JS Bindings nowadays. The new name makes it clearer that this will load the plugin if needed (to make sure the renderer is created, and by doing a layout).
  • Add a PluginLoadingPolicy argument to HTMLPlugInElement::pluginWidget() to let the caller control if the plugin should be loaded or not.
  • Update the call to pluginWidget() in isUserObservable() so that we do not attempt to load the plugin (thus not causing a layout).

No new tests, no behavior change.

  • WebCore.exp.in:
  • WebCore.order:
  • html/HTMLAppletElement.cpp:

(WebCore::HTMLAppletElement::renderWidgetLoadingPlugin):
(WebCore::HTMLAppletElement::renderWidgetForJSBindings): Deleted.

  • html/HTMLAppletElement.h:
  • html/HTMLEmbedElement.cpp:

(WebCore::HTMLEmbedElement::renderWidgetLoadingPlugin):
(WebCore::HTMLEmbedElement::renderWidgetForJSBindings): Deleted.

  • html/HTMLEmbedElement.h:
  • html/HTMLObjectElement.cpp:

(WebCore::HTMLObjectElement::renderWidgetLoadingPlugin):
(WebCore::HTMLObjectElement::renderWidgetForJSBindings): Deleted.

  • html/HTMLObjectElement.h:
  • html/HTMLPlugInElement.cpp:

(WebCore::HTMLPlugInElement::pluginWidget):
(WebCore::HTMLPlugInElement::isUserObservable):

  • html/HTMLPlugInElement.h:
10:21 PM Changeset in webkit [174039] by Chris Dumez
  • 22 edits in trunk/Source/WebCore

Use the new is<>() / downcast<>() for more Node subclasses
​https://bugs.webkit.org/show_bug.cgi?id=137184

Reviewed by Ryosuke Niwa.

Use the new is<>() / downcast<>() for more Node subclasses:
CDATASection, CharacterData, Comment, DocumentType,
ProcessingInstruction, and PseudoElement.

No new tests, no behavior change.

  • dom/CDATASection.h:

(WebCore::isCDATASection):

  • dom/CharacterData.cpp:

(WebCore::CharacterData::setDataAndUpdate):

  • dom/CharacterData.h:

(WebCore::isCharacterData):

  • dom/Comment.h:

(WebCore::isComment):

  • dom/DocumentStyleSheetCollection.cpp:

(WebCore::DocumentStyleSheetCollection::collectActiveStyleSheets):

  • dom/DocumentType.h:

(WebCore::isDocumentType):

  • dom/EventDispatcher.cpp:

(WebCore::eventTargetRespectingTargetRules):
(WebCore::nodeOrHostIfPseudoElement):

  • dom/Node.cpp:

(WebCore::markAncestorsWithChildNeedsStyleRecalc):
(WebCore::Node::pseudoAwarePreviousSibling):
(WebCore::Node::pseudoAwareNextSibling):

  • dom/NodeTraversal.cpp:

(WebCore::NodeTraversal::previousIncludingPseudo):
(WebCore::NodeTraversal::nextIncludingPseudo):
(WebCore::NodeTraversal::nextIncludingPseudoSkippingChildren):

  • dom/ProcessingInstruction.h:

(WebCore::isProcessingInstruction):

  • dom/PseudoElement.h:

(WebCore::isPseudoElement):

  • dom/Range.cpp:

(WebCore::lengthOfContentsInNode):
(WebCore::Range::processContentsBetweenOffsets):
(WebCore::Range::checkNodeWOffset):

  • editing/Editor.cpp:

(WebCore::Editor::shouldInsertFragment):

  • editing/MarkupAccumulator.cpp:

(WebCore::MarkupAccumulator::appendStartMarkup):

  • editing/cocoa/HTMLConverter.mm:

(HTMLConverter::_traverseNode):

  • inspector/InspectorDOMAgent.cpp:

(WebCore::InspectorDOMAgent::buildObjectForNode):

  • inspector/InspectorLayerTreeAgent.cpp:

(WebCore::InspectorLayerTreeAgent::buildObjectForLayer):

  • rendering/HitTestResult.cpp:

(WebCore::HitTestResult::setInnerNode):
(WebCore::HitTestResult::setInnerNonSharedNode):

  • rendering/RenderListItem.cpp:

(WebCore::enclosingList):

  • rendering/RenderObject.cpp:

(WebCore::RenderObject::generatingPseudoHostElement):

  • xml/XPathFunctions.cpp:

(WebCore::XPath::expandedNameLocalPart):

9:13 PM Changeset in webkit [174038] by Chris Dumez
  • 8 edits in trunk/Source/WebCore

Use the new is<>() / downcast<>() for Attr Nodes
​https://bugs.webkit.org/show_bug.cgi?id=137183

Reviewed by Ryosuke Niwa.

Use the new is<>() / downcast<>() for Attr Nodes instead of isAttr() /
toAttr().

No new tests, no behavior change.

  • dom/Attr.h:

(WebCore::isAttr):

  • dom/Document.cpp:

(WebCore::Document::importNode):
(WebCore::Document::adoptNode):

  • dom/NamedNodeMap.cpp:

(WebCore::NamedNodeMap::setNamedItem):

  • dom/Node.cpp:

(WebCore::Node::compareDocumentPosition):

  • inspector/InspectorDOMAgent.cpp:

(WebCore::InspectorDOMAgent::buildObjectForNode):

  • inspector/InspectorNodeFinder.cpp:

(WebCore::InspectorNodeFinder::searchUsingXPath):

  • xml/XPathNodeSet.cpp:

(WebCore::XPath::sortBlock):
(WebCore::XPath::NodeSet::sort):
(WebCore::XPath::findRootNode):

3:17 PM Changeset in webkit [174037] by Brian Burg
  • 5 edits in trunk/Source

Web Replay: Playback position updates should be sent before the next event loop input is dispatched
​https://bugs.webkit.org/show_bug.cgi?id=137162

Reviewed by Timothy Hatcher.

Source/WebCore:

To drive playback position updates in the Inspector UI, we send playbackHitPosition protocol
messages as the replay backend dispatches inputs. However, right now the semantics of that
message are muddy. The update is sent *after* the input at the offset is dispatched. This leads
to unexpected results if the debugger pauses while the input is being dispatched: the frontend
will only know about the previous (stale) playback position when the debugger pauses.

With this patch, the backend sends the playbackHitPosition(segmentOffset=n, inputOffset=m)
message when backend is about to dispatch input m, but has not yet begun to do so. Thus, any
subsequent page execution events (profiling, debugger pauses, etc) until the next
playbackHitPosition are caused by input m's being dispatched.

  • inspector/protocol/Replay.json: Clarify the message's semantics.
  • replay/ReplayController.cpp:

(WebCore::ReplayController::willDispatchInput):
(WebCore::ReplayController::didDispatchInput):

Source/WebInspectorUI:

Pausing playback from the UI was broken because of a typo. Fix this, and rename
stopPlayback to cancelPlayback.

  • UserInterface/Controllers/ReplayManager.js:

(WebInspector.ReplayManager.prototype.switchSession.if):

1:27 PM Changeset in webkit [174036] by fpizlo@apple.com
  • 8 edits
    1 add in trunk

Disable function.arguments
​https://bugs.webkit.org/show_bug.cgi?id=137167

Source/JavaScriptCore:

Rubber stamped by Geoffrey Garen.

Add an option to disable function.arguments. Add a test for disabling it.

Disabling function.arguments means that it returns an Arguments object that claims that
there were zero arguments. All other Arguments functionality still works, so any code
that tries to inspect this object will still think that it is looking at a perfectly
valid Arguments object.

This also makes function.arguments disabled by default. Note that the RJST harness will
enable them by default, to continue to get test coverage for the code that implements
the feature.

We will rip out that code once we're confident that it's really safe to remove this
feature. Only once we rip out that support will we be able to do optimizations to
leverage the lack of this feature. It's important to keep the support code, and the test
infrastructure, in place before we are confident. The logic to keep this working touches
the entire compiler and a large chunk of the runtime, so reimplementing it - or even
merging it back in - would be a nightmare. That's also basically the reason why we want
to rip it out if at all possible. It's a lot of terrible code.

  • interpreter/StackVisitor.cpp:

(JSC::StackVisitor::Frame::createArguments):

  • runtime/Arguments.h:

(JSC::Arguments::create):
(JSC::Arguments::finishCreation):

  • runtime/Options.h:
  • tests/stress/disable-function-dot-arguments.js: Added.

(foo):
(bar):

Tools:

Rubber stamped by Geoffrey Garen

Enable the feature by default during tests.

  • Scripts/run-jsc-stress-tests:

LayoutTests:

Rubber stamped by Geoffrey Garen.

Don't remove the tests for this, yet - but mark them as failing. We will rebase these,
or remove them entirely, once we know that it's safe to rip out this feature entirely.

11:49 AM Changeset in webkit [174035] by benjamin@webkit.org
  • 3 edits
    8 adds in trunk

Chaining multiple :nth-child() does not work properly
​https://bugs.webkit.org/show_bug.cgi?id=137032

Patch by Benjamin Poulain <​bpoulain@apple.com> on 2014-09-27
Reviewed by Gavin Barraclough.

Source/WebCore:

When multiple :nth-child() are chained, the evaluation of each "An+B" could depend on
the execution of the previous "An+B". The reason is that the register holding the position
of the current element could be modified by the evaluation of "An+B".

There are two cases in which the register was used as the destination of an operation:
1) When A and B are positive, the counter would be the destination of "counter - B".
2) When A is not 1 or 2, the modulo operation was not preserving the input register.

For (1), we a copy of the counter in that case of generateElementIsNthChild().

For (2), we also preserve a copy of the input if it is used by the operation. In this case,
if the input register is one of the argument we need for idiv, we preserve it on the stack
or in a register depending on what is available.

This increases the register requirements by 2 in the worst case on x86. The extra registers
can push generateElementIsNthChild() above the 4 available registers. To accomodate for that,
minimumRegisterRequirements() reserve more registers on x86.

The extra register pressure has strictly no effect on performance, x86_64 has 9 registers
available without pushing anything. The extra allocation is only necessary for debugging.

Tests: fast/selectors/nth-child-basics.html

fast/selectors/nth-child-chained.html
fast/selectors/nth-child-of-basics-2.html
fast/selectors/nth-child-of-chained.html

  • cssjit/SelectorCompiler.cpp:

(WebCore::SelectorCompiler::minimumRegisterRequirements):
(WebCore::SelectorCompiler::SelectorCodeGenerator::modulo):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateElementIsNthChild):

LayoutTests:

  • fast/selectors/nth-child-chained-expected.txt: Added.
  • fast/selectors/nth-child-chained.html: Added.
  • fast/selectors/nth-child-of-chained-expected.txt: Added.
  • fast/selectors/nth-child-of-chained.html: Added.

Those new tests target specifically the register reuse bug fixed by the patch.

  • fast/selectors/nth-child-basics-expected.txt: Added.
  • fast/selectors/nth-child-basics.html: Added.
  • fast/selectors/nth-child-of-basics-2-expected.txt: Added.
  • fast/selectors/nth-child-of-basics-2.html: Added.

Those tests add coverage for the examples used by ​http://nthmaster.com. This is to increase
the general test coverage.

I added nth-child-of-basics-2.html instead of extending nth-child-of-basics.html because
of the speed issue in debug without CSS JIT (otherwise the test can timeout).

12:13 AM Changeset in webkit [174034] by mitz@apple.com
  • 5 edits in trunk

WebKit top of tree sources won't build in 10.9 w/ Xcode 6.0.1
​https://bugs.webkit.org/show_bug.cgi?id=137053

Reviewed by Mark Rowe.

.:

  • WebKit.xcworkspace/xcshareddata/xcschemes/All Source (target WebProcess).xcscheme:

In the build pre-action, pass the --wksi and --llvm options to
copy-webkitlibraries-to-product-directory.

  • WebKit.xcworkspace/xcshareddata/xcschemes/All Source.xcscheme: Ditto.

Websites/webkit.org:

  • building/build.html: Removed instructions how to work around this bug, now that it’s fixed.
Note: See TracTimeline for information about the timeline view.