CSS canvas color parsing accepts invalid color identifiers
https://bugs.webkit.org/show_bug.cgi?id=134661

Reviewed by Benjamin Poulain.

Source/WebCore:
Current implementation of the CSSParser::parseSystemColor assumes
that if a valid cssValueKeywordID is got then it has to be a valid
color. Such assumption is wrong and lead to many bugs and layout
test failures.

The parseSystemFunction determines now whether the parsed color is
valid or not.

Addtionally, a new method has been added to share the logic of
determining whether a CSSValueID is a valid primitive values for
colors or not. Generally, we should avoid passing invalid color
identifiers to the theming API.

No new tests, but added additional cases to the
canvas-color-serialization.html, test-setting-canvas-color and
rgb-color-parse test.

* css/CSSParser.cpp:
(WebCore::validPrimitiveValueColor): Added.
(WebCore::parseColorValue):
(WebCore::CSSParser::parseSystemColor):

LayoutTests:
The parseSystemFunction determines now whether the parsed color is
valid or not.

The rgb-color-parser covers css style color parsing cases, which
already provide coverage for invalid color identifiers. I've added
a few more, though.

* fast/canvas/canvas-color-serialization-expected.txt:
* fast/canvas/script-tests/canvas-color-serialization.js:
* fast/css/test-setting-canvas-color-expected.txt:
* fast/css/test-setting-canvas-color.html:
* svg/dom/rgb-color-parser-expected.txt:
* svg/dom/rgb-color-parser.html:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170933 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS] WebKit can crash under QuickLookDocumentData::encode() when viewing a QuickLook preview
https://bugs.webkit.org/show_bug.cgi?id=134780

Reviewed by Tim Horton.

Don't use CFDataCreateWithBytesNoCopy() when we can't guarantee the lifetime of the copied-from DataReference
will match or exceed that of the CFDataRef. Copy the data instead.

* WebProcess/Network/WebResourceLoader.cpp:
(WebKit::WebResourceLoader::didReceiveData):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170934 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Support transparent WKWebViews
https://bugs.webkit.org/show_bug.cgi?id=134779
<rdar://problem/17351058>

Reviewed by Tim Horton.

Source/WebCore:
Schedule rebuilding the compositing layers if a FrameView's transparency changes.

* page/FrameView.cpp:
(WebCore::FrameView::setTransparent):

Source/WebKit2:
* UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView initWithFrame:configuration:]):
Call _updateScrollViewBackground instead of setting the background color.

(contentZoomScale):
Use dot notation.

(scrollViewBackgroundColor):
Helper function that returns the scroll view background color.
If the web view isn't opaque, we want the scroll view to be transparent.

(-[WKWebView _updateScrollViewBackground]):
Call scrollViewBackgroundColor.

(-[WKWebView setOpaque:]):
Call WebPageProxy::setDrawsBackground and update the scroll view background.

(-[WKWebView setBackgroundColor:]):
Call setBackgroundColor on the content view.

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