Timeline
May 19, 2013:
- 11:48 PM Changeset in webkit [150360] by
-
- 2 edits in trunk/Tools
[EFL] init/shutdown should be paired in EWebLauncher
https://bugs.webkit.org/show_bug.cgi?id=116427
Reviewed by Christophe Dumez.
Added ecore_file_shutdown() for cleanup of ecore_file.
Removed edje_init and ecore_evas_init because it was in ewk_init().
- EWebLauncher/main.c:
(main):
- 5:50 PM Changeset in webkit [150359] by
-
- 18 edits in branches/dfgFourthTier
CheckArrays should be hoisted
https://bugs.webkit.org/show_bug.cgi?id=116353
Source/JavaScriptCore:
Performance neutral. This will be more important when we start depending on CheckArray for flat arrays.
Reviewed by Filip Pizlo.
- dfg/DFGAbstractState.cpp: Add ForwardCheckArray to wherever we had a CheckArray before.
(JSC::DFG::AbstractState::executeEffects):
- dfg/DFGArgumentsSimplificationPhase.cpp:
(JSC::DFG::ArgumentsSimplificationPhase::run):
- dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::isContravenedByStructure): Checks if the ArrayMode derived from a specific Structure
would contradict the ArrayModes that would be filtered by the current ArrayMode. This is used to detect
if any specific CheckStructures would contradict our CheckArray so that we can defer to the CheckStructure's
judgment.
- dfg/DFGByteCodeParser.cpp: Fill in checkArrayHoistingFailed where we previously exited due to a BadIndexingType.
(JSC::DFG::ByteCodeParser::setLocal):
(JSC::DFG::ByteCodeParser::setArgument):
(JSC::DFG::ByteCodeParser::parseBlock):
- dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::checkArrayElimination):
(JSC::DFG::CSEPhase::performNodeCSE):
- dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
- dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
- dfg/DFGNode.h:
(JSC::DFG::Node::hasArrayMode):
- dfg/DFGNodeType.h: New ForwardCheckArray node type.
- dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
- dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
- dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
- dfg/DFGTypeCheckHoistingPhase.cpp: Refactored most of TypeCheckHoistingPhase into separate functions, some
of which are now generic to both CheckStructure and CheckArray hoisting while others are specific to one or the
other. Both of the non-zero CheckBallot values must be 1 because we use them as an index into an array of
length 2 inside the VariableAccessData.
(CheckData): Moved structure outside of TypeCheckHoistingPhase so that ArrayTypeCheck and StructureTypeCheck
can access it. Also added new fields for tracking ArrayModes. We need the m_arrayModeIsValid because there
isn't a good sentinel value for "this ArrayMode is invalid and meaningless" like there is for m_structure.
We need m_arrayModeHoistingOkay for when we want to permanently disable hoisting for that particular variable.
(JSC::DFG::CheckData::CheckData):
(JSC::DFG::CheckData::disableCheckArrayHoisting): Helper function for disabling CheckArray hoisting for a
specific CheckData.
(JSC::DFG::TypeCheckHoistingPhase::run): We now do both CheckStructure and CheckArray hoisting, although we prefer
CheckStructure hoisting when given the possibility to do both.
(TypeCheckHoistingPhase):
(JSC::DFG::TypeCheckHoistingPhase::clearVariableVotes): Clears all of the VariableAccessData votes since they
can only have two types of votes at any particular time.
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks): Very similar to identifyRedundantStructureChecks,
but with a few different nodes that are important, namely CheckArray (instead of CheckStructure) and the Arrayify-like
nodes always disable hoisting since they always change the IndexingType.
(JSC::DFG::TypeCheckHoistingPhase::disableHoistingForVariablesWithInsufficientVotes):
(JSC::DFG::TypeCheckHoistingPhase::disableHoistingAcrossOSREntries):
(JSC::DFG::TypeCheckHoistingPhase::disableCheckArrayHoisting): Helper that looks up the CheckData for the
specified variable and disables CheckArray hoisting on it.
(JSC::DFG::TypeCheckHoistingPhase::shouldConsiderForHoisting):
(JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheck):
(JSC::DFG::TypeCheckHoistingPhase::noticeCheckArray):
(JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheckAccountingForArrayMode): We want to take CheckStructure nodes
into account when hoisting CheckArrays, so we make sure that if we contradict what a CheckStructure says then we
give up on hoisting the CheckArray.
(JSC::DFG::ArrayTypeCheck::isValidToHoist):
(ArrayTypeCheck): Structure that houses some of the specifics on how to hoist CheckArrays. This structure
is used a template argument to allow some of the very similar code to statically parameterized and reused
for both CheckStructure and CheckArray hoisting.
(JSC::DFG::ArrayTypeCheck::disableHoisting):
(JSC::DFG::ArrayTypeCheck::isContravenedByValue):
(JSC::DFG::ArrayTypeCheck::hasEnoughVotesToHoist):
(JSC::DFG::ArrayTypeCheck::hoistingPreviouslyFailed):
(JSC::DFG::StructureTypeCheck::isValidToHoist):
(StructureTypeCheck): Same as ArrayTypeCheck, but specific to CheckStructure hoisting.
(JSC::DFG::StructureTypeCheck::disableHoisting):
(JSC::DFG::StructureTypeCheck::isContravenedByValue):
(JSC::DFG::StructureTypeCheck::hasEnoughVotesToHoist):
(JSC::DFG::StructureTypeCheck::hoistingPreviouslyFailed):
- dfg/DFGUnificationPhase.cpp: Added merging of whether or not CheckArray hoisting failed.
(JSC::DFG::UnificationPhase::run):
- dfg/DFGVariableAccessData.h:
(JSC::DFG::VariableAccessData::VariableAccessData):
(JSC::DFG::VariableAccessData::mergeCheckArrayHoistingFailed):
(VariableAccessData):
(JSC::DFG::VariableAccessData::checkArrayHoistingFailed):
- runtime/Options.h:
LayoutTests:
Added a microbenchmark to JSRegress that specifically targets CheckArray hoisting.
We get a 25% improvement on it.
Reviewed by Filip Pizlo.
- fast/js/regress/check-array-hoisting-expected.txt: Added.
- fast/js/regress/check-array-hoisting.html: Added.
- fast/js/regress/script-tests/check-array-hoisting.js: Added.
(f):
- 5:04 PM Changeset in webkit [150358] by
-
- 2 edits in trunk/Source/WebCore
[Mac] Improve string use in PasteboardMac
https://bugs.webkit.org/show_bug.cgi?id=116418
Reviewed by Sam Weinig.
Did a Ben Poulain all over this file.
- platform/mac/PasteboardMac.mm:
(WebCore::Pasteboard::plainText): Add the newline separately to the string builder.
Prepending it to the string first just does more allocations for no good reason.
(WebCore::Pasteboard::documentFragment): Use emptyString() instead of "" and use
ASCIILiteral where appropriate.
(WebCore::cocoaTypeFromHTMLClipboardType): More ASCIILiteral.
(WebCore::Pasteboard::clear): Use early return instead of a nested if here.
Use emptyString() instead of "".
(WebCore::addHTMLClipboardTypesForCocoaType): More ASCIILiteral.
- 4:56 PM Changeset in webkit [150357] by
-
- 2 edits in trunk/Tools
[EFL] Add command line option to MiniBrowser to set user agent
https://bugs.webkit.org/show_bug.cgi?id=116387
Patch by Jinwoo Song <jinwoo7.song@samsung.com> on 2013-05-19
Reviewed by Christophe Dumez.
We need this option to compare the rendering differences according to different user agents.
- MiniBrowser/efl/main.c:
(window_create):
(elm_main):
- 3:57 PM Changeset in webkit [150356] by
-
- 32 edits6 deletes in trunk
Remove link prerendering code
https://bugs.webkit.org/show_bug.cgi?id=116415
Reviewed by Darin Adler.
.:
This code was only used by Chromium and is dead now.
- Source/autotools/SetupWebKitFeatures.m4:
- Source/cmake/WebKitFeatures.cmake:
- Source/cmakeconfig.h.cmake:
Source/JavaScriptCore:
This code was only used by Chromium and is dead now.
- Configurations/FeatureDefines.xcconfig:
Source/WebCore:
- Configurations/FeatureDefines.xcconfig:
- GNUmakefile.list.am:
- Target.pri:
- WebCore.vcproj/WebCore.vcproj:
- WebCore.vcxproj/WebCore.vcxproj:
- WebCore.vcxproj/WebCore.vcxproj.filters:
- WebCore.xcodeproj/project.pbxproj:
- dom/Document.cpp:
(WebCore::Document::Document):
- dom/Document.h:
(WebCore):
(Document):
- dom/EventNames.h:
(WebCore):
- html/HTMLLinkElement.cpp:
- html/HTMLLinkElement.h:
- html/LinkRelAttribute.cpp:
(WebCore::LinkRelAttribute::LinkRelAttribute):
- html/LinkRelAttribute.h:
(LinkRelAttribute):
- loader/LinkLoader.cpp:
(WebCore::LinkLoader::~LinkLoader):
(WebCore::LinkLoader::loadLink):
(WebCore::LinkLoader::released):
- loader/LinkLoader.h:
(WebCore):
(LinkLoader):
- loader/LinkLoaderClient.h:
(LinkLoaderClient):
- loader/Prerenderer.cpp: Removed.
- loader/Prerenderer.h: Removed.
- loader/PrerendererClient.cpp: Removed.
- loader/PrerendererClient.h: Removed.
- platform/PrerenderClient.h: Removed.
- platform/PrerenderHandle.h: Removed.
Source/WebKit/blackberry:
This code was only used by Chromium and is dead now.
- WebCoreSupport/AboutDataEnableFeatures.in:
Source/WebKit/mac:
This code was only used by Chromium and is dead now.
- Configurations/FeatureDefines.xcconfig:
Source/WebKit2:
This code was only used by Chromium and is dead now.
- Configurations/FeatureDefines.xcconfig:
Source/WTF:
This code was only used by Chromium and is dead now.
- wtf/FeatureDefines.h:
- 3:52 PM Changeset in webkit [150355] by
-
- 12 edits in trunk/Source/WebCore
Change the terminology used by rendering code when painting a given node and its children from "paintingRoot" to "subtreePaintRoot"
https://bugs.webkit.org/show_bug.cgi?id=116417
Reviewed by Sam Weinig.
PaintInfo and RenderLayer code referred to a "paintingRoot". This is only set when
FrameView::setNodeToDraw() has been called and is used to restrict painting to
some part of the subtree, but it could easily be misinterpreted, and confused with
the "rootLayer" used by RenderLayer (which is usually not the layer associated with
the paintingRoot).
Change the terminology from "paintingRoot" to "subtreePaintRoot" root to make the
purpose of this variable more obvious.
No behavior change.
- page/FrameView.cpp: Add a comment for setNodeToDraw(); in future this should
be called setSubtreePaintRoot() or something. Not done in this patch to avoid
risk; this function is exported from WebCore.
- rendering/InlineFlowBox.cpp:
(WebCore::InlineFlowBox::paint):
- rendering/PaintInfo.h:
(WebCore::PaintInfo::PaintInfo):
(WebCore::PaintInfo::updateSubtreePaintRootForChildren):
(WebCore::PaintInfo::shouldPaintWithinRoot):
- rendering/RenderBlock.cpp:
(WebCore::RenderBlock::paintContents):
- rendering/RenderBox.cpp:
(WebCore::RenderBox::paint):
- rendering/RenderLayer.cpp:
(WebCore::RenderLayer::paint):
(WebCore::RenderLayer::paintOverlayScrollbars):
(WebCore::RenderLayer::paintLayerContents):
(WebCore::RenderLayer::paintLayerByApplyingTransform):
(WebCore::RenderLayer::paintBackgroundForFragments):
(WebCore::RenderLayer::paintForegroundForFragments):
(WebCore::RenderLayer::paintForegroundForFragmentsWithPhase):
(WebCore::RenderLayer::paintOutlineForFragments):
(WebCore::RenderLayer::paintMaskForFragments):
- rendering/RenderLayer.h:
(WebCore::RenderLayer::LayerPaintingInfo::LayerPaintingInfo):
- rendering/RenderObject.cpp: Add a comment to recommend changing the name of
paintingRootRect() to refer to a subtree paint. Not done in this patch to avoid
risk; this function is exported from WebCore.
- rendering/RenderSnapshottedPlugIn.cpp:
(WebCore::RenderSnapshottedPlugIn::paint):
- rendering/RenderTable.cpp:
(WebCore::RenderTable::paintObject):
- rendering/svg/RenderSVGContainer.cpp:
(WebCore::RenderSVGContainer::paint):
- 2:51 PM Changeset in webkit [150354] by
-
- 5 edits in trunk/Source/WebCore
Use Element instead of Node in DragState, also redo DragState struct
https://bugs.webkit.org/show_bug.cgi?id=116411
Reviewed by Sam Weinig.
The drag source is an element, so use RefPtr<Element> instead of RefPtr<Node>.
Also, the entire drag state is about dragging, so no need for the word "drag" in the
name of its members. Also, it's a struct, so the members don't need m_ prefixes.
- page/DragController.cpp: Removed unneeded include of Node.h since it's included by
Element.h, which is also included.
(WebCore::DragController::draggableElement): Renamed from Node to Element and changed
the types and names of arguments accordingly. Also made this function handle a
startElement of 0 so callers don't need to. Also updated for changes to DragState members.
(WebCore::DragController::startDrag): Updated for changes to DragState members.
Since dragSource can only be an element, was able to get rid of isElementNode checks.
- page/DragController.h: Fixed style of forward declarations of structs. Updated for
change of draggableNode to draggableElement. Also removed declarations of nonexistent
selectionDraggingRect and doDrag functions.
- page/DragState.h: Rewrote practically this whole header. Added an include of Element
instead of Node since that's what we use now. Removed includes that are redundant.
There's no problem copying a DragState, so removed WTF_MAKE_NONCOPYABLE. There's no need
to allocate a DragState on the heap, so removed WTF_MAKE_FAST_ALLOCATED. The event dispatch
boolean is never set to a constant, so there's no need for a policy enum; it can just be
a boolean. Removed the "m_" prefixes from the struct members, since this is a struct with
public members and we don't use the prefix in those cases. Removed the word "drag" from the
struct member names since this entire struct is about dragging and has drag in its name.
Left the comments mostly intact, even though I'm not certain of their value.
- page/EventHandler.cpp:
(WebCore::EventHandler::handleMousePressEvent): Updated for changes to DragState.
(WebCore::EventHandler::eventMayStartDrag):
Use innerElement instead of innerNode to call draggableElement instead of draggableNode.
(WebCore::EventHandler::updateDragAndDrop): Updated for changes to DragState.
(WebCore::EventHandler::cancelDragAndDrop): Ditto.
(WebCore::EventHandler::handleWheelEvent): Added FIXME.
(WebCore::EventHandler::dragHysteresisExceeded): Updated for changes to DragState.
(WebCore::EventHandler::freeClipboard): Updated for changes to DragState. Also re-added
code to release the clipboard object, which is needed here to avoid keeping it around in
memory until the next drag.
(WebCore::EventHandler::dragSourceEndedAt): Updated for changes to DragState.
(WebCore::EventHandler::updateDragStateAfterEditDragIfNeeded): Ditto.
(WebCore::EventHandler::dispatchDragSrcEvent): Ditto.
(WebCore::EventHandler::handleDrag): Updated for changes to DragState. Use innerElement
instead of innerNode to call draggableElement instead of draggableNode. No longer need to
null check innerElement because draggableElement does that. Removed unneeded else that was
setting m_dragSrc to zero since it's guaranteed to already be zero.
- 1:38 PM Changeset in webkit [150353] by
-
- 20 edits in trunk/Source
Remove ChromeClient::webView()
https://bugs.webkit.org/show_bug.cgi?id=116054
Source/WebCore:
Reviewed by Darin Adler.
This blatantly horrible layer violation was only used to know if a ChromeClient is an empty
client or not. We already have a (slightly less horrible) way to do that.
- loader/EmptyClients.h:
- page/ChromeClient.h:
(ChromeClient):
Source/WebKit/blackberry:
Reviewed by Andreas Kling.
This blatantly horrible layer violation was only used by the Chromium port; get rid of it.
- WebCoreSupport/ChromeClientBlackBerry.h:
(ChromeClientBlackBerry):
Source/WebKit/efl:
Reviewed by Darin Adler.
This blatantly horrible layer violation was only used to know if a ChromeClient is an empty
client or not. We already have a (slightly less horrible) way to do that.
- WebCoreSupport/ChromeClientEfl.h:
(ChromeClientEfl):
Source/WebKit/gtk:
Reviewed by Darin Adler.
This blatantly horrible layer violation was only used to know if a ChromeClient is an empty
client or not. We already have a (slightly less horrible) way to do that.
- WebCoreSupport/ChromeClientGtk.h:
(ChromeClient):
Source/WebKit/mac:
Reviewed by Darin Adler.
This blatantly horrible layer violation was only used to know if a ChromeClient is an empty
client or not. We already have a (slightly less horrible) way to do that.
- WebCoreSupport/WebChromeClient.h:
(WebChromeClient):
Source/WebKit/qt:
Reviewed by Darin Adler.
This blatantly horrible layer violation was only used to know if a ChromeClient is an empty
client or not. We already have a (slightly less horrible) way to do that.
- WebCoreSupport/ChromeClientQt.h:
(ChromeClientQt):
Source/WebKit/win:
Reviewed by Darin Adler.
This blatantly horrible layer violation was only used to know if a ChromeClient is an empty
client or not. We already have a (slightly less horrible) way to do that.
- WebCoreSupport/WebChromeClient.h:
(WebChromeClient):
Source/WebKit/wince:
Reviewed by Darin Adler.
This blatantly horrible layer violation was only used to know if a ChromeClient is an empty
client or not. We already have a (slightly less horrible) way to do that.
- WebCoreSupport/ChromeClientWinCE.h:
(ChromeClientWinCE):
- 11:40 AM Changeset in webkit [150352] by
-
- 2 edits in trunk/Tools
Unreviewed, addressing test-webkitpy failures after r150317.
- Scripts/webkitpy/w3c/test_converter.py:
(W3CTestConverter.read_webkit_prefixed_css_property_list): CssPropertyNames.in doesn't exist, but CSSPropertyNames.in does.
- 8:40 AM Changeset in webkit [150351] by
-
- 6 edits1 delete in trunk/Source/WebCore
Eliminate the Editor::newGeneralClipboard function
https://bugs.webkit.org/show_bug.cgi?id=116410
Reviewed by Andreas Kling.
This is one of the clean-ups made possible by the changes to the DOM clipboard class.
I had been waiting until all the platforms were moved over to it, but it turns out to be
easy to do this now, just with #ifdefs.
- PlatformBlackBerry.cmake: Deleted EditorBlackBerry.cpp.
- editing/Editor.cpp:
(WebCore::Editor::dispatchCPPEvent): Call Clipboard::createForCopyAndPaste directly when
using the new version of the Clipboard class. Also some small style cleanup nearby.
- editing/blackberry/EditorBlackBerry.cpp: Removed. The only function in this file was
newGeneralClipboard.
- editing/mac/EditorMac.mm: Deleted newGeneralClipboard.
- platform/efl/ClipboardEfl.cpp: Ditto.
- platform/gtk/ClipboardGtk.cpp: Ditto.
- 7:56 AM Changeset in webkit [150350] by
-
- 2 edits in trunk/Source/WebCore
GtkSelectionData length is off by one
https://bugs.webkit.org/show_bug.cgi?id=113962
Reviewed by Anders Carlsson.
No new tests. Since drag data is interpreted as a null-terminated string
this is difficult to test with a C program and we have no infrastructure
built for using GIR tests.
- platform/gtk/PasteboardHelper.cpp:
(WebCore::PasteboardHelper::fillSelectionData): Instead of including the null
character in the paste data length, just include the string. This matches the behavior
of Firefox.
May 18, 2013:
- 8:01 PM Changeset in webkit [150349] by
-
- 5 edits in trunk/Source/WebCore
Hoist several chunks of code at the top of RenderLayer::paintLayerContents() onto new functions
https://bugs.webkit.org/show_bug.cgi?id=116406
Reviewed by Andreas Kling.
RenderLayer::paintLayerContents() was getting polluted with code related to filters,
clipping and font subpixel quantization, and hard to follow.
Move three hunks of code into new functions:
setupFontSubpixelQuantization() now contains the code related to whether we disable
font subpixel quantization on the context.
setupClipPath() now contains code related to clipping to shapes and references.
setupFilters() and applyFilters() contain code related to CSS filters.
As part of this, the interaction with FilterEffectRendererHelper was simplified.
It was convenient for setupFilters() to return a FilterEffectRendererHelper object
if successful, so we use an OwnPtr<FilterEffectRendererHelper> now. In addition,
the GraphicsContext swapping was moved from FilterEffectRendererHelper code into RenderLayer
to make it easier to follow. FilterEffectRendererHelper no longer holds on to
the old GraphicsContext.
No behavior change.
- rendering/FilterEffectRenderer.cpp:
(WebCore::FilterEffectRendererHelper::filterContext):
(WebCore::FilterEffectRendererHelper::beginFilterEffect):
(WebCore::FilterEffectRendererHelper::applyFilterEffect):
- rendering/FilterEffectRenderer.h:
(WebCore::FilterEffectRendererHelper::FilterEffectRendererHelper):
(WebCore::FilterEffectRendererHelper::hasStartedFilterEffect):
(FilterEffectRendererHelper):
- rendering/RenderLayer.cpp:
(WebCore::RenderLayer::setupFontSubpixelQuantization):
(WebCore::RenderLayer::setupClipPath):
(WebCore::RenderLayer::setupFilters):
(WebCore::RenderLayer::applyFilters):
(WebCore::RenderLayer::paintLayerContents):
- rendering/RenderLayer.h:
- 8:00 PM Changeset in webkit [150348] by
-
- 3 edits in trunk/Source/WebCore
Refactor RenderStyle::diff()
https://bugs.webkit.org/show_bug.cgi?id=116397
Reviewed by Andreas Kling.
RenderStyle::diff() was prone to being changed incorrectly, since there was
a poorly documented ordering requirement: style changes that cause layout
have to be detected before those that cause only repainting.
In addition, the existing code made it impossible to separately ask whether
a given style change requires a repaint, if we've already detected that it
requires a positioned-movement-only layout.
Fix by factoring the code into member functions that check for each type
of style change.
No behavior change.
- rendering/style/RenderStyle.cpp:
(WebCore::positionChangeIsMovementOnly):
(WebCore::RenderStyle::changeRequiresLayout):
(WebCore::RenderStyle::changeRequiresPositionedLayoutOnly):
(WebCore::RenderStyle::changeRequiresLayerRepaint):
(WebCore::RenderStyle::changeRequiresRepaint):
(WebCore::RenderStyle::changeRequiresRepaintIfText):
(WebCore::RenderStyle::changeRequiresRecompositeLayer):
(WebCore::RenderStyle::diff):
- rendering/style/RenderStyle.h:
- 7:40 PM Changeset in webkit [150347] by
-
- 2 edits in trunk/LayoutTests
svg/batik tests are flakey.
webkit.org/b/116398
- platform/mac/TestExpectations:
- 5:06 PM Changeset in webkit [150346] by
-
- 9 edits in trunk/Source
Simplify the StorageArea setter functions
https://bugs.webkit.org/show_bug.cgi?id=116402
Reviewed by Sam Weinig.
Source/WebCore:
Move more security checking code to Storage so more code can be shared between WebKit1 and WebKit2.
- inspector/InspectorDOMStorageAgent.cpp:
(WebCore::InspectorDOMStorageAgent::setDOMStorageItem):
(WebCore::InspectorDOMStorageAgent::removeDOMStorageItem):
- storage/Storage.cpp:
(WebCore::Storage::setItem):
(WebCore::Storage::removeItem):
(WebCore::Storage::clear):
- storage/StorageArea.h:
(StorageArea):
- storage/StorageAreaImpl.cpp:
(WebCore::StorageAreaImpl::setItem):
(WebCore::StorageAreaImpl::removeItem):
(WebCore::StorageAreaImpl::clear):
- storage/StorageAreaImpl.h:
(StorageAreaImpl):
Source/WebKit2:
Remove security checking code that lives in Storage now.
- WebProcess/Storage/StorageAreaImpl.cpp:
(WebKit::StorageAreaImpl::setItem):
(WebKit::StorageAreaImpl::removeItem):
(WebKit::StorageAreaImpl::clear):
- WebProcess/Storage/StorageAreaImpl.h:
- 4:40 PM Changeset in webkit [150345] by
-
- 2 edits in trunk/Source/WebKit2
Fix some builds.
- UIProcess/API/mac/WKTypeRefWrapper.mm:
- 4:15 PM Changeset in webkit [150344] by
-
- 2 edits in trunk/Source/WebKit2
REGRESSION(r150305): WebKit2 build broken with INDEXED_DATABASE enabled
https://bugs.webkit.org/show_bug.cgi?id=116389
Patch by Carlos Garcia Campos <cgarcia@igalia.com> on 2013-05-18
Reviewed by Martin Robinson.
There's no longer WebKeyValueStorageManager in the web process
after r150305.
- WebProcess/WebPage/WebPageGroupProxy.cpp:
(WebKit::WebPageGroupProxy::WebPageGroupProxy):
- 3:41 PM Changeset in webkit [150343] by
-
- 3 edits2 adds in trunk/Source/WebKit2
Add a way to pass WebKit2 WKTypeRefs in Objective-C style user data messages
https://bugs.webkit.org/show_bug.cgi?id=116345
Reviewed by Anders Carlsson.
In order to efficiently send a WKImageRef to another process when using the
Objective-C WKConnection (or other user data messages), we need a way to encode
WKTypeRefs in the objective-c object graph. Thus was born WKTypeRefWrapper.
- Shared/mac/ObjCObjectGraphCoders.mm:
(WebKit::typeFromObject):
(WebKit::WebContextObjCObjectGraphEncoderImpl::encode):
(WebKit::WebContextObjCObjectGraphDecoderImpl::decode):
(WebKit::InjectedBundleObjCObjectGraphEncoderImpl::encode):
(WebKit::InjectedBundleObjCObjectGraphDecoderImpl::decode):
- UIProcess/API/mac/WKTypeRefWrapper.h: Added.
- UIProcess/API/mac/WKTypeRefWrapper.mm: Added.
(-[WKTypeRefWrapper initWithObject:]):
(-[WKTypeRefWrapper object]):
- WebKit2.xcodeproj/project.pbxproj:
- 3:11 PM Changeset in webkit [150342] by
-
- 9 edits in trunk/Source
Simplify StorageArea getter functions
https://bugs.webkit.org/show_bug.cgi?id=116399
Reviewed by Sam Weinig.
Source/WebCore:
Move the security and private browsing checks from StorageArea to Storage so we can share
more code between WebKit1 and WebKit2.
- inspector/InspectorDOMStorageAgent.cpp:
(WebCore::InspectorDOMStorageAgent::getDOMStorageItems):
Update to new StorageArea interface. The security checks are unnecessary here anyway because
InspectorDOMStorageAgent::findStorageArea will only return a StorageArea that can be accessed
by the frame's security origin.
- storage/Storage.cpp:
(WebCore::Storage::key):
(WebCore::Storage::getItem):
(WebCore::Storage::contains):
- storage/StorageArea.h:
(StorageArea):
- storage/StorageAreaImpl.cpp:
(WebCore::StorageAreaImpl::key):
(WebCore::StorageAreaImpl::item):
(WebCore::StorageAreaImpl::contains):
- storage/StorageAreaImpl.h:
(StorageAreaImpl):
Source/WebKit2:
Remove security and private browsing checks.
- WebProcess/Storage/StorageAreaImpl.cpp:
(WebKit::StorageAreaImpl::key):
(WebKit::StorageAreaImpl::item):
(WebKit::StorageAreaImpl::contains):
- WebProcess/Storage/StorageAreaImpl.h:
- 12:27 PM Changeset in webkit [150341] by
-
- 2 edits1 add in trunk/PerformanceTests
Add a performance test for copying
https://bugs.webkit.org/show_bug.cgi?id=116394
Reviewed by Andreas Kling.
Added. We're going to skip this test by default since it's such a microbenchmark, and also because
it currently takes 30 minutes to run. As insane as it sounds, each copy takes rouhgly 57 seconds.
Running Interactive/CopyAll.html (1 of 1)
RESULT Interactive: CopyAll: Time= 57618.05 ms
median= 57135.0 ms, stdev= 1542.07271571 ms, min= 55095.0 ms, max= 60913.0 ms
RESULT Interactive: CopyAll: JSHeap= 102811.2 bytes
median= 103272.0 bytes, stdev= 1115.28148913 bytes, min= 100648.0 bytes, max= 103504.0 bytes
RESULT Interactive: CopyAll: Malloc= 446408712.0 bytes
median= 459156772.0 bytes, stdev= 20007346.3266 bytes, min= 415564040.0 bytes, max= 462011928.0 bytes
Finished: 1766.883236 s
- Interactive/CopyAll.html: Added.
- Skipped:
- 12:09 PM Changeset in webkit [150340] by
-
- 2 edits in trunk/Source/WebCore
Garbage on page background while http://canberraballoons.com.au is loading
https://bugs.webkit.org/show_bug.cgi?id=116384
<rdar://problem/13930328>
Reviewed by Dan Bernstein.
This page loads a large JPEG image as the body background.
ImageSource::frameHasAlphaAtIndex() always claims that JPEG images
are opaque, but this isn't true if the frame is only partially loaded.
However, this would cause FillLayer::hasOpaqueImage() to report that the
background image is opaque, so we'd skip painting the background color.
Unpainted content in an opaque layer results in garbage.
Fix by having ImageSource::frameHasAlphaAtIndex() always return true
for frames that are not complete. When the image load completes, we
recompute metadata and correctly determine that the frame is opaque.
- platform/graphics/cg/ImageSourceCG.cpp:
(WebCore::ImageSource::frameHasAlphaAtIndex):
- 9:06 AM Changeset in webkit [150339] by
-
- 2 edits in trunk/Source/WebCore
Simplify EventLoop::cycle() on Mac.
Reviewed by Anders Carlsson.
- platform/mac/EventLoopMac.mm:
(WebCore::EventLoop::cycle): Use CFRunLoopRunInMode instead.
- 9:06 AM Changeset in webkit [150338] by
-
- 3 edits in branches/dfgFourthTier/Source/JavaScriptCore
fourthTier: getCTIStub should be thread-safe
https://bugs.webkit.org/show_bug.cgi?id=116126
Reviewed by Dan Bernstein.
It's called from the compilation thread. Give it locks.
- jit/JITThunks.cpp:
(JSC::JITThunks::ctiStub):
(JSC::JITThunks::hostFunctionStub):
- jit/JITThunks.h:
(JITThunks):
- 8:02 AM Changeset in webkit [150337] by
-
- 2 edits in trunk/Source/WebCore
Use CSSParserSelector::appendTagHistory() from CSS grammar.
<http://webkit.org/b/116382>
Reviewed by Antti Koivisto.
CSSParserSelector already knows how to append another component to itself,
no need to duplicate that logic in the grammar.
- css/CSSGrammar.y.in:
- 4:36 AM Changeset in webkit [150336] by
-
- 36 edits in trunk
[CMake] Replace *_LIBRARY_NAME with *_OUTPUT_NAME
https://bugs.webkit.org/show_bug.cgi?id=114554
Reviewed by Gyuyoung Kim.
Using variables as target names is very uncommon in CMake.
The usual way to specify the name of the resulting binary
is to set the OUTPUT_NAME target property.
.:
- CMakeLists.txt:
- Source/CMakeLists.txt:
- Source/PlatformEfl.cmake:
- Source/PlatformGTK.cmake:
- Source/cmake/OptionsBlackBerry.cmake:
- Source/cmake/OptionsEfl.cmake:
- Source/cmake/OptionsGTK.cmake:
- Source/cmake/WebKitHelpers.cmake:
- Source/cmake/gtest/CMakeLists.txt:
Source/JavaScriptCore:
- CMakeLists.txt:
- shell/CMakeLists.txt:
Source/WebCore:
- CMakeLists.txt:
Source/WebKit:
- CMakeLists.txt:
- PlatformBlackBerry.cmake:
- PlatformEfl.cmake:
Source/WebKit/efl:
- ewebkit.pc.in:
Source/WebKit2:
- CMakeLists.txt:
- PlatformEfl.cmake:
- efl/ewebkit2.pc.in:
Source/WTF:
- wtf/CMakeLists.txt:
Tools:
- DumpRenderTree/efl/CMakeLists.txt:
- EWebLauncher/CMakeLists.txt:
- ImageDiff/CMakeLists.txt:
- MiniBrowser/efl/CMakeLists.txt:
- TestWebKitAPI/CMakeLists.txt:
- WebKitTestRunner/CMakeLists.txt:
- WebKitTestRunner/PlatformEfl.cmake:
- WinCELauncher/CMakeLists.txt:
- 2:14 AM Changeset in webkit [150335] by
-
- 6 edits in trunk
Unreviewed EFL build fix.
.:
Temporarily disabled INDEXED_DATABASE at compile-time as it breaks
WK2 build after r150305.
- Source/cmake/OptionsEfl.cmake:
Tools:
Temporarily disabled INDEXED_DATABASE at compile-time as it breaks
WK2 build after r150305.
- Scripts/webkitperl/FeatureList.pm:
LayoutTests:
Skip indexeddb test cases as the feature is temporarily disabled due to
r150305.
- platform/efl/TestExpectations:
- 2:12 AM Changeset in webkit [150334] by
-
- 13 edits1 delete in trunk/Source
[GTK] Move GTK port off legacy clipboard
https://bugs.webkit.org/show_bug.cgi?id=116221
Reviewed by Martin Robinson.
Source/WebCore:
Merge clipboard methods into PasteboardGtk that now wraps a
DataObjectGtk.
- GNUmakefile.list.am: Remove ClipboardGtk.h.
- dom/Clipboard.h: Remove GTK from the list of ports using legacy
clipboard.
- page/gtk/EventHandlerGtk.cpp:
(WebCore::EventHandler::createDraggingClipboard): Use
Clipboard::createForDragAndDrop().
- platform/Pasteboard.h:
(Pasteboard):
- platform/gtk/ClipboardGtk.cpp:
(WebCore::Editor::newGeneralClipboard): Use
Clipboard::createForCopyAndPaste().
(WebCore::Clipboard::createDragImage):
(WebCore::Clipboard::declareAndWriteDragImage):
- platform/gtk/ClipboardGtk.h: Removed.
- platform/gtk/DragDataGtk.cpp:
- platform/gtk/PasteboardGtk.cpp:
(WebCore::Pasteboard::create): Create a new Pasteboard for a given
GtkClipboard or DataObjectGtk.
(WebCore::Pasteboard::createForCopyAndPaste): Create a Pasteboard
for the GDK_SELECTION_CLIPBOARD clipboard.
(WebCore::Pasteboard::createPrivate): Create a Pasteboard without
a GtkClipboard associated.
(WebCore::Pasteboard::createForDragAndDrop): Create a Pasteboard
for drag and drop operations.
(WebCore::selectionClipboard): Return a static Pasteboard for the
GDK_SELECTION_CLIPBOARD clipboard.
(WebCore::primaryClipboard): Return a static Pasteboard for the
GDK_SELECTION_PRIMARY clipboard.
(WebCore::Pasteboard::generalPasteboard): Return
selectionClipboard() or primaryClipboard() depending on whether
primary selection clipboard is the active one or not.
(WebCore::Pasteboard::Pasteboard):
(WebCore::Pasteboard::~Pasteboard):
(WebCore::Pasteboard::dataObject): Return the wrapped DataObjectGtk.
(WebCore::dataObjectTypeFromHTMLClipboardType): Copied from
ClipboardGtk.cpp.
(WebCore::Pasteboard::writeString): Adapted to upate the wrapped
DataObjectGtk and the GtkClipboard if needed.
(WebCore::Pasteboard::writeSelection): Ditto.
(WebCore::Pasteboard::writePlainText): Ditto.
(WebCore::Pasteboard::writeURL): Ditto.
(WebCore::Pasteboard::writeImage): Ditto.
(WebCore::Pasteboard::writePasteboard): Copy the wrapped
DataObjectGtk from the DataObjectGtk of the given Pasteboard and
upsate the GtkClipboard if needed.
(WebCore::Pasteboard::clear): Copied from ClipboardGtk.cpp.
(WebCore::Pasteboard::canSmartReplace): Check if current
GtkClipboard supports smart replace.
(WebCore::Pasteboard::setDragImage):
(WebCore::Pasteboard::documentFragment): Adapted to use the
wrapped DataObjectGtk reading from the current GtkClipboard if
present.
(WebCore::Pasteboard::plainText): Ditto.
(WebCore::Pasteboard::hasData): Copied from ClipboardGtk.cpp.
(WebCore::Pasteboard::types): Ditto.
(WebCore::Pasteboard::readString): Ditto.
(WebCore::Pasteboard::readFilenames): Ditto.
Source/WebKit/gtk:
- WebCoreSupport/DragClientGtk.cpp:
(WebKit::DragClient::startDrag): Get the DataObjectGtk from the
Pasteboard associated to the given Clipboard.
Source/WebKit2:
- UIProcess/API/gtk/WebKitWebViewBase.cpp: Remove ClipboardGtk.h
include.
- WebProcess/WebCoreSupport/gtk/WebDragClientGtk.cpp:
(WebKit::WebDragClient::startDrag): Get the DataObjectGtk from the
Pasteboard associated to the given Clipboard.
- 1:51 AM Changeset in webkit [150333] by
-
- 20 edits in trunk/LayoutTests
Mac rebaseline after r148944.
- platform/mac/TestExpectations:
- platform/mac/fast/table/giantRowspan-expected.txt:
- platform/mac/fast/table/giantRowspan2-expected.png:
- platform/mac/fast/table/giantRowspan2-expected.txt:
- platform/mac/tables/mozilla/bugs/bug133756-1-expected.txt:
- platform/mac/tables/mozilla/bugs/bug133756-2-expected.png:
- platform/mac/tables/mozilla/bugs/bug133756-2-expected.txt:
- platform/mac/tables/mozilla/bugs/bug220536-expected.png:
- platform/mac/tables/mozilla/bugs/bug220536-expected.txt:
- platform/mac/tables/mozilla/bugs/bug8858-expected.txt:
- platform/mac/tables/mozilla/core/bloomberg-expected.png:
- platform/mac/tables/mozilla/core/bloomberg-expected.txt:
- platform/mac/tables/mozilla/core/row_span-expected.png:
- platform/mac/tables/mozilla/core/row_span-expected.txt:
- platform/mac/tables/mozilla_expected_failures/bugs/bug131020-3-expected.txt:
- platform/mac/tables/mozilla_expected_failures/bugs/bug23847-expected.png:
- platform/mac/tables/mozilla_expected_failures/bugs/bug23847-expected.txt:
- platform/mac/tables/mozilla_expected_failures/bugs/bug65372-expected.png:
- platform/mac/tables/mozilla_expected_failures/bugs/bug65372-expected.txt:
- 1:48 AM Changeset in webkit [150332] by
-
- 5 edits in trunk/Source/WebKit2
[EFL][WK2] Refactor ewk_view_custom_encoding_set/get API
https://bugs.webkit.org/show_bug.cgi?id=116386
Patch by Jinwoo Song <jinwoo7.song@samsung.com> on 2013-05-18
Reviewed by Christophe Dumez.
Refactor the API to handle 'const char*' parameter in right way and
enable the unit test which was disabled in r136230 as there is no assertion now.
- UIProcess/API/efl/EwkView.cpp:
(EwkView::setCustomTextEncodingName):
- UIProcess/API/efl/EwkView.h:
(EwkView::customTextEncodingName):
(EwkView):
- UIProcess/API/efl/ewk_view.cpp:
(ewk_view_custom_encoding_set):
- UIProcess/API/efl/tests/test_ewk2_view.cpp:
(TEST_F):
- 1:39 AM Changeset in webkit [150331] by
-
- 2 edits in trunk/LayoutTests
REGRESSION: [Mac] fast/js/post-message-numeric-property.html is flaky
https://bugs.webkit.org/show_bug.cgi?id=116388
Add a flaky test expectation.
- platform/mac/TestExpectations:
- 1:34 AM Changeset in webkit [150330] by
-
- 2 edits2 adds in trunk/LayoutTests
Mac Lion rebaselines after r149999 and r150260.
- platform/mac-lion/fast/js/global-constructors-attributes-expected.txt:
- platform/mac-lion/media/track: Added.
- platform/mac-lion/media/track/track-cue-rendering-vertical-expected.txt: Added.
- 1:17 AM Changeset in webkit [150329] by
-
- 2 edits in trunk/Source/WebKit2
[CMake] Unreviewed speculative build fix after r150305 and r150306.
- CMakeLists.txt:
- 1:11 AM Changeset in webkit [150328] by
-
- 2 edits in trunk/Source/WebKit/qt
[Qt] REGRESSION(r150227): It made zillion tests crash under PlatformStrategiesQt::getPluginInfo
https://bugs.webkit.org/show_bug.cgi?id=116289
Patch by Tim Horton <timothy_horton@apple.com> on 2013-05-18
Reviewed by Csaba Osztrogonác.
Don't try to static cast something that isn't a ChromeClientQt to ChromeClientQt.
It's actually SVGImage's EmptyChromeClient-derived client (or other such things).
- WebCoreSupport/PlatformStrategiesQt.cpp:
(PlatformStrategiesQt::getPluginInfo):
- 12:33 AM Changeset in webkit [150327] by
-
- 3 edits in trunk/Source/WebKit2
[Qt][WK2] Unreviewed build fix after r150305 and r150306.
- DerivedSources.pri:
- Target.pri:
- 12:19 AM Changeset in webkit [150326] by
-
- 6 edits in trunk
[GTK] Parallel build fails if gtk-doc is enabled
https://bugs.webkit.org/show_bug.cgi?id=116227
Patch by Alberto Garcia <agarcia@igalia.com> on 2013-05-18
Reviewed by Martin Robinson.
.:
- GNUmakefile.am:
Define an empty noinst_DATA variable where other automake files
can add additional objects to be built.
Source/WebCore:
- GNUmakefile.am:
Don't overwrite noinst_DATA, modify its existing value instead.
Tools:
- GNUmakefile.am:
Don't use the 'all' target to generate the documentation.
The prerequisites of this target must be files that need to be
built _before_ the actual compilation of WebKit starts. Since the
documentation depends on WebKit being built first, this means in
practice that the code will be built in parallel with the
generation of its dependencies, potentially making the build fail.
- 12:12 AM Changeset in webkit [150325] by
-
- 2 edits in trunk/Source/WebKit2
Unreviewed build fix for the GTK port after r150305 and r150306.
- GNUmakefile.list.am:
