Mark a fast/events/onerror-no-constructor.html as failing after v8 roll.

BUG=369600
TBR=loislo

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173225 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Mark virtual/gpu/fast/canvas/canvas-overflow-hidden-animation.html as Crash Pass.

R=fmalita@chromium.org
BUG=369615

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173226 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Pass current value of attributes to WebDOMActivityLogger Setter logs.

Pass the current value of attributes to WebDOMActivityLogger in Setter calls.
In order to keep this clean, separate out log() into logMethod(), logGetter(),
and logSetter().

This is necessary for improvements to the ActivityLogger, where we need to detect if a modification of certain attributes is a switch from a current setting, or an initialization.  In the case of the former, we may need to treat this differently (as it could be modifying to perform ad injection, or other nefarious purposes). 

BUG=356890

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173227 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Remove unreachable code.

BUG=346399
TEST=none

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173228 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Use correct process lock for WaveShaperProcessor

The WaveShaperProcessor should inherit the m_processLock from the
parent class instead of creating its own.  The parent's m_processLock
correctly synchronizes access and processing.

Added a simple test from the bug report.  Manually tested to fail on
Chrome 35, but passes with this CL.

TEST=waveshaper-364379.html
BUG=364379

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173229 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Auto-rebaseline for r173153

http://src.chromium.org/viewvc/blink?view=revision&revision=173153

BUG=368518
TBR=enne@chromium.org

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173230 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Rerebaseline two repaint tests

These two collided in a rebaseline between repaint-after-layout changes
and forc ecompositing mode repaint test changes.  The results are
correct and just need a new baseline.

BUG=369419

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173231 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Directly schedule compositing updates for <canvas>

Instead of using scheduleLayerUpdate() to trigger the compositing state
change for the <canvas>, we can directly set the bits on the
RenderLayerCompositor and our RenderLayer.

This removes several usages of scheduleLayerUpdate(), which we want to
remove since it requires calling into setStyle() with identical styles
and is the source of chicken and egg issues with the compositing update.

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173232 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Revert of Make CSSFontFace::willUseFontData() load fonts with unicode-range (https://codereview.chromium.org/248473005/)

Reason for revert:
Causes off-by-one text errors, e.g. SHOP->RGNO

BUG=369633

Original issue's description:
> Make CSSFontFace::willUseFontData() load fonts with unicode-range
> 
> Before this patch CSSFontFace::willUseFontData() loads font faces that
> have no unicode-range. Since font faces with no unicode-range tends to
> be used as fallback font of segmented font family, this behavior leads
> to unnecessary font downloads.
> 
> This patch makes willUseFontData() loads the first unloaded font face
> whose unicode-range intersects with given text. That check does not
> need to be 100% precise (false negative is ok), so it only checks the
> first character of the text, for speed.
> 
> TEST=fast/css/font-face-unicode-range-overlap-load.html
> BUG=247920,246492
> 
> Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=172943

TBR=dglazkov@chromium.org,eae@chromium.org,ksakamoto@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=247920,246492

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173234 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Auto-rebaseline for r173153

http://src.chromium.org/viewvc/blink?view=revision&revision=173153

BUG=368518
TBR=enne@chromium.org

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173235 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Auto-rebaseline for r173212

http://src.chromium.org/viewvc/blink?view=revision&revision=173212

BUG=235189
TBR=robhogan@gmail.com

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173236 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Don't clobber equivalent paint info when changing squashing assignment.

This CL makes two changes:

1) If the new and old GraphicsLayerPaintInfo objects are
equivalent for squashing, there's no need to overwrite the
other fields in the struct.

2) When we add or remove a RenderLayer from a squashing
layer, we now mark the CompositedLayerMapping for a graphics
update. This change ensures that we'll program the data about
the newly squashed layers into the compositor.

This CL is based on https://codereview.chromium.org/265083002
by vollick@

BUG=368504

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173237 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Fix for cast extension pop-up is all blank.

For extensions, WebViewImpl runs in AutoResizeMode so resize()
is never called so the pinch viewport's compositing layers never
got their bounds set. When masks_to_bounds was turned on the
extensions were masked out by their empty-sized clipping layers.

This fix sets the pinch viewport size explicitly from the
layoutUpdated callback in the case of AutoResizeMode.

BUG=369331

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173238 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Auto-rebaseline for r173153

http://src.chromium.org/viewvc/blink?view=revision&revision=173153

BUG=368518
TBR=enne@chromium.org

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173239 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Auto-rebaseline for r173171

http://src.chromium.org/viewvc/blink?view=revision&revision=173171

BUG=369376
TBR=noel@chromium.org

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173240 bbb929c8-8fbe-4397-9dbb-9b2b20218538
FCMify compositing layout tests that now have a layer tree

BUG=361729

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173241 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Convert layout tests to FCM that have small pixel diffs

These tests all have small pixel differences when run through FCM.  They
are all still correct.  This is the last batch of Linux pixel
differences that aren't in svg.

Convert them to FCM manually and rebaseline.

BUG=361729

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173242 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Deinline PartitionAlloc from DefaultAllocator to reduce code size

DefaultAllocator calls PartitionAlloc functions from inline methods.
PartitionAlloc consist of always inline functions. This result in a huge
code bloat as DefaultAllocator is used as template argument in wtf templatized
containers. We only need to do the allocation via PartitionAlloc directly when
the container's buffer is created or resized so it doesn't seem to worth the
cost in code size to inline them.

This patch reduced the size of content_shell in my static release build with ~0.5 megabyte.
Reference size: 84514K, 61492K after stripping. Patched: 84083K and 61052K.

This is neutral on Android where -Os already does a good job and deny to inline.

I think we can rely on the performance bots to make sure that this doesn't result in performance regression.

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173243 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Handle touch events containing touches not previously reported to blink

Chromium has a couple optimizations which suppress sending touch events
to the renderer (for example, when they're at a place or time known not
to contain touch event handlers).  Our security fix in
http://crbug.com/148567 assumed we'd always see every touchstart event,
so if we got an event which had a point we'd never seen we'd
effectively ignore the event completely.

Touch events do their hit-test on touchstart, and every TouchEvent
contains a touches array for all active touches.  So if we're going
to skip sending some touchstart events, we need to define how those
active touch points show up in the events for other points.  This
problem is similar to how touches should show up for fingers that
are down on iframes outside the bounds of the document receiving
touch events.  I think it's important that we include such touches
(otherwise an app could mis-recognize a two-finger gesture as a
single finger one), but their 'target' should be irrelevant since
we know it wasn't capable of receiving the touch events.  So here
I just set the target to the document.  This also updates the
cross-iframe case, we were previously hiding such points completely.

I've split the main loop across points into two stages (each with
their own loop).  First we do any necessary hit tests, including
establishing the active touch sequence document if it wasn't
previously determined.  Then we create all the Touch objects,
where we may rely on the active touch sequence document determined
by some later point.

This CL also contains a number of overdue cleanups to account for the
fact that we now only need to hit-test on touchstart, and that there's
only ever a single document receiving touch events at any time.
Also rather than use a funky ID+1 key for our touch target HashMap,
just use the ID but ensure HashMap supports 0-value keys by using
UnsignedWithZeroKeyHashTraits.

BUG=363321

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173245 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Rebase text tests after skia roll (chromium r267818)

TBR=loislo
BUG=

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

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