Timeline
Dec 22, 2013:
- 10:20 PM Changeset in webkit [160986] by
-
- 5 edits in trunk/Source/WebKit2
[WK2][SOUP] WebContext::allowSpecificHTTPSCertificateForHost does not work correctly when m_usesNetworkProcess is false
https://bugs.webkit.org/show_bug.cgi?id=125564
Reviewed Carlos Garcia Campos.
WebContext::allowSpecificHTTPSCertificateForHost should send
AllowSpecificHTTPSCertificateForHost to the web process when
m_usesNetworkProcess is false. Also we shouldn't guard
WebProcess::allowSpecificHTTPSCertificateForHost with
!ENABLE(NETWORK_PROCESS) because we need this method when
m_usesNetworkProcess is false.
Patch by Kwang Yul Seo <skyul@company100.net> on 2013-12-22
- UIProcess/WebContext.cpp:
(WebKit::WebContext::allowSpecificHTTPSCertificateForHost):
- WebProcess/WebProcess.h:
- WebProcess/WebProcess.messages.in:
- WebProcess/soup/WebProcessSoup.cpp:
- 10:08 PM Changeset in webkit [160985] by
-
- 6 edits2 adds in trunk
[GTK][CMake] Integrate GResource for inspector files (and others?)
https://bugs.webkit.org/show_bug.cgi?id=125569
Reviewed by Gustavo Noronha Silva.
Source/WebInspectorUI:
- GNUmakefile.am: Use the new generation script instead of generating with
shell scripting in the makefile.
Source/WebKit2:
- GNUmakefile.am: Use the newly added static WebKit2InspectorGResourceBundle.xml
instead of generating the same file each time.
- PlatformGTK.cmake: Add support for building the GResource bundles into WebKit2.
- UIProcess/API/gtk/WebKit2InspectorGResourceBundle.xml: Added.
Tools:
- gtk/generate-inspector-gresource-manifest.py: Added.
- 8:40 PM Changeset in webkit [160984] by
-
- 2 edits in trunk/Source/WebKit
Small build fix for GTK+ with the CMake build
- CMakeLists.txt: Remove duplicate include directory and add missing directories
necessary for GTK+.
- 4:45 PM Changeset in webkit [160983] by
-
- 8 edits2 adds in trunk/Source
Create a skeleton for CSS Selector code generation
https://bugs.webkit.org/show_bug.cgi?id=126044
Source/JavaScriptCore:
Reviewed by Antti Koivisto and Gavin Barraclough.
- assembler/LinkBuffer.h:
Add a new owner UID for code compiled for CSS.
Export the symbols needed to link code from WebCore.
Source/WebCore:
Patch by Benjamin Poulain <bpoulain@apple.com> on 2013-12-22
Reviewed by Antti Koivisto and Gavin Barraclough.
Add CSSCompiler, which provides the basic infrastructure to compile
CSS Selectors on x86_64.
Compilation happens in two phases.
1) The various matching and relation of each CSSSelector is aggregated into units
matching a single element: SelectorFragment.
SelectorFragment also knows about the relations between different fragments,
and contains all the information to generate the code for a particular element.
2) The compiler then goes over the fragments, and generate code based on the information
of each fragment.
It the current state, SelectorCompiler only compiles the tag matching selectors and
any of the relation between selectors.
Depending on the relation and position of a fragment, failure on traversal or matching
does not necessarily causes the complete selector. A failure can cause matching to
resume from the parent or the sibling of a previously visisted node.
The implementation of this is done through the BacktrackingAction. In case of failure,
the next starting state is setup and the program counter jumps back to the appropriate
starting point.
When backtracking, the method used to save the starting point depends on the type
of backtracking.
The child/parent relation (">") is very common so it uses an additional register to keep
the next starting point (m_descendantBacktrackingStart).
The indirect sibling relation ("~") is much less common and uses the stack to save
the next starting point.
- WebCore.xcodeproj/project.pbxproj:
- cssjit/SelectorCompiler.cpp: Added.
(WebCore::SelectorCompiler::SelectorFragment::SelectorFragment):
(WebCore::SelectorCompiler::compileSelector):
(WebCore::SelectorCompiler::fragmentRelationForSelectorRelation):
(WebCore::SelectorCompiler::SelectorCodeGenerator::SelectorCodeGenerator):
(WebCore::SelectorCompiler::SelectorCodeGenerator::compile):
(WebCore::SelectorCompiler::updateChainStates):
(WebCore::SelectorCompiler::isFirstAncestor):
(WebCore::SelectorCompiler::isFirstAdjacent):
(WebCore::SelectorCompiler::isAfterChildRelation):
(WebCore::SelectorCompiler::solveBacktrackingAction):
(WebCore::SelectorCompiler::requiresAdjacentTail):
(WebCore::SelectorCompiler::requiresDescendantTail):
(WebCore::SelectorCompiler::SelectorCodeGenerator::computeBacktrackingInformation):
(WebCore::SelectorCompiler::testIsElementFlagOnNode):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateWalkToParentElement):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateParentElementTreeWalker):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateAncestorTreeWalker):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateWalkToPreviousAdjacent):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateDirectAdjacentTreeWalker):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateIndirectAdjacentTreeWalker):
(WebCore::SelectorCompiler::SelectorCodeGenerator::markParentElementIfResolvingStyle):
(WebCore::SelectorCompiler::SelectorCodeGenerator::linkFailures):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateAdjacentBacktrackingTail):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateDescendantBacktrackingTail):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateBacktrackingTailsIfNeeded):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateElementMatching):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateElementHasTagName):
- cssjit/SelectorCompiler.h: Added.
(WebCore::SelectorCompilationStatus::SelectorCompilationStatus):
(WebCore::SelectorCompilationStatus::operator Status):
(WebCore::SelectorCompiler::simpleSelectorCheckerFunction):
(WebCore::SelectorCompiler::selectorCheckerFunctionWithCheckingContext):
- dom/Element.cpp:
(WebCore::Element::setChildrenAffectedByDirectAdjacentRules):
(WebCore::Element::setChildrenAffectedByForwardPositionalRules):
- dom/Element.h:
(WebCore::Element::tagQNameMemoryOffset):
(WebCore::Element::setChildrenAffectedByForwardPositionalRules):
- dom/Node.h:
(WebCore::Node::parentNodeMemoryOffset):
(WebCore::Node::previousSiblingMemoryOffset):
(WebCore::Node::nodeFlagsMemoryOffset):
(WebCore::Node::flagIsElement):
- dom/QualifiedName.h:
(WebCore::QualifiedName::QualifiedNameImpl::localNameMemoryOffset):
(WebCore::QualifiedName::QualifiedNameImpl::namespaceMemoryOffset):
(WebCore::QualifiedName::implMemoryOffset):
- 4:02 PM Changeset in webkit [160982] by
-
- 4 edits in branches/jsCStack/Source/JavaScriptCore
CStack: Add #if ENABLE(LLINT_C_LOOP) to C loop LLINT only parts of JSStack.
https://bugs.webkit.org/show_bug.cgi?id=126140.
Not yet reviewed.
Also moved startOfFrameFor() to the ENABLE(DEBUG_JSSTACK) section because
it's only needed there.
- interpreter/JSStack.cpp:
(JSC::JSStack::JSStack):
(JSC::JSStack::gatherConservativeRoots):
(JSC::JSStack::sanitizeStack):
- interpreter/JSStack.h:
(JSC::JSStack::gatherConservativeRoots):
(JSC::JSStack::sanitizeStack):
(JSC::JSStack::initializeThreading):
- interpreter/JSStackInlines.h:
(JSC::JSStack::topOfFrameFor):
- 2:26 PM Changeset in webkit [160981] by
-
- 3 edits in branches/jsCStack/Source/JavaScriptCore
CStack: Fixed some JSStack on C Stack boundary computations.
https://bugs.webkit.org/show_bug.cgi?id=126139.
Not yet reviewed.
- Implement committedByteCount() for JSStack on the C stack using the current stack usage as an estimate of committed stack memory.
- Implement lowAddress() and highAddress() for JSStack on the C stack for containsAddress(). lowAddress() will be the top of the JS stack. highAddress() will be 1 past the end of the JS stack.
- Moved some functions around in preparation for an upcoming patch to #if out code which is only used when ENABLE(LLINT_C_LOOP)
- interpreter/JSStack.cpp:
(JSC::JSStack::lowAddress):
(JSC::JSStack::highAddress):
(JSC::JSStack::committedByteCount):
- interpreter/JSStack.h:
(JSC::JSStack::containsAddress):
(JSC::JSStack::lowAddress):
- 10:42 AM Changeset in webkit [160980] by
-
- 19 edits in branches/jsCStack/Source/JavaScriptCore
It should be possible to run the full version of V8v7/crypto with the FTL and call IC's
https://bugs.webkit.org/show_bug.cgi?id=126116
Not yet reviewed.
This involved a number of minor fixes:
- CallLinkInfo::unlink() was assuming that repatchBuffer.codeBlock() is the caller. It's actually the callee. So, to determine if the caller requires register preservation, we need an extra bit to say whether the CallLinkInfo belongs to an FTL JITCode.
- A lot of bugs arise from us incorrectly preserving (or failing to preserve) registers. This adds a bunch of jitAssertTagsInPlace() assertion that helps to catch a bunch of those bugs.
- Apparently the compact_unwind sometimes has garbage after its one entry. This changes our unwind parser so that it doesn't assert that the second entry is null, but it does assert that the first entry corresponds to our generated function.
- The native function thunks assume that tags are set up and that they can clobber any registers. This breaks if we call the thunks from the FTL. This patch fixes the bug by wrapping just those thunks in a DirectJITCode, which has the register preservation wrappers. This probably ends up making sense because the FTL *really* should have intrinsics for all of those thunks. As part of this change, I refactored how NativeExecutable gets its JITCode to make things somewhat more explicit.
We still have a bunch of known performance bugs to fix, but the FTL is already at near
parity with the DFG on V8v7/crypto. This is pretty cool considering the FTL's other
speed-ups, and the fact that crypto has been our primary DFG tuning test for the past
2.5 years.
- bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::unlink):
- bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::CallLinkInfo):
- dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compileEntry):
- dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
- dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::adjustAndJumpToTarget):
- dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
- ftl/FTLCompile.cpp:
(JSC::FTL::compile):
- ftl/FTLJSCall.cpp:
(JSC::FTL::JSCall::link):
- ftl/FTLUnwindInfo.cpp:
(JSC::FTL::UnwindInfo::parse):
- ftl/FTLUnwindInfo.h:
- jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::jitAssertTagsInPlace):
- jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::jitAssertTagsInPlace):
- jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
- jit/JITCode.cpp:
- jit/JITCode.h:
- jit/JITThunks.cpp:
(JSC::JITThunks::hostFunctionStub):
- jit/RegisterPreservationWrapperGenerator.cpp:
(JSC::generateRegisterPreservationWrapper):
- runtime/Executable.h:
(JSC::NativeExecutable::create):
- 10:15 AM Changeset in webkit [160979] by
-
- 3 edits2 adds in trunk
[CSSRegions] Crash when trying to select content from invalid region
https://bugs.webkit.org/show_bug.cgi?id=126113
Reviewed by Antti Koivisto.
Source/WebCore:
After fix for https://bugs.webkit.org/show_bug.cgi?id=120769, positionForPoint for a region attempts to use the associated named flow to perform its task.
However, this should happen only when the region is valid. If the region is invalid, part of a dependency cycle, positionForPoint should behave as usual
for a block instead of a region, otherwise it may run into an infinite loop due to cyclic dependencies and a crash will occur.
This patch ensures that positionForPoint region specifie behaviour is followed only if the region is valid - not part of a dependency cycle.
Test: fast/regions/selection/invalid-region-selection-crash.html
- rendering/RenderRegion.cpp:
(WebCore::RenderRegion::positionForPoint):
LayoutTests:
- fast/regions/selection/invalid-region-selection-crash-expected.txt: Added.
- fast/regions/selection/invalid-region-selection-crash.html: Added.
- 10:03 AM Changeset in webkit [160978] by
-
- 9 edits in trunk/LayoutTests
[CSSRegions] Clean-up selection tests a bit
https://bugs.webkit.org/show_bug.cgi?id=126135
Reviewed by Dirk Schulze.
Move function clearSelection in helper.js. Combine checkResult() from position-for-point* and position-for-point-1*
into a single function, checkSelectionResult() and move it into helper.js too.
- fast/regions/resources/helper.js:
- fast/regions/selection/position-for-point-1-vert-lr.html:
- fast/regions/selection/position-for-point-1-vert-rl.html:
- fast/regions/selection/position-for-point-1.html:
- fast/regions/selection/position-for-point-vert-lr.html:
- fast/regions/selection/position-for-point-vert-rl.html:
- fast/regions/selection/position-for-point.html:
- fast/regions/selection/selecting-text-through-different-region-flows.html:
- 8:45 AM Changeset in webkit [160977] by
-
- 24 edits in trunk/Source/WebKit2
URTBF after r160971 to try to make EFL build again.
Patch by Csaba Osztrogonác <Csaba Osztrogonác> on 2013-12-22
- WebProcess/WebCoreSupport/efl/WebErrorsEfl.cpp:
(WebKit::internalError):
- 8:33 AM Changeset in webkit [160976] by
-
- 3 edits in trunk/Tools
Last URTBF after r160971 to make EFL build happy.
- TestWebKitAPI/efl/PlatformWebView.cpp:
- WebKitTestRunner/efl/PlatformWebViewEfl.cpp:
- 7:45 AM Changeset in webkit [160975] by
-
- 2 edits in trunk/Source/WebKit2
URTBF after r160971 to try to make EFL build again.
- WebProcess/WebCoreSupport/efl/WebErrorsEfl.cpp:
(WebKit::internalError):
- 1:09 AM Changeset in webkit [160974] by
-
- 9 edits in trunk/Source/WebKit2
Unreviewed. Fix GTK+ build after r160971 and r160969.
- GNUmakefile.list.am:
- UIProcess/API/gtk/WebKitFileChooserRequest.cpp:
(webkit_file_chooser_request_select_files):
- UIProcess/API/gtk/WebKitInjectedBundleClient.cpp:
(didReceiveWebViewMessageFromInjectedBundle):
- UIProcess/API/gtk/WebKitURISchemeRequest.cpp:
(webkitURISchemeRequestCreate):
- UIProcess/API/gtk/WebKitURISchemeRequestPrivate.h:
- UIProcess/API/gtk/WebKitWebResource.cpp:
(webkit_web_resource_get_data):
- UIProcess/soup/WebSoupRequestManagerClient.h:
- WebProcess/WebCoreSupport/gtk/WebErrorsGtk.cpp:
(WebKit::internalError):
Dec 21, 2013:
- 11:01 PM Changeset in webkit [160973] by
-
- 3 edits in trunk/Source/WebCore
Start refactoring Filter code to reuse CachedSVGDocument for clipPath
https://bugs.webkit.org/show_bug.cgi?id=126069
Reviewed by Andreas Kling.
Smaller refactoring of the CSS filter style resolver code. Previously the code
requested the FilterOperations list from RenderStyle and compared the content
in this list with an internal map. Then the resource loading was triggered.
With the refactoring we do not request the list from RenderStyle anymore but
rely on the hash map data entirely.
- css/StyleResolver.cpp:
(WebCore::StyleResolver::loadPendingSVGDocuments):
- platform/graphics/filters/FilterOperation.h:
- 6:45 PM Changeset in webkit [160972] by
-
- 4 edits in trunk/Source/WebKit2
Unreviewed build fix attempt on EFL port after r160971 and r160969
- CMakeLists.txt:
- UIProcess/soup/WebSoupRequestManagerClient.cpp:
(WebKit::WebSoupRequestManagerClient::didReceiveURIRequest):
- UIProcess/soup/WebSoupRequestManagerProxy.cpp:
(WebKit::WebSoupRequestManagerProxy::didReceiveURIRequest):
- 6:18 PM Changeset in webkit [160971] by
-
- 16 edits2 moves in trunk/Source/WebKit2
[WK2] Rename WebError to API::Error
https://bugs.webkit.org/show_bug.cgi?id=126125
Reviewed by Anders Carlsson.
- Shared/API/c/WKError.cpp:
(WKErrorGetTypeID):
(WKErrorCopyWKErrorDomain):
- Shared/API/c/WKSharedAPICast.h:
(WebKit::toAPI):
- Shared/API/c/cf/WKErrorCF.cpp:
(WKErrorCreateWithCFError):
- Shared/APIError.cpp: Copied from Source/WebKit2/Shared/WebError.cpp.
(API::Error::webKitErrorDomain):
(API::Error::encode):
(API::Error::decode):
- Shared/APIError.h: Copied from Source/WebKit2/Shared/WebError.h.
(API::Error::create):
(API::Error::domain):
(API::Error::failingURL):
(API::Error::localizedDescription):
(API::Error::Error):
- Shared/Cocoa/WKNSError.h:
(WebKit::wrapper):
- Shared/Cocoa/WKNSError.mm:
(-[WKNSError _web_createTarget]):
- Shared/UserData.cpp:
(WebKit::UserData::encode):
(WebKit::UserData::decode):
- Shared/UserMessageCoders.h:
(WebKit::UserMessageEncoder::baseEncode):
(WebKit::UserMessageDecoder::baseDecode):
- Shared/WebError.cpp: Removed.
- Shared/WebError.h: Removed.
- UIProcess/AutoCorrectionCallback.h:
(WebKit::AutocorrectionDataCallback::invalidate):
- UIProcess/GenericCallback.h:
(WebKit::VoidCallback::invalidate):
(WebKit::GenericCallback::invalidate):
(WebKit::ComputedPagesCallback::invalidate):
(WebKit::ImageCallback::invalidate):
- UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::printFinishedCallback):
- UIProcess/WebPageProxy.h:
(WebKit::ValidateCommandCallback::invalidate):
(WebKit::GestureCallback::invalidate):
(WebKit::TouchesCallback::invalidate):
- WebKit2.xcodeproj/project.pbxproj:
- WebProcess/InjectedBundle/InjectedBundlePageLoaderClient.cpp:
- WebProcess/InjectedBundle/InjectedBundlePagePolicyClient.cpp:
- WebProcess/WebCoreSupport/mac/WebErrorsMac.mm:
(WebKit::blockedError):
(WebKit::cannotShowURLError):
(WebKit::interruptedForPolicyChangeError):
(WebKit::cannotShowMIMETypeError):
(WebKit::pluginWillHandleLoadError):
(WebKit::internalError):
- 5:04 PM Changeset in webkit [160970] by
-
- 5 edits in trunk/Source/WebCore
[Mac] Soft-link WebContentAnalysis.framework
https://bugs.webkit.org/show_bug.cgi?id=126102
Reviewed by Dan Bernstein.
- Configurations/WebCore.xcconfig: There's no need to modify LDFLAGS
now that we don't hard link against WebContentAnalysis.framework.
- WebCore.xcodeproj/project.pbxproj: Removed
WebContentAnalysis.framework from the 'Link Binary with Libraries'
build phase.
- platform/mac/ContentFilterMac.mm: Soft-linked
WebContentAnalysis.framework and the WebFilterEvaluator @class.
(WebCore::ContentFilter::ContentFilter): Called getWebFilterEvaluatorClass().
(WebCore::ContentFilter::isEnabled): Ditto.
- platform/mac/SoftLinking.h: Added an implementation of
SOFT_LINK_PRIVATE_FRAMEWORK().
- 4:57 PM Changeset in webkit [160969] by
-
- 20 edits1 move in trunk/Source/WebKit2
[WK2] Rename WebURL to API::URL
https://bugs.webkit.org/show_bug.cgi?id=126100
Reviewed by Anders Carlsson.
- Shared/API/c/WKSharedAPICast.h:
(WebKit::toURLRef):
(WebKit::toCopiedURLAPI):
- Shared/API/c/WKURL.cpp:
(WKURLGetTypeID):
(WKURLCreateWithUTF8CString):
(WKURLCreateWithBaseURL):
- Shared/API/c/cf/WKURLCF.mm:
(WKURLCreateWithCFURL):
- Shared/APIURL.h: Copied from Source/WebKit2/Shared/WebURL.h.
(API::URL::create):
(API::URL::string):
(API::URL::host):
(API::URL::protocol):
(API::URL::path):
(API::URL::lastPathComponent):
(API::URL::encode):
(API::URL::decode):
(API::URL::URL):
- Shared/Cocoa/WKNSURL.h:
(WebKit::wrapper):
- Shared/Cocoa/WKNSURL.mm:
(-[WKNSURL _web_createTarget]):
- Shared/Plugins/Netscape/PluginInformation.cpp:
(WebKit::createPluginInformationDictionary):
- Shared/UserData.cpp:
(WebKit::UserData::encode):
(WebKit::UserData::decode):
- Shared/UserMessageCoders.h:
(WebKit::UserMessageEncoder::baseEncode):
(WebKit::UserMessageDecoder::baseDecode):
- Shared/WebArchiveResource.h:
- Shared/WebURL.h: Removed.
- UIProcess/WebFrameProxy.cpp:
(WebKit::WebFrameProxy::getResourceData):
- UIProcess/WebFrameProxy.h:
- UIProcess/WebIconDatabase.cpp:
(WebKit::WebIconDatabase::didChangeIconForPageURL):
(WebKit::WebIconDatabase::notifyIconDataReadyForPageURL):
- UIProcess/WebIconDatabaseClient.cpp:
(WebKit::WebIconDatabaseClient::didChangeIconForPageURL):
(WebKit::WebIconDatabaseClient::iconDataReadyForPageURL):
- UIProcess/WebIconDatabaseClient.h:
- UIProcess/WebOpenPanelResultListenerProxy.cpp:
(WebKit::WebOpenPanelResultListenerProxy::chooseFiles):
- UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::getResourceDataFromFrame):
- UIProcess/WebPageProxy.h:
- WebKit2.xcodeproj/project.pbxproj:
- WebProcess/InjectedBundle/API/c/WKBundlePage.cpp:
- 12:25 PM Changeset in webkit [160968] by
-
- 3 edits in trunk/Source/WebCore
Unreviewed, rolling out r160916.
http://trac.webkit.org/changeset/160916
https://bugs.webkit.org/show_bug.cgi?id=126073
Roll out a temporary fix. The underlying issue was fixed.
- accessibility/AccessibilityRenderObject.cpp:
(WebCore::AccessibilityRenderObject::AccessibilityRenderObject):
(WebCore::AccessibilityRenderObject::~AccessibilityRenderObject):
(WebCore::AccessibilityRenderObject::detach):
(WebCore::AccessibilityRenderObject::computeAccessibilityIsIgnored):
- accessibility/AccessibilityRenderObject.h:
- 11:25 AM Changeset in webkit [160967] by
-
- 13 edits in branches/jsCStack/Source/JavaScriptCore
CStack: Update the VMEntryScope's stack limit when the VM enters/exits ErrorMode.
https://bugs.webkit.org/show_bug.cgi?id=126009.
Not yet reviewed.
- Renamed JSStack::updateStackLimit() to setStackLimit() because that is what it actually does. We're going to repurpose the updateStackLimit name for another function.
- Fixed a bug in setStackLimit() where setJSStackLimit() was called with the value of newEnd which points past the end of the stack. The fix is to add 1 to point at the last slot at top of the stack. This is what is the users of the jsStackLimit value expects.
- Introduce the new JSStack::updateStackLimit() which is responsible for re-setting the current stack limit. updateStackLimit() will handle both cases of the JS stack being on the C stack or a separate stack.
For the C stack case, JStack::updateStackLimit() will check if a
VMEntryScope has been installed in the VM. If so, it will tell the
VMEntryScope to do the real work of updating the stack limit. The
VMEntryScope will take into account whether the VM's Interpreter is
in an error handling mode or not when determining the amount of host
zone space to reserve on the stack for computing the stack limit value.
- Interpreter::ErrorHandlingMode now calls JSStack::updateStackLimit whenever it enters / exit error handling mode. This allows the stack limit to change with the error mode change.
- A lot of places in the code were throwing StackOverflowErrors by creating and throwing the error themselves instead of using the throwStackOverflowError() helper function. As a result, the VM never got the chance to enter error mode. This is a bug and is now fixed by making all these sites use throwStackOverflowError() instead.
For sites that can't use throwStackOverflowError(), I updated them to
instantiate Interpreter::ErrorHandlingMode to set the error mode
appropriately.
- Made JSStack::enableErrorStackReserve() and disableErrorStackReserve() private. They are no longer called from outside of JSStack.
- interpreter/Interpreter.cpp:
(JSC::Interpreter::ErrorHandlingMode::ErrorHandlingMode):
(JSC::Interpreter::ErrorHandlingMode::~ErrorHandlingMode):
(JSC::sizeFrameForVarargs):
- interpreter/JSStack.cpp:
(JSC::JSStack::JSStack):
(JSC::JSStack::growSlowCase):
(JSC::JSStack::updateStackLimit):
- interpreter/JSStack.h:
- interpreter/JSStackInlines.h:
(JSC::JSStack::shrink):
(JSC::JSStack::setStackLimit):
- jit/JITOperations.cpp:
- llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
- parser/ParserError.h:
(JSC::ParserError::toErrorObject):
- runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
- runtime/JSONObject.cpp:
(JSC::Walker::walk):
- runtime/StringRecursionChecker.cpp:
(JSC::StringRecursionChecker::throwStackOverflowError):
- runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope):
(JSC::VMEntryScope::updateStackLimit):
- runtime/VMEntryScope.h:
- 10:51 AM Changeset in webkit [160966] by
-
- 51 edits in trunk/Source/WebCore
Figure out if node is focusable without requiring renderer
https://bugs.webkit.org/show_bug.cgi?id=126118
Reviewed by Andreas Kling.
- dom/Element.cpp:
(WebCore::Element::computedStyle):
Use inDocument() test instead of the attached() test. We can compute style for anything that
is in document.
- dom/Node.cpp:
(WebCore::Node::isContentEditable):
(WebCore::Node::isContentRichlyEditable):
(WebCore::Node::hasEditableStyle):
Use computedStyle instead of getting the style from renderer. Computed style gets constructed
on demand if renderer does not exist. If it does then the existing style is used.
(WebCore::Node::isEditableToAccessibility):
(WebCore::Node::canStartSelection):
(WebCore::Node::isRootEditableElement):
(WebCore::Node::rootEditableElement):
- dom/Node.h:
(WebCore::Node::hasEditableStyle):
(WebCore::Node::hasRichlyEditableStyle):
Renamed from rendererIsEditable since these no longer require renderer.
(WebCore::HTMLElement::supportsFocus):
Stop calling updateStyleIfNeeded() and forcing render tree construction.
- 6:40 AM Changeset in webkit [160965] by
-
- 2 edits in trunk/Source/WebKit2
[GTK] Test /webkit2/WebKitWebResource/mime-type fails when run after /webkit2/WebKitWebView/resources
https://bugs.webkit.org/show_bug.cgi?id=126119
Reviewed by Martin Robinson.
The problem is that when the blank.ico resource is loaded from the
disk cache, the mime type is null, because the soup cache doesn't
cache sniffed mime types. This doesn't happen when a resource is
loaded form the memory cache, because the ResourceResponse is
cached, not only the headers. I think the disk cache should also
cache the sniffed content type, but that needs to be done in
soup. For now we can workaround the issue in the unit test by
making sure that resources that can be cached, also include the
Content-Type header, this way the mime type won't be sniffed and
it will be cached as a HTTP header in the disk cache.
- UIProcess/API/gtk/tests/TestResources.cpp:
(serverCallback): Add Content-Type header for resources that can
be cached.
- 6:36 AM Changeset in webkit [160964] by
-
- 3 edits in trunk/Source/WebKit2
REGRESSION(r160909): [GTK] Tests /webkit2/WebKitWebView/default-menu and /webkit2/WebKitSettings/webkit-settings fail
https://bugs.webkit.org/show_bug.cgi?id=126117
Reviewed by Martin Robinson.
In r160909 the fullscreen setting default value was changed, but
the unit tests relaying on the default value were not updated
accordingly.
- UIProcess/API/gtk/tests/TestContextMenu.cpp:
- UIProcess/API/gtk/tests/TestWebKitSettings.cpp:
(testWebKitSettings):
- 1:49 AM Changeset in webkit [160963] by
-
- 5 edits in branches/jsCStack/Source/JavaScriptCore
Register restoration thunk should restore the ArgumentCount after it restores registers
https://bugs.webkit.org/show_bug.cgi?id=126115
Not yet reviewed.
Just getting us further along in V8/crypto...
- ftl/FTLJSCall.cpp:
(JSC::FTL::JSCall::JSCall):
(JSC::FTL::JSCall::link):
- ftl/FTLJSCall.h:
- ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
- jit/RegisterPreservationWrapperGenerator.cpp:
(JSC::generateRegisterRestoration):
- 12:59 AM Changeset in webkit [160962] by
-
- 2 edits in trunk/Tools
Unreviewed. Add myself to some more watch lists.
- Scripts/webkitpy/common/config/watchlist: Watch also soup, gst
and binding scripts patches.
- 12:51 AM Changeset in webkit [160961] by
-
- 3 edits in trunk/Source/WebCore
[SOUP] ResourceHandleSoup should use async client callbacks when client uses async callbacks
https://bugs.webkit.org/show_bug.cgi?id=126006
Reviewed by Martin Robinson.
This fixes WebKit2 loader client unit tests when using the network
process.
- platform/network/ResourceHandle.cpp:
- platform/network/soup/ResourceHandleSoup.cpp:
(WebCore::doRedirect): Call willSendRequestAsync on the client
when usesAsyncCallbacks returns true.
(WebCore::nextMultipartResponsePartCallback): Call
didReceiveResponseAsync on the client when usesAsyncCallbacks
returns true.
(WebCore::sendRequestCallback): Ditto.
(WebCore::ResourceHandle::continueWillSendRequest): Empty
implementation for now because the default one asserts.
(WebCore::ResourceHandle::continueDidReceiveResponse): Ditto.
(WebCore::ResourceHandle::continueShouldUseCredentialStorage): Ditto.
