CodeBlock memory cost reporting should be rationalized
https://bugs.webkit.org/show_bug.cgi?id=120615

Source/JavaScriptCore: 

Reviewed by Darin Adler.
        
Report the size of the instruction stream, and then remind the GC that we're
using memory when we trace.
        
This is a slight slow-down on some JSBench tests because it makes us GC a
bit more frequently. But I think it's well worth it; if we really want those
tests to GC less frequently then we can achieve that through other kinds of
tuning. It's better that the GC knows that CodeBlocks do in fact use memory;
what it does with that information is a somewhat orthogonal question.

* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::visitAggregate):

Source/WTF: 

Reviewed by Darin Adler.

* wtf/RefCountedArray.h:
(WTF::RefCountedArray::refCount):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155021 268f45cc-cd09-0410-ab3c-d52691b4dbfc
AX: REGRESSION: @title is exposed as AXDescription when label label from contents already exists.
https://bugs.webkit.org/show_bug.cgi?id=120550

Reviewed by Mario Sanchez Prada.

Source/WebCore:

Resolve a FIXME from the accessible name computation refactoring so that alternative text for links do not
show up in the title field and do not duplicate naming when a title tag is used.

Effectively, this means that links no longer use AXTitle for alternative text. They use AXDescription
like all other elements.

Test: platform/mac/accessibility/link-with-title.html

* accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
(-[WebAccessibilityObjectWrapper accessibilityTitle]):
(-[WebAccessibilityObjectWrapper accessibilityDescription]):

LayoutTests:

* accessibility/image-map1.html:
* platform/mac/accessibility/document-links-expected.txt:
* platform/mac/accessibility/image-map1-expected.txt:
* platform/mac/accessibility/link-with-title-expected.txt: Added.
* platform/mac/accessibility/link-with-title.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155022 268f45cc-cd09-0410-ab3c-d52691b4dbfc
The DFG should be able to tier-up and OSR enter into the FTL
https://bugs.webkit.org/show_bug.cgi?id=112838

Source/JavaScriptCore: 

Reviewed by Mark Hahnenberg.
        
This adds the ability for the DFG to tier-up into the FTL. This works in both
of the expected tier-up modes:
        
Replacement: frequently called functions eventually have their entrypoint
replaced with one that goes into FTL-compiled code. Note, this will be a
slow-down for now since we don't yet have LLVM calling convention integration.
        
OSR entry: code stuck in hot loops gets OSR'd into the FTL from the DFG.
        
This means that if the DFG detects that a function is an FTL candidate, it
inserts execution counting code similar to the kind that the baseline JIT
would use. If you trip on a loop count in a loop header that is an OSR
candidate (it's not an inlined loop), we do OSR; otherwise we do replacement.
OSR almost always also implies future replacement.
        
OSR entry into the FTL is really cool. It uses a specialized FTL compile of
the code, where early in the DFG pipeline we replace the original root block
with an OSR entrypoint block that jumps to the pre-header of the hot loop.
The OSR entrypoint loads all live state at the loop pre-header using loads
from a scratch buffer, which gets populated by the runtime's OSR entry
preparation code (FTL::prepareOSREntry()). This approach appears to work well
with all of our subsequent optimizations, including prediction propagation,
CFA, and LICM. LLVM seems happy with it, too. Best of all, it works naturally
with concurrent compilation: when we hit the tier-up trigger we spawn a
compilation plan at the bytecode index from which we triggered; once the
compilation finishes the next trigger will try to enter, at that bytecode
index. If it can't - for example because the code has moved on to another
loop - then we just try again. Loops that get hot enough for OSR entry (about
25,000 iterations) will probably still be running when a concurrent compile
finishes, so this doesn't appear to be a big problem.
        
This immediately gives us a 70% speed-up on imaging-gaussian-blur. We could
get a bigger speed-up by adding some more intelligence and tweaking LLVM to
compile code faster. Those things will happen eventually but this is a good
start. Probably this code will see more tuning as we get more coverage in the
FTL JIT, but I'll worry about that in future patches.

* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::hasOptimizedReplacement):
(JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
* bytecode/CodeBlock.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::parse):
* dfg/DFGCFGSimplificationPhase.cpp:
(JSC::DFG::CFGSimplificationPhase::run):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
(JSC::DFG::compile):
* dfg/DFGDriver.h:
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::killBlockAndItsContents):
(JSC::DFG::Graph::killUnreachableBlocks):
* dfg/DFGGraph.h:
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::initialize):
* dfg/DFGJITCode.cpp:
(JSC::DFG::JITCode::reconstruct):
(JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
(JSC::DFG::JITCode::optimizeNextInvocation):
(JSC::DFG::JITCode::dontOptimizeAnytimeSoon):
(JSC::DFG::JITCode::optimizeAfterWarmUp):
(JSC::DFG::JITCode::optimizeSoon):
(JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently):
(JSC::DFG::JITCode::setOptimizationThresholdBasedOnCompilationResult):
* dfg/DFGJITCode.h:
* dfg/DFGJITFinalizer.cpp:
(JSC::DFG::JITFinalizer::finalize):
(JSC::DFG::JITFinalizer::finalizeFunction):
(JSC::DFG::JITFinalizer::finalizeCommon):
* dfg/DFGLoopPreHeaderCreationPhase.cpp:
(JSC::DFG::createPreHeader):
(JSC::DFG::LoopPreHeaderCreationPhase::run):
* dfg/DFGLoopPreHeaderCreationPhase.h:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasUnlinkedLocal):
(JSC::DFG::Node::unlinkedLocal):
* dfg/DFGNodeType.h:
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSREntrypointCreationPhase.cpp: Added.
(JSC::DFG::OSREntrypointCreationPhase::OSREntrypointCreationPhase):
(JSC::DFG::OSREntrypointCreationPhase::run):
(JSC::DFG::performOSREntrypointCreation):
* dfg/DFGOSREntrypointCreationPhase.h: Added.
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::compileInThread):
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPlan.h:
* dfg/DFGPredictionInjectionPhase.cpp:
(JSC::DFG::PredictionInjectionPhase::run):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTierUpCheckInjectionPhase.cpp: Added.
(JSC::DFG::TierUpCheckInjectionPhase::TierUpCheckInjectionPhase):
(JSC::DFG::TierUpCheckInjectionPhase::run):
(JSC::DFG::performTierUpCheckInjection):
* dfg/DFGTierUpCheckInjectionPhase.h: Added.
* dfg/DFGToFTLDeferredCompilationCallback.cpp: Added.
(JSC::DFG::ToFTLDeferredCompilationCallback::ToFTLDeferredCompilationCallback):
(JSC::DFG::ToFTLDeferredCompilationCallback::~ToFTLDeferredCompilationCallback):
(JSC::DFG::ToFTLDeferredCompilationCallback::create):
(JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
(JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
* dfg/DFGToFTLDeferredCompilationCallback.h: Added.
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp: Added.
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::~ToFTLForOSREntryDeferredCompilationCallback):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::create):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h: Added.
* dfg/DFGWorklist.cpp:
(JSC::DFG::globalWorklist):
* dfg/DFGWorklist.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLCapabilities.h:
* ftl/FTLForOSREntryJITCode.cpp: Added.
(JSC::FTL::ForOSREntryJITCode::ForOSREntryJITCode):
(JSC::FTL::ForOSREntryJITCode::~ForOSREntryJITCode):
(JSC::FTL::ForOSREntryJITCode::ftlForOSREntry):
(JSC::FTL::ForOSREntryJITCode::initializeEntryBuffer):
* ftl/FTLForOSREntryJITCode.h: Added.
(JSC::FTL::ForOSREntryJITCode::entryBuffer):
(JSC::FTL::ForOSREntryJITCode::setBytecodeIndex):
(JSC::FTL::ForOSREntryJITCode::bytecodeIndex):
(JSC::FTL::ForOSREntryJITCode::countEntryFailure):
(JSC::FTL::ForOSREntryJITCode::entryFailureCount):
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileBlock):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileExtractOSREntryLocal):
(JSC::FTL::LowerDFGToLLVM::compileGetLocal):
(JSC::FTL::LowerDFGToLLVM::addWeakReference):
* ftl/FTLOSREntry.cpp: Added.
(JSC::FTL::prepareOSREntry):
* ftl/FTLOSREntry.h: Added.
* ftl/FTLOutput.h:
(JSC::FTL::Output::crashNonTerminal):
(JSC::FTL::Output::crash):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
* interpreter/Register.h:
(JSC::Register::unboxedDouble):
* jit/JIT.cpp:
(JSC::JIT::emitEnterOptimizationCheck):
* jit/JITCode.cpp:
(JSC::JITCode::ftlForOSREntry):
* jit/JITCode.h:
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newReplacementCodeBlockFor):
* runtime/Options.h:
* runtime/VM.cpp:
(JSC::VM::ensureWorklist):
* runtime/VM.h:

LayoutTests: 

Reviewed by Mark Hahnenberg.
        
Fix marsaglia to check the result instead of printing, and add a second
version that relies on OSR entry.

* fast/js/regress/marsaglia-osr-entry-expected.txt: Added.
* fast/js/regress/marsaglia-osr-entry.html: Added.
* fast/js/regress/script-tests/marsaglia-osr-entry.js: Added.
(marsaglia):
* fast/js/regress/script-tests/marsaglia.js:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155023 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GStreamer] cannot play live streams
https://bugs.webkit.org/show_bug.cgi?id=116831

Patch by Andre Moreira Magalhaes <andre.magalhaes@collabora.co.uk> on 2013-09-04
Reviewed by Philippe Normand.

Source/WebCore:

Fix issues with rtsp streams embedded on <video> not loading.

* platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
Do not reset pipeline to READY state on STATE_CHANGE_ASYNC when entering PAUSED state for
live streams, otherwise we enter an endless loop of READY->PAUSED->READY->PAUSED when
starting playback.

Tools:

Fix timeout issues with rtspsrc/udpsrc gstreamer elements.

* gtk/jhbuild.modules:
* gtk/patches/rtspsrc-timeout-on-udpsrc-is-in-nanoseconds.patch: Added.
* gtk/patches/udpsrc-improve-timeouts.patch: Added.
Changed gstreamer jhbuild modules to use tarball repos (required to add patches)
and added 2 patches to gst-plugins-good to fix timeout issues with rtsp streams.
Both patches are applied upstream and can be removed once a new gstreamer release
is out (up to 1.0.10 the patches are not included) and we bump the requirements.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155024 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed GTK gardening.

* platform/gtk/TestExpectations: Skipping the media/track/in-band test set that's failing on the GTK port.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155025 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Regions] Extend the RenderRegionRange class to include overflow information + apply the layout overflow
https://bugs.webkit.org/show_bug.cgi?id=116299

Reviewed by David Hyatt.

Source/WebCore:

Patch for computing overflow for boxes per region and applying it for layout overflow.
The approach is based on adding a RenderOverflow object inside the RenderBoxRegionInfo
structure. The RenderOverflow object is manipulated by the RenderRegion using some utility
functions that receive the target box as a parameter.
When computing the portion of a box inside a region it is necessary to split the border
rect of the box between regions. This means mapping the rectangle in the flow thread
coordinates, making the split and then remapping the fragment in the box coordinates.
For now, this is not optimized and walks the render tree to compute the block offsets.
The function getRegionRangeForBox is used to determine in what regions a box should
be rendered into. The range is computed at layout time and it depends on the height of
the box, if its unsplittable for fragmentation etc.
The patch also propagates the layout overflow to the regions. This enables to correctly
display scrollbars when chaining varying size regions (currently the horizontal overflow
is as wide as the widest region for all the regions). Unsplittable boxes will also generate
layout overflow in the start region so they can be scrolled and fully reachable. This
functionality depends on fixing the visual overflow and adapting the layout to take into
account the unsplittable box. Besides this, the relative positioning and transforms are applied
at a fragment level. This is in line with the CSS3 Break specification:
http://dev.w3.org/csswg/css-break/#transforms

Tests: fast/regions/overflow-scrollable-rel-pos-fragment.html
       fast/regions/overflow-scrollable-rotated-fragment.html
       fast/regions/overflow-scrollable-unsplittable-fragment.html
       fast/regions/overflow-scrollable-varying-width-1.html
       fast/regions/overflow-scrollable-varying-width-2.html

* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::computeOverflow):
(WebCore::RenderBlock::clearLayoutOverflow):
(WebCore::RenderBlock::addVisualOverflowFromTheme):
(WebCore::RenderBlock::relayoutForPagination):
* rendering/RenderBlockLineLayout.cpp:
(WebCore::RenderBlock::addOverflowFromInlineChildren):
* rendering/RenderBox.cpp:
(WebCore::RenderBox::clientBoxRectInRegion):
(WebCore::RenderBox::addVisualEffectOverflow):
(WebCore::RenderBox::applyVisualEffectOverflow):
(WebCore::RenderBox::addOverflowFromChild):
(WebCore::RenderBox::clearOverflow):
* rendering/RenderBox.h:
* rendering/RenderBoxRegionInfo.h:
(WebCore::RenderBoxRegionInfo::createOverflow):
(WebCore::RenderBoxRegionInfo::overflow):
(WebCore::RenderBoxRegionInfo::clearOverflow):
* rendering/RenderEmbeddedObject.cpp:
(WebCore::RenderEmbeddedObject::layout):
* rendering/RenderFlowThread.cpp:
(WebCore::RenderFlowThread::updateLogicalWidth):
(WebCore::RenderFlowThread::markRegionsForOverflowLayoutIfNeeded):
(WebCore::RenderFlowThread::mapFromLocalToFlowThread):
(WebCore::RenderFlowThread::mapFromFlowThreadToLocal):
(WebCore::RenderFlowThread::addRegionsVisualEffectOverflow):
(WebCore::RenderFlowThread::addRegionsVisualOverflowFromTheme):
(WebCore::RenderFlowThread::addRegionsOverflowFromChild):
(WebCore::RenderFlowThread::addRegionsLayoutOverflow):
(WebCore::RenderFlowThread::clearRegionsOverflow):
* rendering/RenderFlowThread.h:
* rendering/RenderIFrame.cpp:
(WebCore::RenderIFrame::layout):
* rendering/RenderRegion.cpp:
(WebCore::RenderRegion::computeOverflowFromFlowThread):
(WebCore::RenderRegion::setRenderBoxRegionInfo):
(WebCore::RenderRegion::ensureOverflowForBox):
(WebCore::RenderRegion::rectFlowPortionForBox):
(WebCore::RenderRegion::addLayoutOverflowForBox):
(WebCore::RenderRegion::addVisualOverflowForBox):
(WebCore::RenderRegion::layoutOverflowRectForBox):
(WebCore::RenderRegion::visualOverflowRectForBox):
(WebCore::RenderRegion::layoutOverflowRectForBoxForPropagation):
(WebCore::RenderRegion::visualOverflowRectForBoxForPropagation):
* rendering/RenderRegion.h:
* rendering/RenderReplaced.cpp:
(WebCore::RenderReplaced::layout):
* rendering/RenderTableSection.cpp:
(WebCore::RenderTableSection::computeOverflowFromCells):

LayoutTests:

Add tests for layout overflow propagation. Some tests disable the visual representation of the overflow.
This is because the visual overflow in regions is not yet fixed. The tests will be revisited when the
visual overflow is implemented.
Some repaint tests are rebased because a new repaint is issued on the regions when they compute the layout
overflow.

* fast/regions/element-in-named-flow-absolute-from-fixed-expected.txt: Rebased.
* fast/regions/element-in-named-flow-fixed-from-absolute-expected.txt: Rebased.
* fast/regions/element-inflow-fixed-from-outflow-static-expected.txt: Rebased.
* fast/regions/element-outflow-static-from-inflow-fixed-expected.txt: Rebased.
* fast/regions/overflow-scrollable-rel-pos-fragment-expected.html: Added.
* fast/regions/overflow-scrollable-rel-pos-fragment.html: Added.
* fast/regions/overflow-scrollable-rotated-fragment-expected.html: Added.
* fast/regions/overflow-scrollable-rotated-fragment.html: Added.
* fast/regions/overflow-scrollable-unsplittable-fragment-expected.html: Added.
* fast/regions/overflow-scrollable-unsplittable-fragment.html: Added.
* fast/regions/overflow-scrollable-varying-width-1-expected.html: Added.
* fast/regions/overflow-scrollable-varying-width-1.html: Added.
* fast/regions/overflow-scrollable-varying-width-2-expected.html: Added.
* fast/regions/overflow-scrollable-varying-width-2.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155026 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed GTK gardening.

* platform/gtk/TestExpectations: Manage the current accessibility layout test failures
after r154697, r154781 and r154976.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155027 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Unreviewed bot greening.

* platform/qt-wk2/fast/regions/element-in-named-flow-absolute-from-fixed-expected.txt: Added.
* platform/qt-wk2/fast/regions/element-in-named-flow-fixed-from-absolute-expected.txt: Added.
* platform/qt-wk2/fast/regions/element-inflow-fixed-from-outflow-static-expected.txt: Added.
* platform/qt-wk2/fast/regions/element-outflow-static-from-inflow-fixed-expected.txt: Added.
* platform/qt/TestExpectations: Skip after r155014.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155028 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed GTK gardening.

* platform/gtk/TestExpectations: Adding failure expectations for tests introduced in r154875, r154906 and r154954.
* platform/gtk/animations/cross-fade-background-image-expected.png: Rebaselining after r154906.
* platform/gtk/animations/cross-fade-background-image-expected.txt: Ditto.
* platform/gtk/animations/cross-fade-border-image-source-expected.png: Ditto.
* platform/gtk/animations/cross-fade-border-image-source-expected.txt: Ditto.
* platform/gtk/animations/cross-fade-list-style-image-expected.png: Ditto.
* platform/gtk/animations/cross-fade-list-style-image-expected.txt: Ditto.
* platform/gtk/animations/cross-fade-webkit-mask-box-image-expected.png: Ditto.
* platform/gtk/animations/cross-fade-webkit-mask-box-image-expected.txt: Ditto.
* platform/gtk/animations/cross-fade-webkit-mask-image-expected.png: Ditto.
* platform/gtk/animations/cross-fade-webkit-mask-image-expected.txt: Ditto.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155029 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Regions] Fix failing tests on ML WK2 after r154973
https://bugs.webkit.org/show_bug.cgi?id=120672

Reviewed by Antti Koivisto.

The two tests are failing because the reference tests create backings for the fixed elements layers.
Regions are not yet accelerated, don't create backings and this difference of behaviour causes a
slight shift in the background color of the fixed elements.

* fast/regions/fixed-inside-named-flow-zIndex-expected.html:
* fast/regions/fixed-inside-named-flow-zIndex.html:
* fast/regions/fixed-pos-region-in-nested-flow-expected.html:
* fast/regions/fixed-pos-region-in-nested-flow.html:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155030 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Reimplement atk_text_get_text_*_offset for SENTENCE boundaries
https://bugs.webkit.org/show_bug.cgi?id=114873

Reviewed by Chris Fleizach.

Re-implement these functions without using GailTextUtil nor Pango.

* accessibility/atk/WebKitAccessibleInterfaceText.cpp:
(webkitAccessibleTextWordForBoundary): Renamed from webkitAccessibleTextGetWordForBoundary,
to keep it consistent with names for new functions.
(isSentenceBoundary): Helper function to know when we are either
at the beginning or the end of a sentence.
(isWhiteSpaceBetweenSentences): It returns true if we are in the
middle of a white space between sentences. Useful for implementing
the SENTENCE_END boundary type.
(sentenceAtPositionForAtkBoundary): New helper function to find the
sentence at a given position considering values of AtkTextBoundary.
(webkitAccessibleTextSentenceForBoundary): New function,
implementing atk_text_get_text_*_offset for SENTENCE.
(webkitAccessibleTextGetTextForOffset): Replace usage of Gail for
SENTENCE boundaries with webkitAccessibleTextSentenceForBoundary().

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155031 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Add support for the Wayland build target
https://bugs.webkit.org/show_bug.cgi?id=120627

Reviewed by Gustavo Noronha Silva.

.: 

Add support for building the GTK port with Wayland as the target. The Wayland target can be the sole target
that's enabled, or it can be enabled in parallel with the X11 target.

Each of those two targets, when enabled, checks for the corresponding GTK+ windowing dependency being present.
In the case of only the Wayland target being enabled, the accelerated compositing feature is disabled at
build-time as the feature is not yet supported under the Wayland display protocol. X11-based plugin support is
also disabled under that configuration, even if the WebKitPluginProcess is still built but is left non-operational.
GLX support is also disabled if not building the X11 target.

The Wayland target can be enabled through using the --with-target configuration option that now accepts two
additional values:
- 'wayland' - only enables the Wayland target,
- 'x11,wayland' - enables the X11 and Wayland targets that are to be built in parallel.

This makes it possible to build the GTK port of WebKit with the Wayland target, relying solely on the GTK+
dependency that only has the Wayland backend enabled, and removes linking against any X11-related library.
Note that at the moment there seem to be other dependencies that still link to X11-related libraries.
Complete functionality is not yet guaranteed, but is of course the goal.

* Source/autotools/FindDependencies.m4: Store the version of the basic GTK+ dependency that was found.
This is later used to check that the GTK+ X11 and GTK+ Wayland dependencies are of the same version. The
X11-specific dependencies are grouped into one section (apart from the XComposite and XDamage dependencies),
also checking for the GTK+ X11 dependency. If the X11 target is not enabled, the GLX dependency is disabled.
Additionally check for the GTK+ Wayland dependency if the Wayland target is enabled.
We only check for the presence and correct version of the GTK+ X11 and Wayland dependencies, if necessary.
Check for the XComposite and XDamage dependencies if the X11 target is enabled (in addition to the OpenGL
headers being present).
In case of the Wayland target being enabled while the X11 target is not, disable the accelerated compositing
feature as there's no support yet for it under the Wayland display protocol.
* Source/autotools/PrintBuildConfiguration.m4: The build configuration should now print out 'GDK targets'.
* Source/autotools/ReadCommandLineArguments.m4: The --with-target option can now take two additional values,
'wayland' and 'x11,wayland'. The first one enables only the Wayland target, while the second one enables both
X11 and Wayland targets. This makes it possible to build the GTK port with both X11 and Wayland display protocols
supported in the same build.
We must now check the outcoming with_target variable to see if the special case of building one or both of the
possible parallel targets was chosen. We define with_x11_target and with_wayland_target variables if the
with_target value applies to that case.
* Source/autotools/SetupAutoconfHeader.m4: Do not define the XP_UNIX macro on builds that enable the Wayland-only
target. It should still be defined if we're building both X11 and Wayland targets in parallel.
* Source/autotools/SetupAutomake.m4: Define TARGET_X11 and TARGET_WAYLAND Automake conditionals if the new
with_x11_target or with_wayland_target variables were set, respectively. Additionall, define the TARGET_X11_OR_WAYLAND
Automake conditional if we're building either of the two targets.

Source/WebCore: 

* GNUmakefile.list.am: Reorder the Source/WebCore/plugins/np* source files.
The X11-specific source files should only be included if the X11 target is being built. PluginPackageNone and
PluginViewNone source files must be included in non-X11-target builds. Other source files that were previously
guarded with the TARGET_X11 conditional should also be built for the Wayland target, so the new TARGET_X11_OR_WAYLAND
conditional is used. If neither of those two targets is being built we fall back to adding source files to the build
as necessary by the actual build target.
* platform/gtk/GtkVersioning.c:
(gdk_screen_get_monitor_workarea): Additionally guard bits of code that depend on the GDK_WINDOWING_X11 macro being
defined - these should only be built when building the X11 target, checked for with PLATFORM(X11).

Source/WebKit/gtk: 

* WebCoreSupport/ChromeClientGtk.cpp:
(WebKit::createBackingStore): Additionally guard the <gdk/gdkx.h> inclusion and the inclusion and use of
WidgetBackingStoreGtkX11 with PLATFORM(X11), ensuring this code is built when also building with X11 target
enabled. GDK_WINDOWING_X11 macro can be defined even if the X11 target is disabled.

Source/WebKit2: 

* GNUmakefile.list.am: Build X11-specific NetscapePluginModule and NetscapePlugin classes if building the X11 target,
fall back to the generic, empty classes otherwise.
* PluginProcess/unix/PluginProcessMainUnix.cpp:
(WebKit::PluginProcessMainUnix): Guard the NetscapePluginModule::scanPlugin() invocation with PLUGIN_ARCHITECTURE(X11),
it's at the moment specific to the X11 implementation of the Netscape plugins.
* UIProcess/Plugins/unix/PluginProcessProxyUnix.cpp: Guard PluginProcessProxy::scanPlugin() with PLUGIN_ARCHITECTURE(X11),
just like it's guarded in the PluginProcessProxy class declaration.
* UIProcess/cairo/BackingStoreCairo.cpp: Additionally guard <gdk/gdkx.h> and WidgetBackingStoreGtkX11 inclusion and use
with PLATFORM(X11), this code should only be built when building the X11 target.
(WebKit::createBackingStoreForGTK):
* UIProcess/gtk/WebPageProxyGtk.cpp: Guard the createPluginContainer() and windowedPluginGeometryDidChange() methods and their
helper functions and objects with PLUGIN_ARCHITECTURE(X11), just like they're guarded in the WebPageProxy class declaration.
* config.h: Only define PLUGIN_ARCHITECTURE_X11 to 1 if we're actually building the X11 target.

Tools: 

* GNUmakefile.am: Define the additional macros also if building the Wayland target.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155032 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed GTK gardening. Rebaselining 7 accessibility tests after r154976.

* platform/gtk/accessibility/lists-expected.txt:
* platform/gtk/accessibility/plugin-expected.txt:
* platform/gtk/accessibility/table-detection-expected.txt:
* platform/gtk/accessibility/table-one-cell-expected.txt:
* platform/gtk/accessibility/table-with-aria-role-expected.txt:
* platform/gtk/accessibility/table-with-rules-expected.txt:
* platform/gtk/accessibility/transformed-element-expected.txt:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155033 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Use correct library paths for prefix builds on Mac.
https://bugs.webkit.org/show_bug.cgi?id=120635

Reviewed by Tor Arne Vestbø.

Due to a change of scope of the qmake force_independent configuration
flag, the library paths in QtWebKit builds on the Mac are set to the
QtWebKit build directory even for production builds.

This patch sets the correct library paths for prefixed production builds
while keeping the scope of the force_independent flag for non-production
builds.

* Source/api.pri:
* Source/widgetsapi.pri:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155034 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Unreviewed gardening. Skip failing tests and added platform specifix expected result.

* platform/qt-wk1/inspector/console/command-line-api-expected.txt: Added after r154998.
* platform/qt/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155035 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Unreviewed bot greening.

* platform/qt-wk2/compositing/images/direct-image-object-fit-expected.txt: Rebaselining after r154921.
* platform/qt-wk2/compositing/reflections/direct-image-object-fit-reflected-expected.txt: Ditto.
* platform/qt/TestExpectations: Skip after r155008.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155036 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed GTK gardening.

* platform/gtk/TestExpectations: Adding failure expectation for accessibility/image-map1.html after r155022.
* platform/gtk/fast/dom/Window/window-postmessage-clone-expected.txt: Rebaselining after 155008.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155037 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION (r132328): /WebKit2APITests/TestWebKitAccessibility unit test is failing
https://bugs.webkit.org/show_bug.cgi?id=100408

Unreviewed gardening. Unskip TestWebKitAccessibility after
manually checking that it's running properly in the bot.

* Scripts/run-gtk-tests:
(TestRunner): Unskipped TestWebKitAccessibility.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155038 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Color of input button's text broken with recent gnome-themes-standard
https://bugs.webkit.org/show_bug.cgi?id=120581

Reviewed by Carlos Garcia Campos.

* platform/gtk/RenderThemeGtk3.cpp:
(WebCore::getStyleContext): add the "text-button" class.
(WebCore::RenderThemeGtk::systemColor): Use the ACTIVE state flag,
as this is the one actually used for button labels.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155039 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Use Vector<Ref<T>> in three random WebCore loops.
<https://webkit.org/b/120661>

Reviewed by Darin Adler.

Clean up three little loops to use Refs to avoid null checking known-valid objects.
Also apply auto, reserveInitialCapacity and uncheckedAppend as appropriate.

* page/DOMWindow.cpp:
(WebCore::DOMWindow::dispatchAllPendingBeforeUnloadEvents):
(WebCore::DOMWindow::dispatchAllPendingUnloadEvents):
* platform/graphics/FontCache.cpp:
(WebCore::FontCache::invalidate):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155040 268f45cc-cd09-0410-ab3c-d52691b4dbfc