1. 24 Jul, 2013 40 commits
    • oliver@apple.com's avatar
      fourthTier: It should be possible to query WatchpointSets, and add... · 9397e00c
      oliver@apple.com authored
      fourthTier: It should be possible to query WatchpointSets, and add Watchpoints, even if the compiler is running in another thread
      https://bugs.webkit.org/show_bug.cgi?id=114909
      
      Source/JavaScriptCore:
      
      Reviewed by Oliver Hunt.
      
      The idea here is that a concurrent compiler will use watchpoint sets as follows:
      
      During concurrent compilation: It will create Watchpoints, and query WatchpointSets only
      for the purpose of profiling. That is, it will use decide whether it is profitable to
      compile the code "as if" the watchpoint sets are valid.
      
      During synchronous linking: By "linking" I don't necessarily mean the LinkBuffer stuff,
      but just the very bitter end of compilation where we make the JIT code callable. This
      can happen after LinkBuffer stuff. Anyway, this will have to happen synchronously, and
      at that point we can (a) check that all WatchpointSets that we assumed were valid are
      still valid and (b) if they are then we add the watchpoints to those sets. If any of the
      sets are invalid, we give up on this compilation and try again later.
      
      The querying of WatchpointSets is engineered to say that the set is still valid if it
      is so *right now*, but this is done in a racy way and so it may say so spuriously: we
      may, with hopefully low probability, have a set that says it is valid even though it was
      just invalidated. The goal is only to ensure that (i) a set never claims to be invalid
      if it is actually valid, (ii) a set doesn't claim to be valid if it was invalidated
      before compilation even began, and (iii) querying the validity of a set doesn't cause us
      to crash.
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/Watchpoint.cpp:
      (JSC::InlineWatchpointSet::inflateSlow):
      * bytecode/Watchpoint.h:
      (WatchpointSet):
      (InlineWatchpointSet):
      (JSC::InlineWatchpointSet::hasBeenInvalidated):
      (JSC::InlineWatchpointSet::isThin):
      (JSC::InlineWatchpointSet::isFat):
      (JSC::InlineWatchpointSet::fat):
      * dfg/DFGDesiredWatchpoints.cpp: Added.
      (DFG):
      (JSC::DFG::DesiredWatchpoints::DesiredWatchpoints):
      (JSC::DFG::DesiredWatchpoints::~DesiredWatchpoints):
      (JSC::DFG::DesiredWatchpoints::addLazily):
      (JSC::DFG::DesiredWatchpoints::reallyAdd):
      (JSC::DFG::DesiredWatchpoints::areStillValid):
      * dfg/DFGDesiredWatchpoints.h: Added.
      (DFG):
      (JSC::DFG::WatchpointForGenericWatchpointSet::WatchpointForGenericWatchpointSet):
      (WatchpointForGenericWatchpointSet):
      (GenericDesiredWatchpoints):
      (JSC::DFG::GenericDesiredWatchpoints::GenericDesiredWatchpoints):
      (JSC::DFG::GenericDesiredWatchpoints::addLazily):
      (JSC::DFG::GenericDesiredWatchpoints::reallyAdd):
      (JSC::DFG::GenericDesiredWatchpoints::areStillValid):
      (DesiredWatchpoints):
      * dfg/DFGDriver.cpp:
      (JSC::DFG::compile):
      * dfg/DFGJITCompiler.cpp:
      (JSC::DFG::JITCompiler::link):
      (JSC::DFG::JITCompiler::compile):
      (JSC::DFG::JITCompiler::compileFunction):
      * dfg/DFGJITCompiler.h:
      (JSC::DFG::JITCompiler::addLazily):
      (JITCompiler):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
      (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
      (JSC::DFG::SpeculativeJIT::compileObjectEquality):
      (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
      (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
      (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
      (JSC::DFG::SpeculativeJIT::compileObjectEquality):
      (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
      (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
      (JSC::DFG::SpeculativeJIT::compile):
      * ftl/FTLCompile.cpp:
      (JSC::FTL::compile):
      * ftl/FTLCompile.h:
      (FTL):
      * ftl/FTLState.h:
      (State):
      * runtime/JSFunction.h:
      (JSFunction):
      (JSC::JSFunction::allocationProfileWatchpointSet):
      * runtime/Structure.h:
      (Structure):
      (JSC::Structure::transitionWatchpointSet):
      
      Source/WTF:
      
      Reviewed by Oliver Hunt.
      
      Harden our notions of memory fences, now that we're doing racy algorithms.
      
      * wtf/Atomics.h:
      (WTF):
      (WTF::compilerFence):
      (WTF::armV7_dmb):
      (WTF::armV7_dmb_st):
      (WTF::loadLoadFence):
      (WTF::loadStoreFence):
      (WTF::storeLoadFence):
      (WTF::storeStoreFence):
      (WTF::memoryBarrierAfterLock):
      (WTF::memoryBarrierBeforeUnlock):
      (WTF::x86_mfence):
      
      
      Conflicts:
      	Source/WTF/wtf/Atomics.h
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153124 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9397e00c
    • oliver@apple.com's avatar
      fourthTier: value profiles and array profiles should be thread-safe enough to... · c14eb7d0
      oliver@apple.com authored
      fourthTier: value profiles and array profiles should be thread-safe enough to be accessible in a concurrent compilation thread
      https://bugs.webkit.org/show_bug.cgi?id=114906
      
      Source/JavaScriptCore:
      
      Reviewed by Oliver Hunt.
      
      This introduces thread safety to value profiles, array profiles, and
      array allocation profiles.
      
      We already have three separate operations that happen on profiles:
      (1) writing, which the JIT, LLInt, and OSR exit do; (2) updating,
      which happens during GC, from OSR entry slow-paths, and in the DFG;
      and (3) reading, which happens in the DFG. For example, the JIT/LLInt
      and OSR exit write to ValueProfile::m_buckets, which gets synthesized
      into ValueProfile::m_prediction (and other fields) during update, and
      the latter gets read by the DFG. Note that (2) must also happen in
      the DFG since only the DFG knows which code blocks it will inline,
      and those blocks' profiles may not have otherwise been updated via
      any other mechanism.
      
      I refer to these three operations as writing, updating, and reading.
      
      Consequently, both profile updating and profile reading may happen
      asynchronously, if the JIT is asynchronous.
      
      The locking protocol for profiles works as follows:
      
      - Writing does not require locking, but is only allowed on the main
        thread. We require that these fields can be stored atomically by
        the profiling code, even without locks. For value profiles, this
        only works on 64-bit platforms, currently. For array profiles,
        which consist of multiple separate fields, this means that an
        asynchronous update of the profile may see slight inconsistencies
        (like a structure that doesn't quite match the array modes bits),
        but these should be harmless: at worst, the DFG will specialize
        too much and we'll have OSR exits.
      
      - Updating a value profile requires holding a lock, but must assume
        that the fields written by the profiling code in JIT/LLInt may
        be written to without locking.
      
      - Reading a value profile requires holding a lock.
      
      The one major exception to these rules is the ArrayAllocationProfile,
      which requires no locking. We do this because it's used so often and
      in places where we don't necessarily have access to the owning
      CodeBlock, so if we did want it to be locked it would have to have
      its own lock. Also, I believe that it is sound to just make this
      profile racy and not worry about locking at all. All that was needed
      were some changes to ensure that we explicitly read some raced-over
      fields only once.
      
      Two additional interesting things in this change:
      
      - To make it easy to see which profile methods require locking, they
        take a const CodeBlockLocker& as an argument. I saw this idiom for
        identifying which methods require which locks to be held being used
        in LLVM, and I quite like it.
      
      - Lazy operand value profiles, which are created lazily and at any
        time, require the CodeBlockLock to be held when they are being
        created. Writes to them are lockless and main-thread-only, but as
        with other profiles, updates and reads require locking.
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/ArrayAllocationProfile.cpp:
      (JSC::ArrayAllocationProfile::updateIndexingType):
      * bytecode/ArrayAllocationProfile.h:
      (JSC::ArrayAllocationProfile::selectIndexingType):
      * bytecode/ArrayProfile.cpp:
      (JSC::ArrayProfile::computeUpdatedPrediction):
      (JSC::ArrayProfile::briefDescription):
      * bytecode/ArrayProfile.h:
      (ArrayProfile):
      (JSC::ArrayProfile::expectedStructure):
      (JSC::ArrayProfile::structureIsPolymorphic):
      (JSC::ArrayProfile::hasDefiniteStructure):
      (JSC::ArrayProfile::observedArrayModes):
      (JSC::ArrayProfile::mayInterceptIndexedAccesses):
      (JSC::ArrayProfile::mayStoreToHole):
      (JSC::ArrayProfile::outOfBounds):
      (JSC::ArrayProfile::usesOriginalArrayStructures):
      * bytecode/CallLinkStatus.cpp:
      (JSC::CallLinkStatus::computeFor):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dumpValueProfiling):
      (JSC::CodeBlock::dumpArrayProfiling):
      (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
      (JSC::CodeBlock::updateAllArrayPredictions):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
      (JSC::CodeBlock::updateAllPredictionsAndCheckIfShouldOptimizeNow):
      (CodeBlock):
      * bytecode/CodeBlockLock.h: Added.
      (JSC):
      * bytecode/GetByIdStatus.cpp:
      (JSC::GetByIdStatus::computeFor):
      * bytecode/LazyOperandValueProfile.cpp:
      (JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions):
      (JSC::CompressedLazyOperandValueProfileHolder::add):
      (JSC::LazyOperandValueProfileParser::LazyOperandValueProfileParser):
      (JSC::LazyOperandValueProfileParser::~LazyOperandValueProfileParser):
      (JSC):
      (JSC::LazyOperandValueProfileParser::initialize):
      (JSC::LazyOperandValueProfileParser::prediction):
      * bytecode/LazyOperandValueProfile.h:
      (CompressedLazyOperandValueProfileHolder):
      (LazyOperandValueProfileParser):
      * bytecode/MethodOfGettingAValueProfile.cpp:
      (JSC::MethodOfGettingAValueProfile::getSpecFailBucket):
      * bytecode/PutByIdStatus.cpp:
      (JSC::PutByIdStatus::computeFor):
      * bytecode/ResolveGlobalStatus.cpp:
      (JSC::ResolveGlobalStatus::computeFor):
      * bytecode/ValueProfile.h:
      (JSC::ValueProfileBase::briefDescription):
      (ValueProfileBase):
      (JSC::ValueProfileBase::computeUpdatedPrediction):
      * dfg/DFGArrayMode.cpp:
      (JSC::DFG::ArrayMode::fromObserved):
      * dfg/DFGArrayMode.h:
      (ArrayMode):
      (JSC::DFG::ArrayMode::withProfile):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
      (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
      (JSC::DFG::ByteCodeParser::getArrayMode):
      (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
      (JSC::DFG::ByteCodeParser::parseResolveOperations):
      (JSC::DFG::ByteCodeParser::parseBlock):
      (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGOSRExitPreparation.cpp:
      (JSC::DFG::prepareCodeOriginForOSRExit):
      * dfg/DFGPredictionInjectionPhase.cpp:
      (JSC::DFG::PredictionInjectionPhase::run):
      * jit/JITInlines.h:
      (JSC::JIT::chooseArrayMode):
      * jit/JITStubs.cpp:
      (JSC::tryCachePutByID):
      (JSC::tryCacheGetByID):
      (JSC::DEFINE_STUB_FUNCTION):
      (JSC::lazyLinkFor):
      * llint/LLIntSlowPaths.cpp:
      (JSC::LLInt::LLINT_SLOW_PATH_DECL):
      (JSC::LLInt::setUpCall):
      * profiler/ProfilerBytecodeSequence.cpp:
      (JSC::Profiler::BytecodeSequence::BytecodeSequence):
      * runtime/JSScope.cpp:
      (JSC::JSScope::resolveContainingScopeInternal):
      (JSC::JSScope::resolvePut):
      
      Source/WTF:
      
      Reviewed by Oliver Hunt.
      
      Add ability to abstract whether or not the CodeBlock requires locking at all,
      since some platforms may not support the byte spin-locking and/or may not want
      to, if they turn off concurrent JIT.
      
      * WTF.xcodeproj/project.pbxproj:
      * wtf/ByteSpinLock.h:
      * wtf/NoLock.h: Added.
      (WTF):
      (NoLock):
      (WTF::NoLock::lock):
      (WTF::NoLock::unlock):
      (WTF::NoLock::isHeld):
      * wtf/Platform.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153123 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c14eb7d0
    • oliver@apple.com's avatar
      fourthTier: all inline caches should thread-safe enough to allow a concurrent... · 0c1b13e9
      oliver@apple.com authored
      fourthTier: all inline caches should thread-safe enough to allow a concurrent compilation thread to read them safely
      https://bugs.webkit.org/show_bug.cgi?id=114762
      
      Source/JavaScriptCore:
      
      Reviewed by Mark Hahnenberg.
      
      For most inline caches this is easy: the inline cache has a clean temporal
      separation between doing the requested action (which may take an unbounded
      amount of time, may recurse, and may do arbitrary things) and recording the
      relevant information in the cache. So, we just put locks around the
      recording bit. That part is always O(1) and does not recurse. The lock we
      use is per-CodeBlock to achieve a good balance between locking granularity
      and low space overhead. So a concurrent compilation thread will only block
      if an inline cache ping-pongs in the code block being compiled (or inlined)
      and never when other inline caches do things.
      
      For resolve operations, it's a bit tricky. The global resolve bit works
      like any other IC in that it has the clean temporal separation. But the
      operations vector itself doesn't have this separation, since we will be
      filling it in tandem with actions that may take a long time. This patch
      gets around this by having a m_ready bit in the ResolveOperations and
      PutToBaseOperation. This is set while holding the CodeBlock's lock. If the
      DFG observes the m_ready bit not set (while holding the lock) then it
      conservatively assumes that the resolve hasn't happened yet and just
      plants a ForceOSRExit.
      
      * bytecode/CallLinkStatus.cpp:
      (JSC::CallLinkStatus::computeFor):
      * bytecode/CodeBlock.h:
      (CodeBlock):
      * bytecode/GetByIdStatus.cpp:
      (JSC::GetByIdStatus::computeFor):
      * bytecode/PutByIdStatus.cpp:
      (JSC::PutByIdStatus::computeFor):
      * bytecode/ResolveGlobalStatus.cpp:
      (JSC::ResolveGlobalStatus::computeFor):
      * bytecode/ResolveOperation.h:
      (JSC::ResolveOperations::ResolveOperations):
      (ResolveOperations):
      (JSC::PutToBaseOperation::PutToBaseOperation):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseResolveOperations):
      (JSC::DFG::ByteCodeParser::parseBlock):
      * jit/JITStubs.cpp:
      (JSC::tryCachePutByID):
      (JSC::tryCacheGetByID):
      (JSC::DEFINE_STUB_FUNCTION):
      (JSC::lazyLinkFor):
      * llint/LLIntSlowPaths.cpp:
      (JSC::LLInt::LLINT_SLOW_PATH_DECL):
      (JSC::LLInt::setUpCall):
      * runtime/JSScope.cpp:
      (JSC::JSScope::resolveContainingScopeInternal):
      (JSC::JSScope::resolveContainingScope):
      (JSC::JSScope::resolvePut):
      
      Source/WTF:
      
      Reviewed by Mark Hahnenberg.
      
      Implemented a new spinlock that is optimized for compactness, by using just a byte.
      This will be useful as we start using fine-grained locking on a bunch of places.
      
      At some point I'll make these byte-sized spinlocks into adaptive mutexes, but for
      now I think it's fine to do the evil thing and use spinning particularly since we
      only use them for short critical sections.
      
      * WTF.xcodeproj/project.pbxproj:
      * wtf/Atomics.h:
      (WTF):
      (WTF::weakCompareAndSwap):
      * wtf/ByteSpinLock.h: Added.
      (WTF):
      (ByteSpinLock):
      (WTF::ByteSpinLock::ByteSpinLock):
      (WTF::ByteSpinLock::lock):
      (WTF::ByteSpinLock::unlock):
      (WTF::ByteSpinLock::isHeld):
      * wtf/ThreadingPrimitives.h:
      (WTF::pauseBriefly):
      (WTF):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153122 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0c1b13e9
    • oliver@apple.com's avatar
      fourthTier: Landing the initial FTL logic in a single commit to avoid spurious · ea77149c
      oliver@apple.com authored
      broken builds.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153121 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ea77149c
    • oliver@apple.com's avatar
      fourthTier: DFG should be able to query Structure without modifying it · b3956443
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=114708
      
      Reviewed by Oliver Hunt.
      
      This is work towards allowing the DFG, and FTL, to run on a separate thread.
      The idea is that the most evil thing that the DFG does that has thread-safety
      issues is fiddling with Structures by calling Structure::get(). This can lead
      to rematerialization of property tables, which is definitely not thread-safe
      due to how StringImpl works. So, this patch completely side-steps the problem
      by creating a new version of Structure::get, called
      Structure::getWithoutMaterializing, which may choose to do an O(n) search if
      necessary to avoid materialization. I believe this should be fine - the DFG
      does't call into these code path often enough for this to matter, and most of
      the time, the Structure that we call this on will already have a property
      table because some inline cache would have already called ::get() on that
      Structure.
      
      Also cleaned up the materialization logic: we can stop the search as soon as
      we find any Structure with a property table rather than searching all the way
      for a pinned one.
      
      * bytecode/GetByIdStatus.cpp:
      (JSC::GetByIdStatus::computeFor):
      * bytecode/PutByIdStatus.cpp:
      (JSC::PutByIdStatus::computeFromLLInt):
      (JSC::PutByIdStatus::computeFor):
      * runtime/Structure.cpp:
      (JSC::Structure::findStructuresAndMapForMaterialization):
      (JSC::Structure::materializePropertyMap):
      (JSC::Structure::getWithoutMaterializing):
      (JSC):
      * runtime/Structure.h:
      (Structure):
      * runtime/StructureInlines.h:
      (JSC::Structure::getWithoutMaterializing):
      (JSC):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153120 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      b3956443
    • oliver@apple.com's avatar
      fourthTier: DFG should provide utilities for common OSR exit tasks · b9009149
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=114306
      
      Reviewed by Mark Hahnenberg.
      
      Just abstract out some things that the FTL will want to use as well.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * Target.pri:
      * dfg/DFGDriver.cpp:
      (JSC::DFG::compile):
      * dfg/DFGOSRExitCompiler.cpp:
      * dfg/DFGOSRExitCompiler.h:
      (OSRExitCompiler):
      * dfg/DFGOSRExitCompiler32_64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * dfg/DFGOSRExitCompiler64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * dfg/DFGOSRExitCompilerCommon.cpp: Added.
      (DFG):
      (JSC::DFG::handleExitCounts):
      (JSC::DFG::reifyInlinedCallFrames):
      (JSC::DFG::adjustAndJumpToTarget):
      * dfg/DFGOSRExitCompilerCommon.h: Added.
      (DFG):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153119 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      b9009149
    • oliver@apple.com's avatar
      fourthTier: DFG should better abstract floating point arguments · 72e4b52f
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=114300
      
      Reviewed by Mark Hahnenberg.
      
      * dfg/DFGFPRInfo.h:
      (FPRInfo):
      (JSC::DFG::FPRInfo::toArgumentRegister):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153118 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      72e4b52f
    • oliver@apple.com's avatar
      fourthTier: DFG should better abstract arguments · b0430fb6
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=114073
      
      Reviewed by Mark Hahnenberg.
      
      * dfg/DFGGPRInfo.h:
      (GPRInfo):
      (JSC::DFG::GPRInfo::toArgumentRegister):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153117 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      b0430fb6
    • oliver@apple.com's avatar
      fourthTier: put DFG data into a DFG::JITCode, and put common DFG and FTL data... · 02b179b1
      oliver@apple.com authored
      fourthTier: put DFG data into a DFG::JITCode, and put common DFG and FTL data into something accessible from both DFG::JITCode and FTL::JITCode
      https://bugs.webkit.org/show_bug.cgi?id=113905
      
      Reviewed by Geoffrey Garen.
      
      This removes one pointer from CodeBlock.
      
      It also gives us a framework for having JITType-specific data in CodeBlock, by
      putting it into the appropriate JITCode class (either DFG::JITCode or
      FTL::JITCode). And it allows us to have DFG and FTL share some common data,
      via DFG::CommonData, which is stored in both DFG::JITCode and FTL::JITCode and
      always accessible via JITCode::dfgCommon().
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * Target.pri:
      * bytecode/CodeBlock.cpp:
      (JSC):
      (JSC::CodeBlock::dumpBytecode):
      (JSC::CodeBlock::visitAggregate):
      (JSC::CodeBlock::performTracingFixpointIteration):
      (JSC::CodeBlock::finalizeUnconditionally):
      (JSC::CodeBlock::stronglyVisitWeakReferences):
      (JSC::CodeBlock::shrinkToFit):
      (JSC::CodeBlock::tallyFrequentExitSites):
      * bytecode/CodeBlock.h:
      (CodeBlock):
      (JSC::CodeBlock::setJITCode):
      (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan):
      (JSC::DFGCodeBlocks::mark):
      * dfg/DFGAssemblyHelpers.h:
      * dfg/DFGCommonData.cpp: Added.
      (DFG):
      (JSC::DFG::CommonData::notifyCompilingStructureTransition):
      (JSC::DFG::CommonData::shrinkToFit):
      * dfg/DFGCommonData.h: Added.
      (JSC):
      (DFG):
      (JSC::DFG::WeakReferenceTransition::WeakReferenceTransition):
      (WeakReferenceTransition):
      (CommonData):
      (JSC::DFG::CommonData::CommonData):
      * dfg/DFGDriver.cpp:
      (JSC::DFG::compile):
      (JSC::DFG::tryCompile):
      (JSC::DFG::tryCompileFunction):
      * dfg/DFGDriver.h:
      (DFG):
      (JSC::DFG::tryCompile):
      (JSC::DFG::tryCompileFunction):
      * dfg/DFGGraph.h:
      (Graph):
      * dfg/DFGJITCode.cpp: Added.
      (DFG):
      (JSC::DFG::JITCode::JITCode):
      (JSC::DFG::JITCode::~JITCode):
      (JSC::DFG::JITCode::dfgCommon):
      (JSC::DFG::JITCode::dfg):
      (JSC::DFG::JITCode::shrinkToFit):
      * dfg/DFGJITCode.h: Added.
      (DFG):
      (JITCode):
      (JSC::DFG::JITCode::appendOSREntryData):
      (JSC::DFG::JITCode::osrEntryDataForBytecodeIndex):
      (JSC::DFG::JITCode::appendOSRExit):
      (JSC::DFG::JITCode::lastOSRExit):
      (JSC::DFG::JITCode::appendSpeculationRecovery):
      (JSC::DFG::JITCode::appendWatchpoint):
      * dfg/DFGJITCompiler.cpp:
      (JSC::DFG::JITCompiler::JITCompiler):
      (JSC::DFG::JITCompiler::linkOSRExits):
      (JSC::DFG::JITCompiler::link):
      (JSC::DFG::JITCompiler::compile):
      (JSC::DFG::JITCompiler::compileFunction):
      * dfg/DFGJITCompiler.h:
      (JITCompiler):
      (JSC::DFG::JITCompiler::addWeakReference):
      (JSC::DFG::JITCompiler::noticeOSREntry):
      (JSC::DFG::JITCompiler::jitCode):
      * dfg/DFGOSREntry.cpp:
      (JSC::DFG::prepareOSREntry):
      * dfg/DFGOSRExit.h:
      (OSRExit):
      * dfg/DFGOSRExitCompiler.cpp:
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
      (JSC::DFG::SpeculativeJIT::backwardSpeculationCheck):
      (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
      (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGVariableEventStream.cpp:
      * ftl/FTLCompile.cpp:
      (JSC::FTL::compile):
      * ftl/FTLJITCode.cpp:
      (JSC::FTL::JITCode::JITCode):
      (JSC::FTL::JITCode::~JITCode):
      (FTL):
      (JSC::FTL::JITCode::initializeCode):
      (JSC::FTL::JITCode::addressForCall):
      (JSC::FTL::JITCode::executableAddressAtOffset):
      (JSC::FTL::JITCode::dataAddressAtOffset):
      (JSC::FTL::JITCode::offsetOf):
      (JSC::FTL::JITCode::size):
      (JSC::FTL::JITCode::contains):
      (JSC::FTL::JITCode::ftl):
      (JSC::FTL::JITCode::dfgCommon):
      * ftl/FTLJITCode.h:
      (JITCode):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileStructureTransitionWatchpoint):
      (JSC::FTL::LowerDFGToLLVM::compilePutStructure):
      (JSC::FTL::LowerDFGToLLVM::compilePhantomPutStructure):
      (JSC::FTL::LowerDFGToLLVM::addWeakReference):
      (LowerDFGToLLVM):
      (JSC::FTL::LowerDFGToLLVM::weakPointer):
      * ftl/FTLState.cpp:
      (FTL):
      (JSC::FTL::State::State):
      (JSC::FTL::State::dumpState):
      * ftl/FTLState.h:
      (State):
      * heap/DFGCodeBlocks.cpp:
      (JSC::DFGCodeBlocks::~DFGCodeBlocks):
      (JSC::DFGCodeBlocks::jettison):
      (JSC::DFGCodeBlocks::clearMarks):
      (JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks):
      (JSC::DFGCodeBlocks::traceMarkedCodeBlocks):
      * jit/JITCode.cpp:
      (JSC::JITCode::dfgCommon):
      (JSC):
      (JSC::JITCode::dfg):
      (JSC::JITCode::ftl):
      (JSC::DirectJITCode::DirectJITCode):
      (JSC::DirectJITCode::initializeCodeRef):
      (JSC::DirectJITCode::addressForCall):
      (JSC::DirectJITCode::executableAddressAtOffset):
      (JSC::DirectJITCode::dataAddressAtOffset):
      (JSC::DirectJITCode::offsetOf):
      (JSC::DirectJITCode::size):
      (JSC::DirectJITCode::contains):
      * jit/JITCode.h:
      (DFG):
      (FTL):
      (JSC):
      (JITCode):
      (DirectJITCode):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153116 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      02b179b1
    • oliver@apple.com's avatar
      fourthTier: Everyone should know about the FTL · 56f0addc
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113897
      
      Reviewed by Mark Hahnenberg.
      
      In order to get OSR exit to work right, we need the distinction between DFG and
      FTL to be clear even after compilation finishes, since they will have subtly
      different OSR stories and likely use different data structures.
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::resetStubInternal):
      (JSC::ProgramCodeBlock::compileOptimized):
      (JSC::EvalCodeBlock::compileOptimized):
      (JSC::FunctionCodeBlock::compileOptimized):
      (JSC::CodeBlock::adjustedExitCountThreshold):
      (JSC::CodeBlock::tallyFrequentExitSites):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::setJITCode):
      (JSC::CodeBlock::hasOptimizedReplacement):
      (JSC::ExecState::isInlineCallFrame):
      * ftl/FTLCompile.cpp:
      (JSC::FTL::compile):
      * ftl/FTLJITCode.cpp:
      (JSC::FTL::JITCode::JITCode):
      * ftl/FTLState.cpp:
      (JSC::FTL::State::dumpState):
      * heap/DFGCodeBlocks.cpp:
      (JSC::DFGCodeBlocks::jettison):
      * interpreter/Interpreter.cpp:
      (JSC::getLineNumberForCallFrame):
      (JSC::getCallerInfo):
      * jit/JITCode.cpp:
      (WTF::printInternal):
      * jit/JITCode.h:
      (JSC::JITCode::topTierJIT):
      (JSC::JITCode::nextTierJIT):
      (JITCode):
      (JSC::JITCode::isJIT):
      (JSC::JITCode::isLowerTier):
      (JSC::JITCode::isHigherTier):
      (JSC::JITCode::isLowerOrSameTier):
      (JSC::JITCode::isHigherOrSameTier):
      (JSC::JITCode::isOptimizingJIT):
      * jit/JITDriver.h:
      (JSC::jitCompileIfAppropriate):
      (JSC::jitCompileFunctionIfAppropriate):
      * jit/JITStubs.cpp:
      (JSC::DEFINE_STUB_FUNCTION):
      * runtime/Executable.cpp:
      (JSC::EvalExecutable::compileOptimized):
      (JSC::samplingDescription):
      (JSC::ProgramExecutable::compileOptimized):
      (JSC::FunctionExecutable::compileOptimizedForCall):
      (JSC::FunctionExecutable::compileOptimizedForConstruct):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153115 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      56f0addc
    • oliver@apple.com's avatar
      fourthTier: DFG should abstract out how it does forward exits, and that code should be simplified · c02ffd60
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113894
      
      Reviewed by Mark Hahnenberg.
      
      1) We previously had two different ways of convertingToForward, one path for
         where we had a ValueRecovery for the current node and one where we didn't.
         But the paths were doing exactly the same thing except that if you have a
         ValueRecovery, you also find the last applicable mov hint and do some
         extra things. This patch combines the two paths and bases both of them on
         the previous no-ValueRecovery path, which was simpler to begin with.
      
      2) This moves the logic into DFG::OSRExit, which further simplifies the code
         and makes the logic available to the FTL.
      
      * dfg/DFGOSRExit.cpp:
      (JSC::DFG::OSRExit::convertToForward):
      (DFG):
      * dfg/DFGOSRExit.h:
      (DFG):
      (OSRExit):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153114 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c02ffd60
    • oliver@apple.com's avatar
      fourthTier: JITCode should abstract exactly how the JIT code is structured and... · 9a1ae938
      oliver@apple.com authored
      fourthTier: JITCode should abstract exactly how the JIT code is structured and where it was allocated
      https://bugs.webkit.org/show_bug.cgi?id=113437
      
      Reviewed by Mark Hahnenberg.
      
      JITCode is now a virtual base class, which will allow different JITs to have radically
      different memory allocation and management conventions in the future. It will also
      make it easier to store JIT-specific meta-data in CodeBlock just by putting it into
      an appropriate JITCode subclass.
      
      For now there is one subclass, DirectJITCode, which just behaves like JITCode used to
      behave.
      
      * assembler/RepatchBuffer.h:
      (JSC::RepatchBuffer::RepatchBuffer):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::resetStubInternal):
      (JSC::CodeBlock::bytecodeOffset):
      (JSC::CodeBlock::codeOriginForReturn):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::setJITCode):
      (JSC::CodeBlock::getJITCode):
      (JSC::CodeBlock::getJITType):
      (CodeBlock):
      * dfg/DFGDriver.cpp:
      (JSC::DFG::compile):
      (JSC::DFG::tryCompile):
      (JSC::DFG::tryCompileFunction):
      * dfg/DFGDriver.h:
      (DFG):
      (JSC::DFG::tryCompile):
      (JSC::DFG::tryCompileFunction):
      * dfg/DFGJITCompiler.cpp:
      (JSC::DFG::JITCompiler::compile):
      (JSC::DFG::JITCompiler::compileFunction):
      * dfg/DFGJITCompiler.h:
      (JITCompiler):
      * dfg/DFGOSREntry.cpp:
      (JSC::DFG::prepareOSREntry):
      * dfg/DFGOSRExit.cpp:
      (JSC::DFG::OSRExit::codeLocationForRepatch):
      * dfg/DFGOSRExitCompiler32_64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * dfg/DFGOSRExitCompiler64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * dfg/DFGOperations.cpp:
      * interpreter/Interpreter.cpp:
      (JSC::Interpreter::execute):
      (JSC::Interpreter::executeCall):
      (JSC::Interpreter::executeConstruct):
      * jit/JIT.cpp:
      (JSC::JIT::privateCompile):
      * jit/JIT.h:
      (JSC::JIT::compile):
      (JIT):
      * jit/JITCode.cpp:
      (JSC):
      (JSC::JITCode::JITCode):
      (JSC::JITCode::~JITCode):
      (JSC::JITCode::execute):
      (JSC::JITCode::hostFunction):
      (JSC::DirectJITCode::DirectJITCode):
      (JSC::DirectJITCode::~DirectJITCode):
      (JSC::DirectJITCode::addressForCall):
      (JSC::DirectJITCode::executableAddressAtOffset):
      (JSC::DirectJITCode::dataAddressAtOffset):
      (JSC::DirectJITCode::offsetOf):
      (JSC::DirectJITCode::size):
      (JSC::DirectJITCode::contains):
      * jit/JITCode.h:
      (JSC):
      (JITCode):
      (JSC::JITCode::bottomTierJIT):
      (JSC::JITCode::topTierJIT):
      (JSC::JITCode::nextTierJIT):
      (JSC::JITCode::isOptimizingJIT):
      (JSC::JITCode::isBaselineCode):
      (JSC::JITCode::jitType):
      (JSC::JITCode::jitTypeFor):
      (JSC::JITCode::executableAddress):
      (JSC::JITCode::start):
      (JSC::JITCode::end):
      (DirectJITCode):
      * jit/JITDriver.h:
      (JSC::jitCompileIfAppropriate):
      (JSC::jitCompileFunctionIfAppropriate):
      * jit/JITStubs.cpp:
      (JSC::lazyLinkFor):
      (JSC::DEFINE_STUB_FUNCTION):
      * jit/ThunkGenerators.cpp:
      (JSC::virtualForGenerator):
      * llint/LLIntEntrypoints.cpp:
      (JSC::LLInt::getFunctionEntrypoint):
      (JSC::LLInt::getEvalEntrypoint):
      (JSC::LLInt::getProgramEntrypoint):
      * llint/LLIntEntrypoints.h:
      (JSC):
      (LLInt):
      (JSC::LLInt::getEntrypoint):
      * llint/LLIntSlowPaths.cpp:
      (JSC::LLInt::jitCompileAndSetHeuristics):
      (JSC::LLInt::entryOSR):
      (JSC::LLInt::LLINT_SLOW_PATH_DECL):
      * runtime/Executable.cpp:
      (JSC::EvalExecutable::compileInternal):
      (JSC::ProgramExecutable::compileInternal):
      (JSC::FunctionExecutable::compileForCallInternal):
      (JSC::FunctionExecutable::compileForConstructInternal):
      * runtime/Executable.h:
      (JSC::ExecutableBase::generatedJITCodeForCall):
      (JSC::ExecutableBase::generatedJITCodeForConstruct):
      (JSC::ExecutableBase::generatedJITCodeFor):
      (ExecutableBase):
      (JSC::ExecutableBase::hostCodeEntryFor):
      (JSC::ExecutableBase::jsCodeEntryFor):
      (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor):
      (JSC::NativeExecutable::create):
      (JSC::NativeExecutable::finishCreation):
      (JSC::EvalExecutable::generatedJITCode):
      (JSC::ProgramExecutable::generatedJITCode):
      * runtime/ExecutionHarness.h:
      (JSC::prepareForExecution):
      (JSC::prepareFunctionForExecution):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153113 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9a1ae938
    • simon.fraser@apple.com's avatar
      [iOS] Captions are clipped in documents using pagination · 429afd29
      simon.fraser@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=119072
      
      Reviewed by Beth Dakin.
      
      MediaControlTextTrackContainerElement::createTextTrackRepresentationImage() is called
      to paint captions into a layer used for fullscreen video. It did the painting using
      a subtree paint, but starting at the root RenderView's layer. This is problematic,
      because the caption painting is subject to clipping for columns, and any enclosing
      overflow:hidden container.
      
      Fix this by starting the paint at the MediaControlTextTrackContainerElement's
      renderer's layer. By doing this we don't have to worry about an offset, so no
      translation is required.
      
      Also make sure we update layer before grabbing the renderer (in case layout
      destroys it).
      
      * html/shadow/MediaControlElements.cpp:
      (WebCore::MediaControlTextTrackContainerElement::createTextTrackRepresentationImage):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153112 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      429afd29
    • dbates@webkit.org's avatar
      Add DRT test to ensure don't override z-index for overflow: scroll,... · f322964e
      dbates@webkit.org authored
      Add DRT test to ensure don't override z-index for overflow: scroll, -webkit-overflow-scrolling: touch
      https://bugs.webkit.org/show_bug.cgi?id=119071
      
      Reviewed by Simon Fraser.
      
      Add a DRT test to ensure we don't regress the fix for <https://bugs.webkit.org/show_bug.cgi?id=119066>.
      
      * compositing/overflow/should-not-override-z-index-for-element-with-non-auto-z-index-and-overflow-scroll-and-touch-expected.txt: Added.
      * compositing/overflow/should-not-override-z-index-for-element-with-non-auto-z-index-and-overflow-scroll-and-touch.html: Added.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153111 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      f322964e
    • ruth_fong@apple.com's avatar
      Rename WebColorChooserProxy · 0a7a361b
      ruth_fong@apple.com authored
      <rdar://problem/14528039> and https://bugs.webkit.org/show_bug.cgi?id=119025
      
      Reviewed by Brady Eidson.
      
      Renamed WebColorChooserProxy to WebColorPicker since the name WebColorChoooserProxy
      implies that it represents the same object as WebColorChooser, which is not true.
      Also, renamed createColorChooserProxy to createColorPicker in WebPageProxy and
      platform-equivalent versions of it.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * Target.pri:
      * UIProcess/API/gtk/PageClientImpl.cpp:
      (WebKit::PageClientImpl::createColorPicker):
      * UIProcess/API/gtk/PageClientImpl.h:
      * UIProcess/API/mac/PageClientImpl.h:
      * UIProcess/API/mac/PageClientImpl.mm:
      (WebKit::PageClientImpl::createColorPicker):
      * UIProcess/API/qt/raw/qrawwebview.cpp:
      (QRawWebViewPrivate::createColorPicker):
      * UIProcess/API/qt/raw/qrawwebview_p_p.h:
      * UIProcess/CoordinatedGraphics/WebView.cpp:
      (WebKit::WebView::createColorPicker):
      * UIProcess/CoordinatedGraphics/WebView.h:
      * UIProcess/PageClient.h:
      * UIProcess/WebColorChooserProxy.cpp: Removed.
      * UIProcess/WebColorChooserProxy.h: Removed.
      * UIProcess/WebColorPicker.cpp: Copied from Source/WebKit2/UIProcess/WebColorChooserProxy.cpp.
      (WebKit::WebColorPicker::WebColorPicker):
      (WebKit::WebColorPicker::~WebColorPicker):
      (WebKit::WebColorPicker::endChooser):
      (WebKit::WebColorPicker::setSelectedColor):
      * UIProcess/WebColorPicker.h: Copied from Source/WebKit2/UIProcess/WebColorChooserProxy.h.
      (WebKit::WebColorPicker::create):
      * UIProcess/WebPageProxy.cpp:
      (WebKit::WebPageProxy::close):
      (WebKit::WebPageProxy::showColorChooser):
      (WebKit::WebPageProxy::setColorChooserColor):
      (WebKit::WebPageProxy::endColorChooser):
      (WebKit::WebPageProxy::didEndColorChooser):
      (WebKit::WebPageProxy::resetStateAfterProcessExited):
      * UIProcess/WebPageProxy.h: Renamed m_colorChooser to m_colorPicker.
      * UIProcess/qt/QtPageClient.cpp:
      (WebKit::QtPageClient::createColorPicker):
      * UIProcess/qt/QtPageClient.h:
      * UIProcess/qt/WebColorChooserProxyQt.cpp: Removed.
      * UIProcess/qt/WebColorChooserProxyQt.h: Removed.
      * UIProcess/qt/WebColorPickerQt.cpp: Added.
      (WebKit::ColorChooserContextObject::ColorChooserContextObject):
      (WebKit::ColorChooserContextObject::currentColor):
      (WebKit::ColorChooserContextObject::elementRect):
      (WebKit::ColorChooserContextObject::accept):
      (WebKit::ColorChooserContextObject::reject):
      (WebKit::WebColorPickerQt::WebColorPickerQt):
      (WebKit::WebColorPickerQt::~WebColorPickerQt):
      (WebKit::WebColorPickerQt::createItem):
      (WebKit::WebColorPickerQt::createContext):
      (WebKit::WebColorPickerQt::setSelectedColor):
      (WebKit::WebColorPickerQt::notifyColorSelected):
      (WebKit::WebColorPickerQt::endChooser):
      * UIProcess/qt/WebColorPickerQt.h: Added.
      (WebKit::WebColorPickerQt::create):
      * WebKit2.xcodeproj/project.pbxproj:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153108 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0a7a361b
    • andersca@apple.com's avatar
      Crash when calling WKPageGetProcessIdentifier after aborted process launch · 16a649dc
      andersca@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=119069
      <rdar://problem/14494064>
      
      Reviewed by Andreas Kling.
      
      Source/WebKit2:
      
      * UIProcess/WebPageProxy.cpp:
      (WebKit::WebPageProxy::processIdentifier):
      Check if the page is closed instead of checking whether we have a process - We'll always have a process.
      
      (WebKit::WebPageProxy::isValid):
      Make this const.
      
      * UIProcess/WebPageProxy.h:
      
      Tools:
      
      Add a test.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebKit2/mac/GetPIDAfterAbortedProcessLaunch.cpp: Added.
      (TestWebKitAPI::didFinishLoadForFrame):
      (TestWebKitAPI::TEST):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153107 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      16a649dc
    • kseo@webkit.org's avatar
      [WK2][Soup] Add entry point for network process · c73808f2
      kseo@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=110136
      
      Reviewed by Gustavo Noronha Silva.
      
      Original patch by Balazs Kelemen <kbalazs@webkit.org>.
      
      Added a common entry point for non-Mac Unix ports.
      
      * NetworkProcess/unix/NetworkProcessMainUnix.cpp: Added.
      (WebKit::NetworkProcessMain):
      * NetworkProcess/unix/NetworkProcessMainUnix.h: Added.
      * unix/NetworkMainUnix.cpp: Added.
      (main):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153106 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c73808f2
    • simon.fraser@apple.com's avatar
      REGRESSION (r152335): Mac Pro title occluded in MobileSafari; can't scroll page · 2677ced8
      simon.fraser@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=119066
      <rdar://problem/14499184>
      
      Reviewed by Daniel Bates.
      
      Following <http://trac.webkit.org/changeset/152335> (bug #118337) we set
      the z-index to 0 on every element with CSS "overflow: scroll" and
      "-webkit-overflow-scrolling: touch" regardless of whether the element has
      non-auto z-index. Instead we should only set the z-index to 0 for such elements
      that have an auto z-index.
      
      * css/StyleResolver.cpp:
      (WebCore::StyleResolver::adjustRenderStyle):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153105 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2677ced8
    • fpizlo@apple.com's avatar
      It should be possible to hijack IndexingHeader for things other than lengths · 85eb7df9
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=119065
      
      Reviewed by Mark Hahnenberg.
              
      Made the body of IndexingHeader be a union.
              
      Modified the offlineasm so that you can say IndexingHeader::u.lengths.publicLength.
      Previously those dots would cause parse errors. Now an identifier in offlineasm can
      have a dot anywhere except the first character.
      
      * llint/LowLevelInterpreter32_64.asm:
      * llint/LowLevelInterpreter64.asm:
      * offlineasm/parser.rb:
      * runtime/IndexingHeader.h:
      (JSC::IndexingHeader::offsetOfPublicLength):
      (JSC::IndexingHeader::offsetOfVectorLength):
      (JSC::IndexingHeader::IndexingHeader):
      (JSC::IndexingHeader::vectorLength):
      (JSC::IndexingHeader::setVectorLength):
      (JSC::IndexingHeader::publicLength):
      (JSC::IndexingHeader::setPublicLength):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153104 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      85eb7df9
    • rniwa@webkit.org's avatar
      Use-after-free in ApplyStyleCommand::removeInlineStyle · 7e9bb4ce
      rniwa@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=118627
      
      Reviewed by Oliver Hunt.
              
      Merge https://chromium.googlesource.com/chromium/blink/+/b6471d077e012b05ccba14d0ce8e6d616106c8e6
      
      Unfortunately, there is no test case for this bug.
      
      * editing/ApplyStyleCommand.cpp:
      (WebCore::ApplyStyleCommand::removeInlineStyle):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153102 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7e9bb4ce
    • achristensen@apple.com's avatar
      Generate derived files in ANGLE at build time rather than when updating from upstream. · 32a3ed38
      achristensen@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118872
      
      Reviewed by Mark Rowe.
      
      * ANGLE.xcodeproj/project.pbxproj: Made Derived Sources target which calls DerivedSources.make,
      moved generated files into Derived Sources group.
      * DerivedSources.make: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153101 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      32a3ed38
    • mhahnenberg@apple.com's avatar
      JIT::updateTopCallFrame doesn't update the CallFrame's bytecodeOffset if bytecodeOffset == 0 · 1b864dac
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118923
      
      Reviewed by Filip Pizlo.
      
      This bug causes the CallFrame's bytecodeOffset to not be properly set when we
      enter, e.g., cti_optimize from an op_enter.
      
      * jit/JITInlines.h:
      (JSC::JIT::updateTopCallFrame):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153097 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      1b864dac
    • jberlin@webkit.org's avatar
      Remove WKPageGetPlugInInformation - it is not used anymore · 172c3cb3
      jberlin@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=119047
      
      Reviewed by Alexey Proskuryakov.
      
      Revert r151172, which fixed a crash introduced in r151043, r151054, which fixed some naming
      and ref-churn issues introduced in r151043, and r151043, which added
      WKPageGetPlugInInformation.
      
      * UIProcess/API/C/mac/WKPagePrivateMac.cpp:
      (WKPageIsURLKnownHSTSHost):
      * UIProcess/API/C/mac/WKPagePrivateMac.h:
      * UIProcess/Plugins/PluginProcessManager.h:
      * UIProcess/Plugins/mac/PluginProcessManagerMac.mm:
      * UIProcess/WebPageProxy.cpp:
      (WebKit::WebPageProxy::close):
      * UIProcess/WebPageProxy.h:
      * UIProcess/WebPageProxy.messages.in:
      * UIProcess/mac/WebPageProxyMac.mm:
      * WebProcess/Plugins/Netscape/NetscapePlugin.h:
      * WebProcess/Plugins/PDF/SimplePDFPlugin.h:
      * WebProcess/Plugins/Plugin.h:
      * WebProcess/Plugins/PluginProxy.h:
      * WebProcess/Plugins/PluginView.h:
      * WebProcess/WebPage/WebPage.h:
      * WebProcess/WebPage/WebPage.messages.in:
      * WebProcess/WebPage/mac/WebPageMac.mm:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153096 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      172c3cb3
    • zandobersek@gmail.com's avatar
      Remove CheckedInt, use Checked<T, RecordOverflow> instead · bbad71f1
      zandobersek@gmail.com authored
      https://bugs.webkit.org/show_bug.cgi?id=119022
      
      Reviewed by Oliver Hunt.
      
      Following the cleanup in r153062, the CheckedInt uses are replaced with
      using the Checked<T, RecordOverflow> class. The CheckedInt header is not
      used anywhere anymore and is thus removed.
      
      * GNUmakefile.list.am:
      * WebCore.xcodeproj/project.pbxproj:
      * html/canvas/CheckedInt.h: Removed.
      * html/canvas/DataView.cpp:
      (WebCore::DataView::create):
      * html/canvas/WebGLBuffer.cpp:
      (WebCore::WebGLBuffer::associateBufferSubDataImpl):
      * html/canvas/WebGLRenderingContext.cpp:
      (WebCore::WebGLRenderingContext::drawArrays):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153095 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      bbad71f1
    • akling@apple.com's avatar
      RenderMenuList computes the width of its longest option twice. · 5d5175c6
      akling@apple.com authored
      <http://webkit.org/b/119046>
      <rdar://problem/14534679>
      
      Reviewed by Darin Adler.
      
      Rename the RenderMenuList::m_optionsChanged flag to m_needsOptionsWidthUpdate,
      and make sure it gets cleared after we do a width computation in response to font changes.
      
      * rendering/RenderMenuList.cpp:
      (WebCore::RenderMenuList::styleDidChange):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153094 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5d5175c6
    • zandobersek@gmail.com's avatar
      Make KURL::hasPath private · 48fa4212
      zandobersek@gmail.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118279
      
      Reviewed by Darin Adler.
      
      Source/WebCore: 
      
      * platform/KURL.h: The KURL::hasPath method is not used outside of the KURL class, so it is made private.
      
      Tools: 
      
      * TestWebKitAPI/Tests/WebCore/KURL.cpp:
      (TestWebKitAPI::TEST_F): Remove references to KURL::hasPath the method is now private and thus not accessible for testing.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153093 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      48fa4212
    • jberlin@webkit.org's avatar
      Remove WKPageGetPlugInInformation - it is not used anymore · 98e1cb89
      jberlin@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=119047
      
      Rubber-stamped by Alexey Proskuryakov.
      
      Revert r152328, which added a key used only in the callback info for
      WKPageGetPlugInInformation.
      
      Source/WebCore:
      
      * WebCore.exp.in:
      
      Source/WebKit2:
      
      * Shared/API/c/WKPluginInformation.cpp:
      * Shared/API/c/WKPluginInformation.h:
      * Shared/Plugins/Netscape/PluginInformation.cpp:
      * Shared/Plugins/Netscape/PluginInformation.h:
      * UIProcess/WebPageProxy.h:
      * UIProcess/WebPageProxy.messages.in:
      * UIProcess/mac/WebPageProxyMac.mm:
      (WebKit::WebPageProxy::containsPlugInCallback):
      * WebProcess/WebPage/mac/WebPageMac.mm:
      (WebKit::WebPage::containsPluginViewsWithPluginProcessToken):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153092 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      98e1cb89
    • graouts@apple.com's avatar
      Web Inspector: control+clicking on a numeric token should not show the context menu · 8a1ffaf6
      graouts@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=119048
      
      Reviewed by Timothy Hatcher.
      
      Track "contextmenu" events when we're hovering a token containing a numeric value
      and call preventDefault() in the event handler to ensure that the context menu does
      not appear.
      
      * UserInterface/CodeMirrorDragToAlterNumberController.js:
      (WebInspector.CodeMirrorDragToAlterNumberController.prototype.handleEvent):
      (WebInspector.CodeMirrorDragToAlterNumberController.prototype._setTracksMouseClickAndDrag):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153091 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8a1ffaf6
    • robert@webkit.org's avatar
      Border drawing incorrect when using both border-collapse: collapse and overflow: hidden on a table · 4831816e
      robert@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=18305
      
      Reviewed by David Hyatt.
      
      Source/WebCore:
      
      overflowClipRect() clips out the table's half of a collapsed border when there is an overflow clip
      on the table. This prevents the table's half of the border ever getting painted.
      
      To fix this, clip to the border box of tables when we're in the paint phase that gets the sections to draw the collapsed borders
      or when we're self painting. This will allow the table's half of the border to get painted. In the case where the table is self
      painting we ensure that content gets clipped to cell's side of the collapsed border by ensuring the clip passed to child layers
      from the table clips to the inside of the collapsed border.
      
      It's worth noting that a table's collapsed borders are painted by the table's layer using functions in
      RenderTableSection and RenderTableCell. So if a table section has a self-painting layer this patch still works, because
      the borders aren't painted by the section's layer.
      
      Tests: fast/table/overflow-table-collapsed-borders-cell-painting-table-self-painting-layer.html
             fast/table/overflow-table-collapsed-borders-cell-painting.html
             fast/table/overflow-table-collapsed-borders-section-layer-painting.html
             fast/table/overflow-table-collapsed-borders-section-layer-table-self-painting-layer.html
             fast/table/overflow-table-collapsed-borders-section-self-painting-layer-painting.html
             fast/table/overflow-table-collapsed-borders-section-self-painting-layer-table-self-painting-layer.html
             fast/table/table-overflow.html
      
      * rendering/RenderBox.cpp:
      (WebCore::RenderBox::pushContentsClip):
      (WebCore::RenderBox::overflowClipRect):
      * rendering/RenderBox.h:
      (WebCore::RenderBox::overflowClipRectForChildLayers):
      * rendering/RenderLayer.cpp:
      (WebCore::RenderLayer::calculateClipRects):
      * rendering/RenderTable.cpp:
      (WebCore::RenderTable::overflowClipRect):
      * rendering/RenderTable.h:
      (WebCore::RenderTable::overflowClipRectForChildLayers):
      
      LayoutTests:
      
      * fast/table/overflow-table-collapsed-borders-cell-painting-expected.png: Added.
      * fast/table/overflow-table-collapsed-borders-cell-painting-expected.txt: Added.
      * fast/table/overflow-table-collapsed-borders-cell-painting-table-self-painting-layer-expected.png: Added.
      * fast/table/overflow-table-collapsed-borders-cell-painting-table-self-painting-layer-expected.txt: Added.
      * fast/table/overflow-table-collapsed-borders-cell-painting-table-self-painting-layer.html: Added.
      * fast/table/overflow-table-collapsed-borders-cell-painting.html: Added.
      * fast/table/overflow-table-collapsed-borders-section-layer-painting-expected.png: Added.
      * fast/table/overflow-table-collapsed-borders-section-layer-painting-expected.txt: Added.
      * fast/table/overflow-table-collapsed-borders-section-layer-painting.html: Added.
      * fast/table/overflow-table-collapsed-borders-section-layer-table-self-painting-layer-expected.png: Added.
      * fast/table/overflow-table-collapsed-borders-section-layer-table-self-painting-layer-expected.txt: Added.
      * fast/table/overflow-table-collapsed-borders-section-layer-table-self-painting-layer.html: Added.
      * fast/table/overflow-table-collapsed-borders-section-self-painting-layer-painting-expected.png: Added.
      * fast/table/overflow-table-collapsed-borders-section-self-painting-layer-painting-expected.txt: Added.
      * fast/table/overflow-table-collapsed-borders-section-self-painting-layer-painting.html: Added.
      * fast/table/overflow-table-collapsed-borders-section-self-painting-layer-table-self-painting-layer-expected.png: Added.
      * fast/table/overflow-table-collapsed-borders-section-self-painting-layer-table-self-painting-layer-expected.txt: Added.
      * fast/table/overflow-table-collapsed-borders-section-self-painting-layer-table-self-painting-layer.html: Added.
      * fast/table/table-overflow-expected.html: Added.
      * fast/table/table-overflow.html: Added.
      * platform/qt/fast/table/overflowHidden-expected.txt:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153089 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4831816e
    • commit-queue@webkit.org's avatar
      Graphical elements inside mphantom should not be visible. · da2bc021
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=116600.
      
      Patch by Frédéric Wang <fred.wang@free.fr> on 2013-07-24
      Reviewed by Chris Fleizach.
      
      Source/WebCore:
      
      Test: mathml/presentation/phantom.html
      
      * rendering/mathml/RenderMathMLFraction.cpp:
      (WebCore::RenderMathMLFraction::paint): don't paint the fraction bar when the visibility is not "visible"
      * rendering/mathml/RenderMathMLRoot.cpp:
      (WebCore::RenderMathMLRoot::paint): don't paint the radical symbol when the visibility is not "visible"
      
      LayoutTests:
      
      * mathml/presentation/phantom-expected.html: Added.
      * mathml/presentation/phantom.html: Added.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153088 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      da2bc021
    • graouts@apple.com's avatar
      Web Inspector: support click-and-drag editing of CSS numeric values · 930aea84
      graouts@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118896
      
      Reviewed by Timothy Hatcher.
      
      Add support for adjustment of numeric values in the various CodeMirror editors
      by holding the option key and dragging the mouse. By default, dragging one pixel
      changes the value by 1, but key modifiers allow to customize that behavior by using
      the control key to change the value to 0.1 and the shift key to change the value to 10.
      
      * UserInterface/CodeMirrorAdditions.js:
      Split adjustNumber() into two methods such that we may use its logic from the
      CodeMirrorDragToAlterNumberController. The new method, CodeMirror.prototype.alterNumberInRange()
      allow to set begin and end CodeMirror positions such that the existing alterNumber()
      can use information based on the current cursor position, and CodeMirrorDragToAlterNumberController
      can use information based on the hovered token.
      
      * UserInterface/CodeMirrorDragToAlterNumberController.css: Added.
      (.CodeMirror.drag-to-adjust .CodeMirror-lines):
      Set the cursor to "col-resize" when a number token is hovered and the option key
      modifier is pressed.
      
      * UserInterface/CodeMirrorDragToAlterNumberController.js: Added.
      (WebInspector.CodeMirrorDragToAlterNumberController):
      We define the new "dragToAdjustNumbers" CodeMirror option.
      
      (WebInspector.CodeMirrorDragToAlterNumberController.prototype.set enabled):
      The "enabled" property controls whether the associated CodeMirror instance
      may act upon hovering numeric values to adjust them via a drag interaction.
      
      (WebInspector.CodeMirrorDragToAlterNumberController.prototype.handleEvent):
      Proxy for various event-specific methods to deal with mouse events. We also bind
      the value of the "active" property to the "mouseenter" and "mouseleave" events
      if we're not currently dragging-to-adjust.
      
      (WebInspector.CodeMirrorDragToAlterNumberController.prototype._setActive):
      The "active" property is set when the mouse is over the associated CodeMirror
      editor and when it's on we track all "mousemove" events such that we may
      identify tokens containing numeric values. We also start tracking changes to the
      option modifier key press state such that we may change the cursor accordingly.
      We ensure that the CodeMirror instance is not read-only such that we don't
      allow adjustment of numeric values in places where they couldn't be committed.
      
      (WebInspector.CodeMirrorDragToAlterNumberController.prototype._setDragging):
      The "dragging" property reflects whether a dragging-to-adjust interaction
      is underway. We call into WebInspector.elementDragStart() and WebInspector.elementDragEnd()
      to set the cursor to "col-resize" for the whole document while tracking mousemove
      and mouseup events at the window level such that we can drag-to-adjust even outside
      of the inspector window.
      
      (WebInspector.CodeMirrorDragToAlterNumberController.prototype._setTracksMouseClickAndDrag):
      The "tracksMouseClickAndDrag" property is set to true whenever the controller
      has detected that a token containing a numeric value is being hovered and the
      option modifier key is pressed. This property controls the cursor value for the
      hovered token to reflect that a drag-to-adjust interaction is allowed and tracks
      "mousedown" events for when a dragging interaction may be initiated.
      
      (WebInspector.CodeMirrorDragToAlterNumberController.prototype._modifiersDidChange):
      Sets the "tracksMouseClickAndDrag" property depending on the availability of a hovered
      token containing a numeric value and the pressed state of the option modified key.
      
      (WebInspector.CodeMirrorDragToAlterNumberController.prototype._mouseMoved):
      Handles "mousemove" events when we're not in the "dragging" state such that we
      check the currently hovered token, if any, to see if it contains a number that
      we may drag-to-adjust. Subsequently, we may enter the "tracksMouseClickAndDrag"
      state.
      
      (WebInspector.CodeMirrorDragToAlterNumberController.prototype._mouseWasPressed):
      Handles "mousedown" events during a drag-to-adjust interaction. We simply track
      the current mouse position in the x-axis and enter the "dragging" state.
      
      (WebInspector.CodeMirrorDragToAlterNumberController.prototype._mouseWasDragged):
      Handles "mousemove" events when we are in the "dragging" state. We compare the
      current mouse position in the x-axis with the last recoreded value and determine
      the amount by which we should adjust the value, taking into account the shift and
      control modifier keys. We then call into WebInspector.alterNumberInRange() to
      apply the change amount to the associated CodeMirror editor.
      
      (WebInspector.CodeMirrorDragToAlterNumberController.prototype._mouseWasReleased):
      Handles "mouseup" events, simply exiting the "dragging" state and resetting other
      parameters we would have customized as a result of the drag-to-adjust interaction.
      
      (WebInspector.CodeMirrorDragToAlterNumberController.prototype._reset):
      Resetting some parameters we would have customized as a result of the drag-to-adjust
      interaction.
      
      * UserInterface/Main.html:
      Include the new CodeMirrorDragToAlterNumberController.{js|css} files.
      
      * UserInterface/Main.js:
      (WebInspector.elementDragStart):
      (WebInspector.elementDragEnd):
      Add an extra parameter to elementDragStart() such that the caller may specify the event
      target for the "mousemove" and "mouseup" events.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153087 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      930aea84
    • commit-queue@webkit.org's avatar
      WebVTTParser's identifier buffering can ignore subsequent lines · e860fc6c
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=118483
      
      Patch by Brendan Long <b.long@cablelabs.com> on 2013-07-24
      Reviewed by Eric Carlson.
      
      No new tests since this bug can't be reproduced in layout tests.
      
      * html/track/WebVTTParser.cpp:
      (WebCore::WebVTTParser::parseBytes): Only buffer the identifier if we haven't read an entire line.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153086 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e860fc6c
    • commit-queue@webkit.org's avatar
      [GTK] TestInspectorServer unit test is timing out · 3aa5a532
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=105866
      
      Patch by Anton Obzhirov <a.obzhirov@samsung.com> on 2013-07-24
      Reviewed by Gustavo Noronha Silva.
      
      Source/WebKit2:
      
      The test failed because it couldn't find inspector resources in default folder
      (make install step was missing). It uses now resources available in
      WebKitBuild folder. WebInspectorServerGtk was refactored as well to make
      easier to use WEBKIT_INSPECTOR_SERVER_PATH variable.
      
      * UIProcess/API/gtk/tests/GNUmakefile.am:
      * UIProcess/API/gtk/tests/InspectorTestServer.cpp:
      (main):
      * UIProcess/API/gtk/tests/TestInspectorServer.cpp:
      (testInspectorServerPageList):
      * UIProcess/InspectorServer/gtk/WebInspectorServerGtk.cpp:
      (WebKit::WebInspectorServer::platformResourceForPath):
      (WebKit::WebInspectorServer::buildPageList):
      (WebKit::WebInspectorServer::inspectorServerFilesPath):
      
      Tools:
      
      * Scripts/run-gtk-tests:
      (TestRunner):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153085 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      3aa5a532
    • commit-queue@webkit.org's avatar
      [GTK] [WK2] Handle wheel event with delta zero · 84d6b230
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=118973
      
      Patch by Anton Obzhirov <a.obzhirov@samsung.com> on 2013-07-24
      Reviewed by Gustavo Noronha Silva.
      
      Added handling of zero mouse scroll deltas in EventSenderProxy similar
      to WK1 and Qt/EFL ports.
      
      fast/events/platform-wheelevent-with-delta-zero-crash.html is no longer
      failing on WK2.
      
      * WebKitTestRunner/gtk/EventSenderProxyGtk.cpp:
      (WTR::EventSenderProxy::mouseScrollBy):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153084 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      84d6b230
    • simon.pena@samsung.com's avatar
      [GTK] Unreviewed gardening. Add expectations for flaky test. · 2e291073
      simon.pena@samsung.com authored
      * platform/gtk/TestExpectations: Mark svg/stroke/non-scaling-stroke-pattern.svg
      as flaky.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153083 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2e291073
    • zandobersek@gmail.com's avatar
      Unreviewed. Setting the svn:eol-style=native property on the ANGLE.sln file. · 40b68922
      zandobersek@gmail.com authored
      * src/ANGLE.sln: Added property svn:eol-style.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153082 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      40b68922
    • ossy@webkit.org's avatar
      [Qt] Buildfix after r153064. Add Uniform files to the Target.pri. · c8bae8a9
      ossy@webkit.org authored
      Patch by Gabor Abraham <abrhm@inf.u-szeged.hu> on 2013-07-24
      Reviewed by Csaba Osztrogonác.
      
      * Target.pri:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153081 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c8bae8a9
    • ryuan.choi@samsung.com's avatar
      [EFL][CMAKE] Fix wrong syntax about option commands · 9422575f
      ryuan.choi@samsung.com authored
      https://bugs.webkit.org/show_bug.cgi?id=119035
      
      Reviewed by Christophe Dumez.
      
      second argument of cmake option command should be description.
      
      * Source/cmake/OptionsEfl.cmake: Added description instead of wrong initial value.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153080 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9422575f
    • commit-queue@webkit.org's avatar
      [EFL] Unreviewed gardening · e9b7a0f6
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=118826
      
      Unreviewed EFL gardening.
      
      Patch by Seokju Kwon <seokju.kwon@gmail.com> on 2013-07-24
      
      * platform/efl-wk2/TestExpectations: Update test expectations after r134890 and r139491.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153079 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e9b7a0f6
    • simon.pena@samsung.com's avatar
      [GTK] Unreviewed gardening. Added expectations for flaky tests. · 6c2d38f8
      simon.pena@samsung.com authored
      * platform/gtk/TestExpectations: Marked animations/resume-after-page-cache.html,
      css3/calc/img-size.html and perf/nested-combined-selectors.html as flaky.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153078 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      6c2d38f8