CSS3 calc: working with translate and scale transforms
https://bugs.webkit.org/show_bug.cgi?id=105985

Reviewed by Ojan Vafai.

Source/WebCore:

Allow convertTo[Float|Int]Length functions to process calculated values.

Tests: css3/calc/transforms-scale.html
       css3/calc/transforms-translate.html

* css/StyleResolver.cpp:
(WebCore::StyleResolver::convertToIntLength):
(WebCore::StyleResolver::convertToFloatLength):

LayoutTests:

* css3/calc/transforms-scale-expected.html: Added.
* css3/calc/transforms-scale.html: Added.
* css3/calc/transforms-translate-expected.html: Added.
* css3/calc/transforms-translate.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138833 268f45cc-cd09-0410-ab3c-d52691b4dbfc
CSP 1.1: Experiment with adding line numbers to violation reports.
https://bugs.webkit.org/show_bug.cgi?id=105374

Reviewed by Adam Barth.

Source/WebCore:

Line numbers and URLs were added to the CSP 1.1 spec in
https://dvcs.w3.org/hg/content-security-policy/rev/e0270baace3d, and
already exist (and have for quite some time) in Firefox's
implementation. Based on developer feedback, it seems reasonable to
experiment a bit with adding them to WebKit's violation reports.
This patch generates a stack trace when constructing the violation
report object (iff a violation report object ought to be generated)
and adds a line number and URL to the object if possible.

Tests: http/tests/security/contentSecurityPolicy/report-uri-from-inline-javascript.html
       http/tests/security/contentSecurityPolicy/report-uri-from-javascript.html

* page/ContentSecurityPolicy.cpp:
(WebCore::ContentSecurityPolicy::reportViolation):
    Generate a stack trace when building the violation report: if it
    has relevant detail, add the line number and URL to the report
    object.

LayoutTests:

* http/tests/security/contentSecurityPolicy/report-uri-from-inline-javascript-expected.txt: Added.
* http/tests/security/contentSecurityPolicy/report-uri-from-inline-javascript.html: Added.
* http/tests/security/contentSecurityPolicy/report-uri-from-javascript-expected.txt: Added.
* http/tests/security/contentSecurityPolicy/report-uri-from-javascript.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138834 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Invalidation of some SVG filter attributes on HTML content doesn't work
https://bugs.webkit.org/show_bug.cgi?id=105635

Reviewed by Dirk Schulze.

Source/WebCore:

Since HTML elements with filters are only added to m_clientLayers, not
m_clients, and do not use the FilterInfo used by SVG filters on SVG
elements, they must be invalidated separately.  Some filter attribute
invalidations call markAllClientsForInvalidation(), but some call
markClientForInvalidation() directly.  These invaldations must also
invalidate m_clientLayers.

Test: css3/filters/reference-filter-update-on-attribute-change.html

* rendering/svg/RenderSVGResourceContainer.cpp:
(WebCore::RenderSVGResourceContainer::markAllClientsForInvalidation):
(WebCore::RenderSVGResourceContainer::markAllClientLayersForInvalidation):
* rendering/svg/RenderSVGResourceContainer.h:
Refactor client layer invalidation out into its own function.
* rendering/svg/RenderSVGResourceFilter.cpp:
(WebCore::RenderSVGResourceFilter::primitiveAttributeChanged):
Mark all client layers for invalidation when a filter primitve attribute is
changed.

LayoutTests:

New reftest to verify filter attribute change invalidations.

* css3/filters/reference-filter-update-on-attribute-change-expected.html: Added.
* css3/filters/reference-filter-update-on-attribute-change.html: Added.


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