Fix a rendering bug when frames have no dirty rect on display list mode.

In the current implementation, finalizeFrameInternal() is returned early when
the image buffer doesn't have dirty rect. Even so we should transfer a state
stack to next canvas.

BUG=392614

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

git-svn-id: svn://svn.chromium.org/blink/trunk@182556 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Get rid of dataToExamine from sheriff-o-matic.

It doesn't serve any purpose. We should just pass the CTFailureGroup
directly to the ct-results-panel. In addition to simplifying the code
this fixes a bug introduced in r182172 where examine pages wouldn't
work.

Store the failure group key in the pushState so that we have an easy
way to grab the key out and find the right CTFailureGroup on popState.

Added a new test to ct-results-panel-tests for the url results panel case.
Also, cleaned up this test to get rid of the unnecessary use of beforeEach.
beforeEach was making it hard to write the url test because it used global
state that didn't apply.

NOTRY=true
R=leviw@chromium.org, michaelpg@chromium.org

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

git-svn-id: svn://svn.chromium.org/blink/trunk@182557 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Skip imported/web-platform-tests/custom-elements/.../no-registry-test.html

As this test requires http server to run, skip this test in imported/
directory and have the same test in http/.

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

git-svn-id: svn://svn.chromium.org/blink/trunk@182558 bbb929c8-8fbe-4397-9dbb-9b2b20218538
[blink] Pass SkBitmap by reference in WebNinePatchLayer::setBitmap and refactor

Although passing SkBitmap by value doesn't copy the underlying pixels, it indeed
involves memcpy (~64 bytes to be precise) to replicate the settings from the
other bitmap in the copy constructor.

This overhead, albeit minor, can be avoided by passing SkBitmap as reference.

R=jamesr@chromium.org

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

git-svn-id: svn://svn.chromium.org/blink/trunk@182559 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Update expectations for serviceworker/request.html after V8 roll.

The latest V8 roll https://codereview.chromium.org/595883002 tickles
something in this test on ia32 machines.

In debug mode it hits an assert and in release mode it times out.

Updating the test expectations for now while the issue is investigated.

TBR=horo@chromium.org, jkummerow@chromium.org
BUG=409755
NOTRY=true

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

git-svn-id: svn://svn.chromium.org/blink/trunk@182560 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Fix test in sheriff-o-matic.

I broke this in my last commit. The category was failedOnce instead
of default for this test, which meant the failure group didn't get
stamped out. Instead, make it a regular failure so that the category
becomes default.

TBR=leviw@chromium.org
NOTRY=true

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

git-svn-id: svn://svn.chromium.org/blink/trunk@182561 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Mark recently added inspector timeline test as flaky.

TBR=yurys@chromium.org
BUG=412782

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

git-svn-id: svn://svn.chromium.org/blink/trunk@182562 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Make narrowPrecisionToFloat() use clampTo<float>() instead of static_cast.

For numbers within the range of valid floats, this has no effect.  For numbers
outside that range, the old code was technically undefined behavior (and in
practice would result in bad things like converting to infinity).  Now such
numbers will be deterministically clamped to +/-FLOAT_MAX.

BUG=416991
TEST=svg/text/svg-zoom-large-value.xhtml should not cause asserts with the patch on https://codereview.chromium.org/521543002/

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

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