Revert 150342 "Implement filter primitive subregion for referenc..."

This caused 2 tests to crash will null pointers:
css3/filters/effect-reference-composite.html
css3/filters/effect-reference-ordering-hw.html

> Implement filter primitive subregion for reference CSS filters.  This required copying determineFilterPrimitiveSubregion() from RenderSVGResourceFilter out into FilterEffect, and modifying it slightly (to accommodate CSS's inflatable result rects; see below). This also required refactoring m_filterRegion and m_absoluteFilterRegion into the Filter base class, and giving its accessors sane names.
> 
> There was also a call to setClipsToBounds(false) for the FilterOperations nodes converted to FilterEffects.  However, this is not correct for reference filters -- they should clip to their filter primitive subregion.  (In fact, it was only being called on the final node in a reference effect chain, just to be super-confusing.)  This was fixed by calling setEffectBoundaries() while building the reference filter, and skipping the call to setClipsToBounds(false).
> 
> The filter outsets for reference filters are now computed by recursively traversing the DAG, so the graphics layers will be created at the appropriately-inflated size, as is done for shorthand filters. The actual per-FilterEffect-subclass computation (mapRect) was refactored from the existing code to compute absolutePaintRects, and made bidirectional. It's used for computing outsets in the forward direction, and source rects in the reverse direction.
> 
> We now no longer call setMaxEffectsRects() directly, but instead call determineFilterPrimitiveSubregion() recursively on the output node. This will set the maxEffectRect as well as the absolutePaintRect, inflating and clipping as necessary. This uses the filter primitive subregion (if set, as in the reference filter case), or the source rect (if not).
> 
> Note that this patch only supports filter primitive subregion, not filter effect region, which still defaults to 100% of the filterBoxRect.
> 
> Finally, I noticed that the colorspace for reference filters was not being correctly set either (same place as the setClipsToBounds() call).  That will require a bunch of rebaselines, however, so it'll be fixed in a separate patch.
> 
> BUG=237518
> R=schenney@chromium.org
> 
> Review URL: https://codereview.chromium.org/14652016

TBR=senorblanco@chromium.org

Review URL: https://codereview.chromium.org/14852010

git-svn-id: svn://svn.chromium.org/blink/trunk@150369 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Get rid of Gradient::getColor()

Merges http://trac.webkit.org/changeset/150088 by Benjamin Poulain.

BUG=none
R=pdr@chromium.org

Review URL: https://codereview.chromium.org/15178004

git-svn-id: svn://svn.chromium.org/blink/trunk@150370 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Refactor compositing reasons so that it can be pushed to cc::layer

Along the way, I took the opportunity to do some much-needed house cleaning.
This patch does not get all the way to a clean state, but paves the way.

Changes in this patch:

1. Removed viewportConstrainedNotCompositedReason from needsToBeComposited and
   requiresCompositingLayer. It is accessed directly from
   requiresCompositingForPosition where the value is needed.

2. Added helper function requiresCompositingForBackfaceVisibility for
   consistency

3. Changed CompositingReasonClipsCompositingDescendants into an indirect
   reason.

4. Added an explicit reason for reflections of composited parents (reflections
   with composited descendants already existed).

5. Merged indirectCompositingReasons into all CompositingReasons

6. At that point, requiresCompositingLayer() ended up being a trivial helper
   function that causes more confusion thatn its worth, so it's removed now.

7. Refactored computeCompositingRequirements to accumulate all
   compositingReasons, cleaned up comments.

BUG=233466
R=enne@chromium.org

Review URL: https://codereview.chromium.org/15013006

git-svn-id: svn://svn.chromium.org/blink/trunk@150371 bbb929c8-8fbe-4397-9dbb-9b2b20218538
build fix after 150371

TBR=eseidel@chromium.org

Review URL: https://codereview.chromium.org/14594014

git-svn-id: svn://svn.chromium.org/blink/trunk@150372 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Revert 150055 "Consider "mixed content XHR" as mixed script inst..."

> Consider "mixed content XHR" as mixed script instead of mixed display.
> 
> BUG=239540
> R=abarth@chromium.org
> 
> Review URL: https://codereview.chromium.org/14619021

TBR=cevans@chromium.org

Review URL: https://codereview.chromium.org/14793022

git-svn-id: svn://svn.chromium.org/blink/trunk@150373 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Build fix for 150371 part 2.  The fix in 150372 was incomplete.

TBR=eseidel@chromium.org

Review URL: https://codereview.chromium.org/14794010

git-svn-id: svn://svn.chromium.org/blink/trunk@150374 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Remove dead ContextMenu code from Blink core

Most of ContextMenuController was devoted to building up context menus
and handling actions for those menus it had built up, but in Blink/Chromium,
those menus are almost entirely dropped on the floor by the embedder.
Only those menu items tagged as "custom" are preserved. And these are added
elsewhere, by ContextMenuProvider instances; the only currently-existing
one belongs to the web inspector.

As part of this cleanup, renamed ContextMenuClient::customizeMenu() to
showContextMenu(), since it's a call to that method from the controller
which actually causes a context menu to appear. Also tightened up that
method, which has no reason to transfer ownership (or even allow mutation)
of its ContextMenu to the embedder.

R=darin

Review URL: https://chromiumcodereview.appspot.com/14795011

git-svn-id: svn://svn.chromium.org/blink/trunk@150375 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Disable flaky AssociatedURLLoaderTest.RedirectCrossOriginWithAccessControlFailure

TBR=bbudge

BUG=240912

Review URL: https://codereview.chromium.org/14573010

git-svn-id: svn://svn.chromium.org/blink/trunk@150376 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Make mediastream objects ScriptWrappable

This change allows binding intergrity checks to be applied to these obects.

R=abarth@chromium.org
BUG=236671

Review URL: https://chromiumcodereview.appspot.com/15042007

git-svn-id: svn://svn.chromium.org/blink/trunk@150377 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Hookup painting to texture path for media stream on Android

There are 2 WebMediaPlayer implementations on Android, one is WebMediaPlayerAndroid for regular <video> playback, while the other is WebMediaPlayerMS for WebRTC <video> display. They are very different due to the difference between buffered playback and real time communication, and how WMPAndroid is implemented (it uses media player service which WMPMS can't use).

Currently, when WebMediaPlayerClientImpl is asked to paint video frames to a texture, it eventually calls m_webMediaPlayer->copyVideoTextureToPlatformTexture which is not implemented in WMPMS because WMPMS is going s/w path, i.e., expecting paint() call.

This patch will hookup paint correctly when it's WebRTC
<video> display.

A new layout test is added to catch this case. Basically, the new layout test clears out canvas with black color, then draws one video frame to the canvas. Since all pixels in the video frame are non-black, it will test the pixel value in canvas against black.

BUG=239541
R=jamesr@chromium.org, qinmin@chromium.org

Review URL: https://codereview.chromium.org/14715015

git-svn-id: svn://svn.chromium.org/blink/trunk@150378 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Shrink libwebkit.so by 243KB

This CL removes the "inline" attribute from the hash table "add" functions,
letting the compile move them out of line. This CL shrinks the size of
libwebkit.so in the Linux Component Release build by 243KB.

There's potentially a lot more binary to be saved in this area as evidenced by
https://codereview.chromium.org/15031006/, but this CL is a start.

To assess the performance impact, I ran Parser/html5-full-render.html 15 times
both with and without this CL. I saw a 0.65% regression, which might be real
or it might be noise. IMHO, we should land this CL and see what the full perf
test suite has to say.

Review URL: https://chromiumcodereview.appspot.com/14995017

git-svn-id: svn://svn.chromium.org/blink/trunk@150379 bbb929c8-8fbe-4397-9dbb-9b2b20218538
dispatchEvent call can execute javascript and blow away endRoot from underneath. Make the argument startRoot and endRoot as PassRefPtr.

BUG=237429
TEST=webkit/tools/layout_tests/run_webkit_tests.sh editing/undo/undo-after-setting-value.html editing/undo/undo-after-event-edited.html

Review URL: https://chromiumcodereview.appspot.com/14829006

git-svn-id: svn://svn.chromium.org/blink/trunk@150380 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Add parsing for named grid lines

This extends our grammar to support named grid lines (no support
for named grid lines with 'span' yet, though the testing for that
is added as part of this change).

The idea is that we convert the existing "integer position" into an
explicit position that covers [ <integer> || <string> ] in the
grammar. Also to simplify StyleResolver, we always create a
CSSValueList with the different values in a well-defined order.

The grid-item-*-get-set.html tests were improved to support the
extended grammar and some clean-up was done in the invalid cases
in grid-item-column-row-get-set.html as a lot of them could fail
for 2 reasons (both positions are span and another one).

BUG=234192
TESTS=fast/css-grid-layout/grid-item-column-row-get-set.html
      fast/css-grid-layout/grid-item-end-after-get-set.html
      fast/css-grid-layout/grid-item-start-before-get-set.html

Review URL: https://chromiumcodereview.appspot.com/14715014

git-svn-id: svn://svn.chromium.org/blink/trunk@150381 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Pull in http://trac.webkit.org/changeset/150087.

Will get a less hacky solution once http://lists.w3.org/Archives/Public/www-style/2013May/0342.html is resolved.

BUG=240741

Change description from the patch:
The new flexbox spec says that flex-basis omitted in the flex shorthand defaults to
0 when flex-grow/shrink are set. This has undesirable behavior when objects don't
end up flexing at all, and it's something the spec is going to eventually address.

For now, though, to fix the regression, I'm making a targeted "hack" to deliberately
violate the spec, but to do so as minimally as possible. This hack detects if there
is infinite available space on a line, and if so, it treats a flex-basis of 0 like
auto.

This means that when height is constrained and set by a container, flexing will do
the right thing. Basically any time you end up actually flexing, the spec behavior
should happen. If you're just laying out at intrinsic sizes, though, and no flexing
is going to occur, we ignore a flex-basis of 0 and just use the child's normal size.

Note that widths don't have to be patched because the preferred logical widths
algorithm is broken right now and not checking flex-basis. If it did, we'd have seen
the same bug in the width direction.

This width issue is covered by https://bugs.webkit.org/show_bug.cgi?id=116117

* rendering/RenderFlexibleBox.cpp:
(core::RenderFlexibleBox::mainAxisContentExtent):
Make sure we return LayoutUnit::max when you have infinite free space and not
max - borderPadding.

(core::RenderFlexibleBox::preferredMainAxisContentExtentForChild):
Only clear override size if it was set. Only mark for relayout if we did
an override size clear (i.e., if we were actually flexed). Add a new parameter,
hasInfiniteLineLength, that - if set - causes us to special case flex-basis:0
and treat it like flex-basis:auto.

(core::RenderFlexibleBox::layoutFlexItems):
Define hasInfiniteLineLength and pass it to all the functions that need it.

(core::RenderFlexibleBox::computeMainAxisPreferredSizes):
Remove the code that marks for layout and does a layout so early. This code
is moving (and changing) to preferredMainAxisContentExtentForChild.

(core::RenderFlexibleBox::computeNextFlexLine):
Computes whether or not we have infinite line length now.

(core::RenderFlexibleBox::freezeViolations):
(core::RenderFlexibleBox::resolveFlexibleLengths):
Propagate hasInfiniteLineLength through to preferredMainAxisContentExtentForChild.

* rendering/RenderFlexibleBox.h:
(RenderFlexibleBox):
Add hasInfiniteLineLength parameter to a bunch of functions.

Review URL: https://chromiumcodereview.appspot.com/15051005

git-svn-id: svn://svn.chromium.org/blink/trunk@150382 bbb929c8-8fbe-4397-9dbb-9b2b20218538