Missing dependencies when compiling on ubuntu 12.04.1 #2
Comments
intltool./configure: line 12418: intltool-update: command not found configure: error: Your intltool is too old. You need intltool 0.35.0 or later.libgnutls-devconfigure: error: in `/home/webkitbuildbot/_ubi1204-teszt/WebKitNix/WebKitBuild/Dependencies/Source/glib-networking-2.33.2': configure: error: "No package 'gnutls' found"gnome-common*** Configuring libsoup *** [10/11] You need to install gnome-commongtk-doc-tools*** Configuring libsoup *** [10/11] |
|
Doesn't it also need ruby? |
|
Yes, we need ruby too. All of us have sedkit-env-qtwebkit PPA installed from ppa:u-szeged/sedkit, It would be great if somebody can try to find all dependency with pbuilder |
dakerfp
pushed a commit
that referenced
this issue
Mar 4, 2013
Remove duplicated entries. * platform/chromium/TestExpectations: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144445 268f45cc-cd09-0410-ab3c-d52691b4dbfc
|
I guess you shouldn't need libavcodec anymore, neither the dev package. |
dakerfp
pushed a commit
that referenced
this issue
Mar 20, 2013
https://bugs.webkit.org/show_bug.cgi?id=112482 Reviewed by Simon Fraser. Tests that rely on multiple 'iframe' elements loading in a specific order are a Bad Idea™. This patch splits 'fast/frames/sandboxed-iframe-scripting.html' out into five tests, and changes two of them (#2 and #4) to use message passing in order to test in a way that 'js-test-{pre,post}' can cleanly report. * fast/frames/sandboxed-iframe-scripting-01-expected.txt: Added. * fast/frames/sandboxed-iframe-scripting-01.html: Added. * fast/frames/sandboxed-iframe-scripting-02-expected.txt: Added. * fast/frames/sandboxed-iframe-scripting-02.html: Added. * fast/frames/sandboxed-iframe-scripting-03-expected.txt: Added. * fast/frames/sandboxed-iframe-scripting-03.html: Added. * fast/frames/sandboxed-iframe-scripting-04-expected.txt: Added. * fast/frames/sandboxed-iframe-scripting-04.html: Added. * fast/frames/sandboxed-iframe-scripting-05-expected.txt: Added. * fast/frames/sandboxed-iframe-scripting-05.html: Added. * fast/frames/sandboxed-iframe-scripting-expected.txt: Removed. * fast/frames/sandboxed-iframe-scripting.html: Removed. * platform/mac/TestExpectations: Remove the skipped test, since it no longer exists. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@145993 268f45cc-cd09-0410-ab3c-d52691b4dbfc
This was referenced Jul 15, 2013
dakerfp
pushed a commit
that referenced
this issue
Jul 26, 2013
… read and what they write https://bugs.webkit.org/show_bug.cgi?id=118910 Source/JavaScriptCore: Reviewed by Sam Weinig. Add the notion of AbstractHeap to the DFG. This is analogous to the AbstractHeap in the FTL, except that the FTL's AbstractHeaps are used during LLVM lowering and are engineered to obey LLVM TBAA logic. The FTL's AbstractHeaps are also engineered to be inexpensive to use (they just give you a TBAA node) but expensive to create (you create them all up front). FTL AbstractHeaps also don't actually give you the ability to reason about aliasing; they are *just* a mechanism for lowering to TBAA. The DFG's AbstractHeaps are engineered to be both cheap to create and cheap to use. They also give you aliasing machinery. The DFG AbstractHeaps are represented internally by a int64_t. Many comparisons between them are just integer comaprisons. AbstractHeaps form a three-level hierarchy (World is the supertype of everything, Kind with a TOP payload is a direct subtype of World, and Kind with a non-TOP payload is the direct subtype of its corresponding TOP Kind). Add the notion of a ClobberSet. This is the set of AbstractHeaps that you had clobbered. It represents the set that results from unifying a bunch of AbstractHeaps, and is intended to quickly answer overlap questions: does the given AbstractHeap overlap any AbstractHeap in the ClobberSet? To this end, if you add an AbstractHeap to a set, it "directly" adds the heap itself, and "super" adds all of its ancestors. An AbstractHeap is said to overlap a set if any direct or super member is equal to it, or if any of its ancestors are equal to a direct member. Example #1: - I add Variables(5). I.e. Variables is the Kind and 5 is the payload. This is a subtype of Variables, which is a subtype of World. - You query Variables. I.e. Variables with a TOP payload, which is the supertype of Variables(X) for any X, and a subtype of World. The set will have Variables(5) as a direct member, and Variables and World as super members. The Variables query will immediately return true, because Variables is indeed a super member. Example #2: - I add Variables(5) - You query NamedProperties NamedProperties is not a member at all (neither direct or super). We next query World. World is a member, but it's a super member, so we return false. Example #3: - I add Variables - You query Variables(5) The set will have Variables as a direct member, and World as a super member. The Variables(5) query will not find Variables(5) in the set, but then it will query Variables. Variables is a direct member, so we return true. Example #4: - I add Variables - You query NamedProperties(5) Neither NamedProperties nor NamedProperties(5) are members. We next query World. World is a member, but it's a super member, so we return false. Overlap queries require that either the heap being queried is in the set (either direct or super), or that one of its ancestors is a direct member. Another way to think about how this works is that two heaps A and B are said to overlap if A.isSubtypeOf(B) or B.isSubtypeOf(A). This is sound since heaps form a single-inheritance heirarchy. Consider that we wanted to implement a set that holds heaps and answers the question, "is any member in the set an ancestor (i.e. supertype) of some other heap". We would have the set contain the heaps themselves, and we would satisfy the query "A.isSubtypeOfAny(set)" by walking the ancestor chain of A, and repeatedly querying its membership in the set. This is what the "direct" members of our set do. Now consider the other part, where we want to ask if any member of the set is a descendent of a heap, or "A.isSupertypeOfAny(set)". We would implement this by implementing set.add(B) as adding not just B but also all of B's ancestors; then we would answer A.isSupertypeOfAny(set) by just checking if A is in the set. With two such sets - one that answers isSubtypeOfAny() and another that answers isSupertypeOfAny() - we could answer the "do any of my heaps overlap your heap" question. ClobberSet does this, but combines the two sets into a single HashMap. The HashMap's value, "direct", means that the key is a member of both the supertype set and the subtype set; if it's false then it's only a member of one of them. Finally, this adds a functorized clobberize() method that adds the read and write clobbers of a DFG::Node to read and write functors. Common functors for adding to ClobberSets, querying overlap, and doing nothing are provided. Convenient wrappers are also provided. This allows you to say things like: ClobberSet set; addWrites(graph, node1, set); if (readsOverlap(graph, node2, set)) // We know that node1 may write to something that node2 may read from. Currently this facility is only used to improve graph dumping, but it will be instrumental in both LICM and GVN. In the future, I want to completely kill the NodeClobbersWorld and NodeMightClobber flags, and eradicate CSEPhase's hackish way of accomplishing almost exactly what AbstractHeap gives you. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractHeap.cpp: Added. (DFG): (JSC::DFG::AbstractHeap::Payload::dump): (JSC::DFG::AbstractHeap::dump): (WTF): (WTF::printInternal): * dfg/DFGAbstractHeap.h: Added. (DFG): (AbstractHeap): (Payload): (JSC::DFG::AbstractHeap::Payload::Payload): (JSC::DFG::AbstractHeap::Payload::top): (JSC::DFG::AbstractHeap::Payload::isTop): (JSC::DFG::AbstractHeap::Payload::value): (JSC::DFG::AbstractHeap::Payload::valueImpl): (JSC::DFG::AbstractHeap::Payload::operator==): (JSC::DFG::AbstractHeap::Payload::operator!=): (JSC::DFG::AbstractHeap::Payload::operator<): (JSC::DFG::AbstractHeap::Payload::isDisjoint): (JSC::DFG::AbstractHeap::Payload::overlaps): (JSC::DFG::AbstractHeap::AbstractHeap): (JSC::DFG::AbstractHeap::operator!): (JSC::DFG::AbstractHeap::kind): (JSC::DFG::AbstractHeap::payload): (JSC::DFG::AbstractHeap::isDisjoint): (JSC::DFG::AbstractHeap::overlaps): (JSC::DFG::AbstractHeap::supertype): (JSC::DFG::AbstractHeap::hash): (JSC::DFG::AbstractHeap::operator==): (JSC::DFG::AbstractHeap::operator!=): (JSC::DFG::AbstractHeap::operator<): (JSC::DFG::AbstractHeap::isHashTableDeletedValue): (JSC::DFG::AbstractHeap::payloadImpl): (JSC::DFG::AbstractHeap::encode): (JSC::DFG::AbstractHeapHash::hash): (JSC::DFG::AbstractHeapHash::equal): (AbstractHeapHash): (WTF): * dfg/DFGClobberSet.cpp: Added. (DFG): (JSC::DFG::ClobberSet::ClobberSet): (JSC::DFG::ClobberSet::~ClobberSet): (JSC::DFG::ClobberSet::add): (JSC::DFG::ClobberSet::addAll): (JSC::DFG::ClobberSet::contains): (JSC::DFG::ClobberSet::overlaps): (JSC::DFG::ClobberSet::clear): (JSC::DFG::ClobberSet::direct): (JSC::DFG::ClobberSet::super): (JSC::DFG::ClobberSet::dump): (JSC::DFG::ClobberSet::setOf): (JSC::DFG::addReads): (JSC::DFG::addWrites): (JSC::DFG::addReadsAndWrites): (JSC::DFG::readsOverlap): (JSC::DFG::writesOverlap): * dfg/DFGClobberSet.h: Added. (DFG): (ClobberSet): (JSC::DFG::ClobberSet::isEmpty): (ClobberSetAdd): (JSC::DFG::ClobberSetAdd::ClobberSetAdd): (JSC::DFG::ClobberSetAdd::operator()): (ClobberSetOverlaps): (JSC::DFG::ClobberSetOverlaps::ClobberSetOverlaps): (JSC::DFG::ClobberSetOverlaps::operator()): (JSC::DFG::ClobberSetOverlaps::result): * dfg/DFGClobberize.cpp: Added. (DFG): (JSC::DFG::didWrites): * dfg/DFGClobberize.h: Added. (DFG): (JSC::DFG::clobberize): (NoOpClobberize): (JSC::DFG::NoOpClobberize::NoOpClobberize): (JSC::DFG::NoOpClobberize::operator()): (CheckClobberize): (JSC::DFG::CheckClobberize::CheckClobberize): (JSC::DFG::CheckClobberize::operator()): (JSC::DFG::CheckClobberize::result): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): Source/WTF: Reviewed by Sam Weinig. Fix compile goof in sortedListDump(). * wtf/ListDump.h: (WTF::sortedListDump): Conflicts: Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153294 268f45cc-cd09-0410-ab3c-d52691b4dbfc
tulliolucena
pushed a commit
that referenced
this issue
Sep 6, 2013
…atforms that can't support it because if non-bourne shells. This fixes part #2 of the Linux bot breakage. * Scripts/run-javascriptcore-tests: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155103 268f45cc-cd09-0410-ab3c-d52691b4dbfc
hugopl
pushed a commit
that referenced
this issue
Sep 12, 2013
…caping to bytecode, as opposed to just escaping within DFG code.
Rubber stamped by Mark Hahnenberg.
We need to care about escaping to bytecode if we're doing a lossy optimization,
i.e. the optimization means we produce less information and so we can't rescue
ourselves during OSR exit.
We only need to care about escaping within the DFG code (and can ignore what
might happen in bytecode) if we're doing an optimization that is lossless, i.e.
we can always still reconstruct the values that bytecode wants.
Example #1:
Large int32 + int32 which overflows. We want to optimize away the overflow
check and just do a 32-bit add.
This is lossy; the result should have one extra bit but we simply throw
that bit away by doing a check-less 32-bit add. Hence we need to know that
even the bytecode wouldn't have cared about that bit. This is true in cases
like (a + b) | 0.
Example #2:
Larbe int32 + int32 which overflows. We want to optimize away the overflow
check by doing a 64-bit add.
This is lossless. We can always convert the resulting 64-bit int back to a
double if that's what bytecode wants. Hence we only need to know that the
DFG code won't want to do something to this value that would make 64-bit
ints either unprofitable or unsound.
The backwards propagator's notions of flags (NodeUsedAsValue, etc) are for lossy
optimizations and so should be named in a way that reflects this. This patch
calls then NodeBytecodeUsesAsValue, etc.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::refine):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::mergeDefaultFlags):
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
* dfg/DFGNode.h:
(JSC::DFG::Node::arithNodeFlags):
* dfg/DFGNodeFlags.cpp:
(JSC::DFG::dumpNodeFlags):
* dfg/DFGNodeFlags.h:
(JSC::DFG::bytecodeUsesAsNumber):
(JSC::DFG::bytecodeCanTruncateInteger):
(JSC::DFG::bytecodeCanIgnoreNegativeZero):
(JSC::DFG::nodeMayNegZero):
(JSC::DFG::nodeCanSpeculateInt32):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDoubleAsInt32):
(JSC::DFG::SpeculativeJIT::compileAdd):
(JSC::DFG::SpeculativeJIT::compileArithSub):
(JSC::DFG::SpeculativeJIT::compileArithNegate):
(JSC::DFG::SpeculativeJIT::compileArithMul):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGVariableAccessData.h:
(JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileAdd):
(JSC::FTL::LowerDFGToLLVM::compileArithSub):
(JSC::FTL::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::LowerDFGToLLVM::compileArithDiv):
(JSC::FTL::LowerDFGToLLVM::compileArithMod):
(JSC::FTL::LowerDFGToLLVM::compileArithNegate):
git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155497 268f45cc-cd09-0410-ab3c-d52691b4dbfc
hugopl
pushed a commit
that referenced
this issue
Sep 16, 2013
…th DFG and FTL https://bugs.webkit.org/show_bug.cgi?id=121371 Reviewed by Sam Weinig. Forward rewiring is a tricky part of OSR that handles the following: a: Something(...) SetLocal(@A, locX) b: Int32ToDouble(@A) c: SomethingThatExits(@b) <no further uses of @A or @b> Note that at @c, OSR will think that locX->@A, but @A will be dead. So it must be smart enough to find @b, which contains an equivalent value. It must do this for any identity functions we support. Currently we support four such functions. Currently the code for doing this is basically duplicated between the DFG and the FTL. Also both versions of the code have some really weirdly written logic for picking the "best" identity function to use. We should fix this by simply having a way to ask "is this node an identity function, and if so, then how good is it?" Then both the DFG and FTL could use this and have no hard-wired knowledge of those identity functions. While we're at it, this also changes some terminology because I found the use of the word "needs" confusing. Note that this retains the somewhat confusing behavior that we don't search all possible forward/backward uses. We only search one step in each direction. This is because we only need to handle cases that FixupPhase and the parser insert. All other code that tries to insert intermediate conversion nodes should ensure to Phantom the original node. For example, the following transformation is illegal: Before: x: SomethingThatExits(@A) After: w: Conversion(@A) x: SomethingThatExits(@w) The correct form of that transformation is one of these: Correct #1: v: DoAllChecks(@A) // exit here w: Conversion(@A) x: Something(@w) // no exit Correct #2: w: Conversion(@A) x: SomethingThatExits(@w) y: Phantom(@A) Correct #3: w: Conversion(@A) x: SomethingThatExits(@w, @A) Note that we use #3 for some heap accesses, but of course it requires that the node you're using has an extra slot for a "dummy" use child. Broadly speaking though, such transformations should be relegated to something below DFG IR, like LLVM IR. * dfg/DFGNodeType.h: (JSC::DFG::forwardRewiringSelectionScore): (JSC::DFG::needsOSRForwardRewiring): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155793 268f45cc-cd09-0410-ab3c-d52691b4dbfc
lauromoura
pushed a commit
that referenced
this issue
Oct 12, 2013
…hread (causing scroll bars not to appear/update quickly in some cases) https://bugs.webkit.org/show_bug.cgi?id=122585 -and corresponding- <rdar://problem/10710775> Reviewed by Simon Fraser. Source/WebCore: This patch does a few things in order to allow scrollbars to be updated on the scrolling thread: 1. This patch adds the ability to know if the lower-level APIs necessary to get this to work right are available, AND if the content is actually capable of taking advantage of this feature. This is currently implemented as Scrollbar::supportsUpdateOnSecondaryThread() which makes use of a new ScrollableArea function called updatesScrollLayerPositionOnMainThread() 2. To update on the scrolling thread, the scrolling tree needs to know about the ScrollbarPainters. 3. Once it knows about them, it should update the presentation value whenever the layer position changes. 4. Presentation value is basically the same thing as double value. There is a bit of code we maintain currently to compute that. This patch moves that code to a static function on ScrollableArea that can be called from both the main thread and the scrolling thread. 5. ScrollbarPainter API needs to know about the layers we have created for the vertical and horizontal scrollbars, then they will use those layers and the presentation value that we set on the scrolling thread to move the layers around. This is part of #1 above. * page/FrameView.cpp: (WebCore::FrameView::updatesScrollLayerPositionOnMainThread): * page/FrameView.h: This is part of #2. ScrollingStateScrollingNodes now have vertical and horizontal ScrollbarPainters for Mac only. * page/scrolling/ScrollingStateScrollingNode.cpp: (WebCore::ScrollingStateScrollingNode::ScrollingStateScrollingNode): * page/scrolling/ScrollingStateScrollingNode.h: (WebCore::ScrollingStateScrollingNode::verticalScrollbarPainter): (WebCore::ScrollingStateScrollingNode::horizontalScrollbarPainter): Also part of #2. Make sure to set the ScrollbarPainters for scrolling nodes when appropriate. * page/scrolling/mac/ScrollingCoordinatorMac.h: * page/scrolling/mac/ScrollingCoordinatorMac.mm: (WebCore::ScrollingCoordinatorMac::frameViewLayoutUpdated): Implement this function that was just stubbed out before. This is part of #5 in that is will allow the ScrollbarPainter API to know about any layer changes. (WebCore::ScrollingCoordinatorMac::scrollableAreaScrollbarLayerDidChange): Back to #2, making sure we properly set the ScrollbarPainters to send over to the scrolling thread. (WebCore::ScrollingCoordinatorMac::setScrollbarPaintersForNode): * page/scrolling/mac/ScrollingStateScrollingNodeMac.mm: (WebCore::ScrollingStateScrollingNode::setScrollbarPainters): This code achieves #3. It uses new ScrollbarPainter API to adjust the position of the scrollbars from the scrolling thread. * page/scrolling/mac/ScrollingTreeScrollingNodeMac.h: * page/scrolling/mac/ScrollingTreeScrollingNodeMac.mm: (WebCore::ScrollingTreeScrollingNodeMac::ScrollingTreeScrollingNodeMac): (WebCore::ScrollingTreeScrollingNodeMac::updateBeforeChildren): (WebCore::ScrollingTreeScrollingNodeMac::setScrollLayerPosition): This is for #5. ScrollbarPainter needs to know about our scrollbar layers. * platform/ScrollAnimator.h: (WebCore::ScrollAnimator::verticalScrollbarLayerDidChange): (WebCore::ScrollAnimator::horizontalScrollbarLayerDidChange): * platform/ScrollableArea.cpp: (WebCore::ScrollableArea::verticalScrollbarLayerDidChange): (WebCore::ScrollableArea::horizontalScrollbarLayerDidChange): This is for #4. This code computes the scrollbar’s value and current overhang amount. (WebCore::ScrollableArea::computeScrollbarValueAndOverhang): * platform/ScrollableArea.h: (WebCore::ScrollableArea::layerForHorizontalScrollbar): (WebCore::ScrollableArea::layerForVerticalScrollbar): (WebCore::ScrollableArea::layerForScrolling): This is for #1. We need to know if we have the ability to update scrollbars on a different thread. We can do that only on certain versions of the OS, only when threaded scrolling is enabled, and only when the current page is actually using the scrolling thread to scroll. * platform/Scrollbar.cpp: (WebCore::Scrollbar::supportsUpdateOnSecondaryThread): * platform/Scrollbar.h: * platform/ScrollbarThemeClient.h: New ScrollbarPainter APIs. * platform/mac/NSScrollerImpDetails.h: This is for #5, letting the ScrollbarPainter API know about the layers. * platform/mac/ScrollAnimatorMac.h: * platform/mac/ScrollAnimatorMac.mm: (-[WebScrollbarPainterDelegate layer]): (-[WebScrollbarPainterDelegate convertRectToLayer:]): (-[WebScrollbarPainterDelegate shouldUseLayerPerPartForScrollerImp:]): Before we kick off a scroll animation, set the current painting characteristics so they are up-to-date in case we are scrolling on the scrolling thread. (-[WebScrollbarPainterDelegate setUpAlphaAnimation:scrollerPainter:part:WebCore::animateAlphaTo:duration:]): (-[WebScrollbarPainterDelegate scrollerImp:animateKnobAlphaTo:duration:]): (-[WebScrollbarPainterDelegate scrollerImp:animateTrackAlphaTo:duration:]): (WebCore::ScrollAnimatorMac::didAddVerticalScrollbar): (WebCore::ScrollAnimatorMac::didAddHorizontalScrollbar): (WebCore::ScrollAnimatorMac::verticalScrollbarLayerDidChange): (WebCore::ScrollAnimatorMac::horizontalScrollbarLayerDidChange): Only paint the scrollbars through ScrollbarThemeMac if they are NOT being updated by the scrolling thread. * platform/mac/ScrollbarThemeMac.h: * platform/mac/ScrollbarThemeMac.mm: (WebCore::ScrollbarThemeMac::setCurrentPaintCharacteristics): (WebCore::scrollbarPainterPaint): (WebCore::ScrollbarThemeMac::paint): Back to #1. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::updatesScrollLayerPositionOnMainThread): * rendering/RenderLayer.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::updateOverflowControlsLayers): * rendering/RenderListBox.h: Source/WebKit2: New pure virtual function. * WebProcess/Plugins/PDF/PDFPlugin.h: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157253 268f45cc-cd09-0410-ab3c-d52691b4dbfc
qrwteyrutiyoup
pushed a commit
that referenced
this issue
Nov 6, 2013
…will hide it in the inspector https://bugs.webkit.org/show_bug.cgi?id=123516 Reviewed by Timothy Hatcher. Source/WebCore: InspectorInstrumentation::willRemoveDOMNode was actually calling both willRemoveDOMNodeImpl and didRemoveDOMNodeImpl, making the DOMAgent unbind the element even if it was still part of the DOM. Because of that the DOMAgent was sending two events: 1. When the element was about to be removed, just before JS "DOMNodeRemoved" was triggered. 2. When the element was actually removed. Note that inspector's event #2 will not know about the node, as it just removed it from the internal hashmap, so it will just use a nodeID == 0 for it. This patch adds a separate call to InspectorInstrumentation::didRemoveDOMNode, just before the element is about to be removed. The InspectorInstrumentation::willRemoveDOMNode call is now only used by the DOMDebugger to trigger the DOM breakpoints in the Web Inspector. That feature is not exposed in the new Inspector UI, but can be used/tested using the protocol directly. Tests: inspector-protocol/dom-debugger/node-removed.html inspector-protocol/dom/dom-remove-events.html inspector-protocol/dom/remove-multiple-nodes.html * dom/ContainerNode.cpp: (WebCore::ContainerNode::removeBetween): * inspector/InspectorInstrumentation.h: (WebCore::InspectorInstrumentation::willRemoveDOMNode): (WebCore::InspectorInstrumentation::didRemoveDOMNode): LayoutTests: Added tests to check that the DOM.childNodeRemoved inspector-protocol message is dispatched correctly when DOM nodes are moved while inside the "DOMNodeRemoved" event handler. * inspector-protocol/dom-debugger/node-removed-expected.txt: Added. * inspector-protocol/dom-debugger/node-removed.html: Added. Checking that the DOMDebugger agent is still sending the node-removed events. * inspector-protocol/dom/dom-remove-events-expected.txt: Added. * inspector-protocol/dom/dom-remove-events.html: Added. Test with a single DOM remove event. * inspector-protocol/dom/remove-multiple-nodes-expected.txt: Added. * inspector-protocol/dom/remove-multiple-nodes.html: Added. Test case when multiple children are removed at once with parentNode.textContent = "String". git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158708 268f45cc-cd09-0410-ab3c-d52691b4dbfc
thiagolacerda
pushed a commit
that referenced
this issue
Mar 14, 2014
https://bugs.webkit.org/show_bug.cgi?id=129741 Reviewed by Geoffrey Garen. We want to keep track of three GC states for an object: 1. Not marked (which implies not in the remembered set) 2. Marked but not in the remembered set 3. Marked and in the remembered set Currently we only indicate marked vs. not marked in JSCell::m_gcData. During a write barrier, we only want to take the slow path if the object being stored to is in state #2. We'd like to make the test for state #2 as fast as possible, which means making it a compare against 0. * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::osrWriteBarrier): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::checkMarkByte): (JSC::DFG::SpeculativeJIT::writeBarrier): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::writeBarrier): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::writeBarrier): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::allocateCell): (JSC::FTL::LowerDFGToLLVM::emitStoreBarrier): * heap/Heap.cpp: (JSC::Heap::clearRememberedSet): (JSC::Heap::addToRememberedSet): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::checkMarkByte): * jit/JIT.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::checkMarkByte): (JSC::JIT::emitWriteBarrier): * jit/Repatch.cpp: (JSC::writeBarrier): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSCell.h: (JSC::JSCell::mark): (JSC::JSCell::remember): (JSC::JSCell::forget): (JSC::JSCell::isMarked): (JSC::JSCell::isRemembered): * runtime/JSCellInlines.h: (JSC::JSCell::JSCell): * runtime/StructureIDBlob.h: (JSC::StructureIDBlob::StructureIDBlob): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165135 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following dependencies were missing:
libxrender-dev
libxcomposite-dev
libavcodec-dev
libavcodec was not found so I had to install libavcodec-dev
The text was updated successfully, but these errors were encountered: