Build fix.

* platform/network/soup/CookieJarSoup.cpp:
(WebCore::deleteAllCookiesModifiedSince):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
WebStorageNamespaceProvider should know about its local storage database path
https://bugs.webkit.org/show_bug.cgi?id=139413

Reviewed by Andreas Kling.

Source/WebKit:

* Storage/WebStorageNamespaceProvider.cpp:
(WebStorageNamespaceProvider::create):
(WebStorageNamespaceProvider::WebStorageNamespaceProvider):
* Storage/WebStorageNamespaceProvider.h:

Source/WebKit/mac:

* WebCoreSupport/WebViewGroup.h:
* WebCoreSupport/WebViewGroup.mm:
(WebViewGroup::getOrCreate):
(WebViewGroup::WebViewGroup):
* WebView/WebView.mm:
(-[WebView _commonInitializationWithFrameName:groupName:]):
(-[WebView initSimpleHTMLDocumentWithStyle:frame:preferences:groupName:]):
(-[WebView setGroupName:]):
(-[WebView groupName]): Deleted.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176976 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS] YouTube plug-in replacement should support partial urls
https://bugs.webkit.org/show_bug.cgi?id=139400

Reviewed by Alexey Proskuryakov.

* Modules/plugins/YouTubePluginReplacement.cpp:
(WebCore::YouTubePluginReplacement::youTubeURL): Call Document::completeURL.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176977 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Inline elements whose parents have small line-height are laid out too low
https://bugs.webkit.org/show_bug.cgi?id=139375

Reviewed by Dave Hyatt.

Source/WebCore:

This is a port of the Blink patch at
https://src.chromium.org/viewvc/blink?revision=155253&view=revision.

When laying out inline elements, we try to align leaf children's parents'
baselines across the entire line. However, if you set line-height: 0px on a
span, the entire InlineBox which represents that span will have a height of
0, and therefore be laid out entirely on the baseline. In addition, we will
try to vertically center the leaf text in the span's InlineBox, which means
the leaf text will be vertically centered on the baseline. All the other
major browsers do not have this behavior; instead, they line up the boxes
as you would expect.

This bug led to a rendering problem on the front page of the New York Times.

Here is the ChangeLog from the Blink patch:

Fix baseline position when it is outside the element's box

Specifically, we shouldn't force the baseline to be inside the element. IE
and FF don't do this, and it's incompatible with the CSS spec:

"The baseline of an 'inline-block' is the baseline of its last line box in
the normal flow, unless it has either no in-flow line boxes or if its
'overflow' property has a computed value other than 'visible', in which case
the baseline is the bottom margin edge."
-- http://www.w3.org/TR/CSS21/visudet.html#leading

It doesn't have a special case for "baseline is outside of the element's
margin box".

Test: fast/text/small-line-height.html

* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::baselinePosition):

LayoutTests:

Add fast/text/small-line-height.html for a simple example. In addition, update
existing tests.

* fast/forms/textfield-overflow-by-value-update-expected.txt:
* fast/regions/cssom/client-rects-inline-complex.html:
* fast/regions/overflow/overflow-region-inline-expected.html:
* fast/text/small-line-height-expected.html: Added.
* fast/text/small-line-height.html: Added.
* platform/mac/fast/box-sizing/box-sizing-expected.png:
* platform/mac/fast/box-sizing/box-sizing-expected.txt:
* platform/mac/fast/forms/search-vertical-alignment-expected.png:
* platform/mac/fast/forms/search-vertical-alignment-expected.txt:
* platform/mac/fast/forms/textfield-overflow-by-value-update-expected.png: Removed.
* platform/mac/fast/multicol/client-rects-expected.png:
* platform/mac/fast/multicol/client-rects-expected.txt:
* platform/mac/fast/multicol/client-rects-spanners-complex-expected.png:
* platform/mac/fast/multicol/client-rects-spanners-complex-expected.txt:
* platform/mac/fast/multicol/client-rects-spanners-expected.png:
* platform/mac/fast/multicol/client-rects-spanners-expected.txt:
* platform/mac/fast/multicol/layers-split-across-columns-expected.png:
* platform/mac/fast/multicol/layers-split-across-columns-expected.txt:
* platform/mac/fast/multicol/newmulticol/client-rects-expected.png:
* platform/mac/fast/multicol/newmulticol/client-rects-expected.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176978 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fixes operationPutByIds such that they check that the put didn't
change the structure of the object who's property access is being
cached.
https://bugs.webkit.org/show_bug.cgi?id=139196

Reviewed by Filip Pizlo.

* jit/JITOperations.cpp:
(JSC::operationGetByIdOptimize): changed get to getPropertySlot
(JSC::operationPutByIdStrictBuildList): saved the structure before the put.
(JSC::operationPutByIdNonStrictBuildList): ditto.
(JSC::operationPutByIdDirectStrictBuildList): ditto.
(JSC::operationPutByIdDirectNonStrictBuildList): ditto.
* jit/Repatch.cpp:
(JSC::tryCachePutByID): fixed structure() to use the existant vm.
(JSC::tryBuildPutByIdList): Added a check that the old structure's id
is the same as the new.
(JSC::buildPutByIdList): Added an argument
* jit/Repatch.h:
(JSC::buildPutByIdList): Added an argument
* tests/stress/put-by-id-build-list-order-recurse.js: Test that failed before the change
* tests/stress/put-by-id-strict-build-list-order.js: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176979 268f45cc-cd09-0410-ab3c-d52691b4dbfc
The website data store should know all its associated pages
https://bugs.webkit.org/show_bug.cgi?id=139411

Reviewed by Tim Horton.

* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::WebPageProxy):
(WebKit::WebPageProxy::close):
* UIProcess/WebPageProxy.h:
* UIProcess/WebsiteData/WebsiteDataStore.cpp:
(WebKit::WebsiteDataStore::~WebsiteDataStore):
(WebKit::WebsiteDataStore::addWebPage):
(WebKit::WebsiteDataStore::removeWebPage):
* UIProcess/WebsiteData/WebsiteDataStore.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176980 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Try to fix the 32-bit build.

* WebCore.exp.in:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176981 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix iOS build after r176971.

I had previously modified the WTF forwarding header instead of modifying the real source.

* wtf/unicode/CharacterNames.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176982 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix the parsing of advanced :lang() after r176902
https://bugs.webkit.org/show_bug.cgi?id=139379

Reviewed by Andreas Kling.

Source/WebCore:

There were two mistakes that were only caught in debug:

The lexer was not calling isIdentifierStart() before parseIdentifier().
Some identifier we were parsing should have been invalid.
This was caught with an assertion in parseIdentifier().

The other issue is that we were accumulating pointer to freed memory.
The tokenizer for LANGRANGE was creating a new string with a StringBuilder.
The problem is that CSSParserString does not keep the source string alive.
Consequently, the list of language range was accumulating pointers to dead
StringImpls.

The fix there is to simply extend the token to take the original asterisk character
from the input. That is not elegant but that's efficient and we know
the buffer lifetime.

* css/CSSParser.cpp:
(WebCore::CSSParser::realLex):
* css/CSSGrammar.y.in: Fix the indentation of a language range rule.

LayoutTests:

Unskip and update the tests.

All the interesting cases were covered, I just had to update
the expectations.

* TestExpectations:
* fast/css/css-selector-text-expected.txt:
* fast/css/css-selector-text.html:
* fast/css/parsing-css-lang-expected.txt:
* fast/css/parsing-css-lang.html:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176983 268f45cc-cd09-0410-ab3c-d52691b4dbfc
A selector should not match anything if there is a subselector after a non-scrollbar pseudo element
https://bugs.webkit.org/show_bug.cgi?id=139336
Source/WebCore:

rdar://problem/19051623

Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-12-08
Reviewed by Andreas Kling.

Tests: fast/css/duplicated-after-pseudo-element.html
       fast/css/duplicated-before-pseudo-element.html
       fast/css/simple-selector-after-pseudo-element.html

* cssjit/SelectorCompiler.cpp:
(WebCore::SelectorCompiler::constructFragments):
The code filtering out simple selectors was only considering
the relation CSSSelector::SubSelector. That comes from SelectorChecker where
the relation considered is the one from the previous selector.

In this case, the relation is the extracted from the current simple selector,
which is the relation with the following selector.

When a single simple selector was following a pseudo element, the relation evaluated
to descendant/adjacent/direct-adjacent and we were skipping the early return.
That simple selector was evaluated as a regular filter on the element.

In the CSS JIT, we can just remove that test altogether. Fragments are built one after
the other. By definition, the evaluated simple selector belong to the current fragment.

LayoutTests:


Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-12-08
Reviewed by Andreas Kling.

* fast/css/duplicated-after-pseudo-element-expected.html: Added.
* fast/css/duplicated-after-pseudo-element.html: Added.
* fast/css/duplicated-before-pseudo-element-expected.html: Added.
* fast/css/duplicated-before-pseudo-element.html: Added.
* fast/css/simple-selector-after-pseudo-element-expected.html: Added.
* fast/css/simple-selector-after-pseudo-element.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176984 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Move the new :nth-child() and :nth-last-child() out of experimental
https://bugs.webkit.org/show_bug.cgi?id=139329

Reviewed by Andreas Kling.

The code is stable.
Feedback has only been positive.
All the known issues have been reported to the CSS WG.

The #ifdef don't really work anymore anyway for :nth-child() and :nth-last-child().

* css/CSSSelector.cpp:
(WebCore::CSSSelector::selectorText):
* css/SelectorChecker.cpp:
(WebCore::SelectorChecker::checkOne):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176985 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION (173394): Support for webcam is broken
https://bugs.webkit.org/show_bug.cgi?id=139313

Test by Antti Koivisto, reviewed and tweaked by Alexey Proskuryakov.

* http/tests/multipart/multipart-image-expected.html: Added.
* http/tests/multipart/multipart-image.html: Added.

* http/tests/multipart/resources/multipart.php: Multiopart boundary must start on
a new line, so make it so. In newwer OS versions, CFNetwork has a workaround that
makes invalid multipart response work, which is why the test was passing locally.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176990 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Adding user content to a group should force that group to be created
https://bugs.webkit.org/show_bug.cgi?id=139421
rdar://problem/19180108

Reviewed by Sam Weinig.

* WebCoreSupport/WebViewGroup.h:
Store the local storage database path in the group.

* WebCoreSupport/WebViewGroup.mm:
(WebViewGroup::getOrCreate):
If we have an existing group that hasn't had its storage namespace provider created, and the path passed is not empty,
set it. This will ensure that getOrCreate will still work when creating a storage namspace provider.

(WebViewGroup::WebViewGroup):
Initialize the new member variable.

(WebViewGroup::storageNamespaceProvider):
Create the namespace provider lazily.

* WebView/WebView.mm:
(+[WebView _addUserScriptToGroup:world:source:url:whitelist:blacklist:injectionTime:injectedFrames:]):
(+[WebView _addUserStyleSheetToGroup:world:source:url:whitelist:blacklist:injectedFrames:]):
Use getOrCreate instead of get.

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