Add a flag for the CSS Selectors level 4 implementation
https://bugs.webkit.org/show_bug.cgi?id=135535

Reviewed by Andreas Kling.


.: 
* Source/cmake/OptionsEfl.cmake:
* Source/cmake/OptionsGTK.cmake:
* Source/cmake/WebKitFeatures.cmake:
* Source/cmakeconfig.h.cmake:

Source/JavaScriptCore: 
* Configurations/FeatureDefines.xcconfig:

Source/WebCore: 
* Configurations/FeatureDefines.xcconfig:

Source/WebKit/mac: 
* Configurations/FeatureDefines.xcconfig:

Source/WebKit2: 
* Configurations/FeatureDefines.xcconfig:

WebKitLibraries: 
* win/tools/vsprops/FeatureDefines.props:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@172023 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Simplify the StyleInvalidation mode of rule collection
https://bugs.webkit.org/show_bug.cgi?id=135521

Reviewed by Antti Koivisto.


Source/WebCore: 
There are two branches where StyleInvalidation code is removed:
-Pseudo elements for shadow dom elements.
-Pseudo elements without dom tree counterpart.

The first can never be hit because StyleInvalidationAnalysis does a complete invalidation
when there is any shadow dom styling involved in the stylesheets.

Even if that branch was hit, not failing on custom pseudo elements would be equivalent
to ignoring those pseudo elements from the Selector. By doing so, we would match elements
that do not have shadow dom and invalidate pretty much everything.

Unlike pseudo elements without real elements, shadow dom elements are not matched separately with a different
context, thus we could generalize StyleInvalidationAnalysis to handle this case.


The second case handle pseudo elements that do not have a real element. That case no longer need to be handled
separately at the filter time, it has become a special case of SelectorChecker::match() after everything else
has matched.

The only condition for this to work is that the Context's pseudoId must be NOPSEUDO. This is the case
in practice since matching specific pseudo types would be a waste of time. ElementRuleCollector::collectMatchingRules()
has a new assertion to enforce that.

Test: fast/css/stylesheet-change-updates-pseudo-elements.html

* css/ElementRuleCollector.cpp:
(WebCore::ElementRuleCollector::collectMatchingRules):
* css/SelectorChecker.cpp:
(WebCore::SelectorChecker::matchRecursively):
* cssjit/SelectorCompiler.cpp:
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateRequestedPseudoElementEqualsToSelectorPseudoElement):

LayoutTests: 
This test by:
1) Forcing the recalc of the user-agent stylesheet.
2) Wait for the page to finish loading.
3) Add a style changing only pseudo elements without corresponding shadow element.

* fast/css/stylesheet-change-updates-pseudo-elements-expected.html: Added.
* fast/css/stylesheet-change-updates-pseudo-elements.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@172024 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[MSE] Videos will report a stall when within 1 frame-duration before the end of a movie.
https://bugs.webkit.org/show_bug.cgi?id=135586

Reviewed by Eric Carlson.

Under certain circumstances, videos which are within 1/24 seconds before the end of a media stream when
monitorSourceBuffers() is called will fail the hasFutureTime() check. This is because hasFutureTime()
checks whether enough media is buffered to play back at least some time in the future, but when the
current time is close to the duration, not enough data is buffered to satisfy that check.

Add some logic which will break out early when the SourceBuffer has buffered up to and including the
media's duration, and return that the buffer indeed hasFutureTime() available.

* Modules/mediasource/SourceBuffer.cpp:
(WebCore::SourceBuffer::hasFutureTime):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@172025 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[MSE][Mac] Seeking past buffered range will not resume playback when seek completes.
https://bugs.webkit.org/show_bug.cgi?id=135591

Reviewed by Eric Carlson.

If a seek is delayed due to seeking into an unbuffered area, playback will not be restarted
at that point. Instead, playback must resume when enough media data has been added, and
the MediaSource indicates the seek should complete.

* platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::seekCompleted):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@172026 268f45cc-cd09-0410-ab3c-d52691b4dbfc
AX: Select activity behavior does not work when an existing range is already selected
https://bugs.webkit.org/show_bug.cgi?id=135579

Reviewed by Mario Sanchez Prada.

Source/WebCore:
If you have an existing range selected, and try to apply a select and replace operation, like capitalize,
searching for that range will fail because it skips the currently selected range.

For these cases, it seems the best way is to start the search from the start position, rather than relying on the
entire range.

Updated existing test: platform/mac/accessibility/select-text.html

* accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::selectText):

LayoutTests:
* platform/mac/accessibility/select-text-expected.txt:
* platform/mac/accessibility/select-text.html:


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