GitLab

BUG=626274

Review-Url: https://codereview.chromium.org/2244943002
Cr-Commit-Position: refs/heads/master@{#413414}

After ThreadedWorklet is introduced, worklet code gets more tied up with
worker code, so it'd be reasonable that they are located in the same directory.

BUG=567358

Review-Url: https://codereview.chromium.org/2262483003
Cr-Commit-Position: refs/heads/master@{#413413}

Temporarily unbind current transform feedback object to make
glResumeTransformFeedback actually work correctly.

BUG=638514
TEST=webgl2_conformance_test/deqp/functional/gles3/transformfeedback on mac
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2252153003
Cr-Commit-Position: refs/heads/master@{#413412}

It was hidden to the user since chrome://gpu was not showing
any workarounds, but they were still applied in the gpu process.

Also add a gpu test that sets
--disable-gpu-driver-bug-workarounds --use_gpu_driver_workaround_for_testing
and verifies that the only active workaround is USE_TESTING_GPU_DRIVER_WORKAROUND
in both browser and gpu processes.

BUG=359367

R=kbr@chromium.org, zmo@chromium.org

TEST=./content/test/gpu/run_gpu_test.py gpu_process --show-stdout --browser=exact --extra-browser-args="--no-sandbox" --browser-executable=./out/build/chrome
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Committed: https://crrev.com/d18006d595e7b6bf070f9ab9777d353ac8457755
Committed: https://crrev.com/7eee382917c50ad10a487ef1c1402adc8c84e9fd
Committed: https://crrev.com/87c144ab365dacd92f2bb7720628e3397a44c2d6
Review-Url: https://codereview.chromium.org/2195743005
Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#409197}
Cr-Original-Original-Commit-Position: refs/heads/master@{#412685}
Cr-Original-Commit-Position: refs/heads/master@{#412989}
Cr-Commit-Position: refs/heads/master@{#413411}

According to the HTML specification [1], we should throw a TypeError if a non-Date
object is specified to valueAsDate.
 - Update toCoreDate() so that it throws a TypeError for non-Date objects.
 - Also, add DCHECKs to WTF::msToYear.

Note: Web IDL CR doesn't accept |null| for Date conversion [2]. However the
specification itself is deprecated.

[1] https://html.spec.whatwg.org/multipage/forms.html#dom-input-valueasdate
[2] https://www.w3.org/TR/WebIDL/#es-Date

BUG=637115

Review-Url: https://codereview.chromium.org/2265443002
Cr-Commit-Position: refs/heads/master@{#413410}

A mostly-automated change to convert instances of WrapUnique(new Foo(...)) to
MakeUnique<Foo>(...). See the thread at
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/iQgMedVA8-k
for background.

To avoid requiring too many manual fixups, the change skips some cases that are
frequently problematic. In particular, in methods named Foo::Method() it will
not try to change WrapUnique(new Foo()) to MakeUnique<Foo>(). This is because
Foo::Method() may be accessing an internal constructor of Foo.

Cases where MakeUnique<NestedClass>(...) is called within a method of
OuterClass are common but hard to detect automatically, so have been fixed-up
manually.

The only types of manual fix ups applied are:
1) Revert MakeUnique back to WrapUnique
2) Change NULL to nullptr in argument list (MakeUnique cannot forward NULL
   correctly)
3) Add base:: namespace qualifier where missing.

WrapUnique(new Foo) has not been converted to MakeUnique<Foo>() as this might
change behaviour if Foo does not have a user-defined constructor. For example,
WrapUnique(new int) creates an unitialised integer, but MakeUnique<int>()
creates an integer initialised to 0.

git cl format has been been run over the CL. Spot-checking has uncovered no
cases of mis-formatting.

  BUG=637812
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2258833002
Cr-Commit-Position: refs/heads/master@{#413409}

- Use single-line comments.
- Update comments
- Unexport WTFGetBacktrace() and WTFPrintBacktrace()
- Remove unused ASSERT_MSG_DISABLED macro

This CL has no behavior changes.

Review-Url: https://codereview.chromium.org/2254153002
Cr-Commit-Position: refs/heads/master@{#413408}

This patch converts "editing/deleting/delete-leading-ws-001.html"
to use w3c test harness to simplify test script for improving readability.

BUG=n/a
TEST=n/a; no behavior changes

Review-Url: https://codereview.chromium.org/2264463002
Cr-Commit-Position: refs/heads/master@{#413407}

(Note: This patch was reverted in crrev.com/2213223004 because of issues
crbug.com/633859 and crbug.com/634254. These issues were caused from
setting isInherited to false instead of true for the StyleBuilder
generated inherit functions, and a slotting bug from skipping child
recalc in HTMLSlotElement and InsertionPoints, which have both now been
fixed in this patch & have tests added.)

Add a fast-path for inherited properties which do not depend on and do
not affect any other properties on ComputedStyle. When these properties
are modified in a parent element, set them directly on ComputedStyle and
skip doing a full recalc for elements only affected by this change.

Also implemented two of these properties: visibility and pointer-events,
storing an extra 2 bits per ComputedStyle. This increases the size of
ComputedStyle by 1 byte on Windows and some Android builds (due to
aligned fields), which increases the memory usage for a standard page
with ~1000 elements by up to 1kb (although potentially up to 4/8kb on
32/64 bit builds due to packing, although this depends on the allocator
implementation details) but realistically less since style sharing only
creates one ComputedStyle object for each unique style.

Benchmarks show a speed increase of up to 2x for setting these
properties on the root element of a typical web page (Facebook, Twitter,
Pinterest, Amazon, Wikipedia) and letting the change propagate directly
onto the child ComputedStyle objects, rather than doing a full style
recalc.

Initial Benchmarks:
https://docs.google.com/spreadsheets/d/1mUuJEs8cPWyNTR7tQw27oxq6fDTvWiAwgatf_g--B4w/edit#gid=1597242813

Follow-up Benchmarks:
https://docs.google.com/spreadsheets/d/1mUuJEs8cPWyNTR7tQw27oxq6fDTvWiAwgatf_g--B4w/edit#gid=918856082

BUG=622138

Review-Url: https://codereview.chromium.org/2220873002
Cr-Commit-Position: refs/heads/master@{#413406}

BUG=402536

Review-Url: https://codereview.chromium.org/2259253002
Cr-Commit-Position: refs/heads/master@{#413405}

A mostly-automated change to convert instances of WrapUnique(new Foo(...)) to
MakeUnique<Foo>(...). See the thread at
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/iQgMedVA8-k
for background.

To avoid requiring too many manual fixups, the change skips some cases that are
frequently problematic. In particular, in methods named Foo::Method() it will
not try to change WrapUnique(new Foo()) to MakeUnique<Foo>(). This is because
Foo::Method() may be accessing an internal constructor of Foo.

Cases where MakeUnique<NestedClass>(...) is called within a method of
OuterClass are common but hard to detect automatically, so have been fixed-up
manually.

The only types of manual fix ups applied are:
1) Revert MakeUnique back to WrapUnique
2) Change NULL to nullptr in argument list (MakeUnique cannot forward NULL
   correctly)
3) Add base:: namespace qualifier where missing.

WrapUnique(new Foo) has not been converted to MakeUnique<Foo>() as this might
change behaviour if Foo does not have a user-defined constructor. For example,
WrapUnique(new int) creates an unitialised integer, but MakeUnique<int>()
creates an integer initialised to 0.

git cl format has been been run over the CL. Spot-checking has uncovered no
cases of mis-formatting.

  BUG=637812

Review-Url: https://codereview.chromium.org/2256733004
Cr-Commit-Position: refs/heads/master@{#413404}

Those properties are: background-image, border-image-source, list-style-image, content, and shape-outside.

Spec: https://drafts.css-houdini.org/css-typed-om/#mapping-of-properties-to-accepted-types

BUG=545318

Review-Url: https://codereview.chromium.org/2220253002
Cr-Commit-Position: refs/heads/master@{#413403}

Revert of bluetooth: Return false for IsPresent only when bluetooth is not supported (patchset #1 id:1 of https://codereview.chromium.org/2248033006/ )

Reason for revert:
device_unittests: BluetoothTest.ConstructDefaultAdapter is failing.

Original issue's description:
> bluetooth: Return false for IsPresent only when bluetooth is not supported
>
> BUG=633274
>
> Committed: https://crrev.com/784971913adcc32bdb22a92da6ac237a7de88a2b
> Cr-Commit-Position: refs/heads/master@{#413192}

TBR=jyasskin@chromium.org,ortuno@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=633274

Review-Url: https://codereview.chromium.org/2262033002
Cr-Commit-Position: refs/heads/master@{#413402}

https://chromium.googlesource.com/skia.git/+log/577e012e4058..5755cd98a749

$ git log 577e012e4..5755cd98a --date=short --no-merges --format='%ad %ae %s'
2016-08-21 reed make zoomer text clearer

CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
TBR=bungeman@google.com

Review-Url: https://codereview.chromium.org/2265843002
Cr-Commit-Position: refs/heads/master@{#413401}

A mostly-automated change to convert instances of WrapUnique(new Foo(...)) to
MakeUnique<Foo>(...). See the thread at
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/iQgMedVA8-k
for background.

To avoid requiring too many manual fixups, the change skips some cases that are
frequently problematic. In particular, in methods named Foo::Method() it will
not try to change WrapUnique(new Foo()) to MakeUnique<Foo>(). This is because
Foo::Method() may be accessing an internal constructor of Foo.

Cases where MakeUnique<NestedClass>(...) is called within a method of
OuterClass are common but hard to detect automatically, so have been fixed-up
manually.

The only types of manual fix ups applied are:
1) Revert MakeUnique back to WrapUnique
2) Change NULL to nullptr in argument list (MakeUnique cannot forward NULL
   correctly)
3) Add base:: namespace qualifier where missing.

WrapUnique(new Foo) has not been converted to MakeUnique<Foo>() as this might
change behaviour if Foo does not have a user-defined constructor. For example,
WrapUnique(new int) creates an unitialised integer, but MakeUnique<int>()
creates an integer initialised to 0.

git cl format has been been run over the CL. Spot-checking has uncovered no
cases of mis-formatting.

  BUG=637812
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2257713003
Cr-Commit-Position: refs/heads/master@{#413400}

A mostly-automated change to convert instances of WrapUnique(new Foo(...)) to
MakeUnique<Foo>(...). See the thread at
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/iQgMedVA8-k
for background.

To avoid requiring too many manual fixups, the change skips some cases that are
frequently problematic. In particular, in methods named Foo::Method() it will
not try to change WrapUnique(new Foo()) to MakeUnique<Foo>(). This is because
Foo::Method() may be accessing an internal constructor of Foo.

Cases where MakeUnique<NestedClass>(...) is called within a method of
OuterClass are common but hard to detect automatically, so have been fixed-up
manually.

The only types of manual fix ups applied are:
1) Revert MakeUnique back to WrapUnique
2) Change NULL to nullptr in argument list (MakeUnique cannot forward NULL
   correctly)
3) Add base:: namespace qualifier where missing.

WrapUnique(new Foo) has not been converted to MakeUnique<Foo>() as this might
change behaviour if Foo does not have a user-defined constructor. For example,
WrapUnique(new int) creates an unitialised integer, but MakeUnique<int>()
creates an integer initialised to 0.

git cl format has been been run over the CL. Spot-checking has uncovered no
cases of mis-formatting.

  BUG=637812

Review-Url: https://codereview.chromium.org/2259523003
Cr-Commit-Position: refs/heads/master@{#413399}

Since deterministic_build_blacklist.json is used by not only
compare_build_artifacts.py but also remove_build_metadata.py,
let me rename the directory name to determinism to reflect
what this is.

BUG=314403

Review-Url: https://codereview.chromium.org/2260053003
Cr-Commit-Position: refs/heads/master@{#413398}

A mostly-automated change to convert instances of WrapUnique(new Foo(...)) to
MakeUnique<Foo>(...). See the thread at
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/iQgMedVA8-k
for background.

To avoid requiring too many manual fixups, the change skips some cases that are
frequently problematic. In particular, in methods named Foo::Method() it will
not try to change WrapUnique(new Foo()) to MakeUnique<Foo>(). This is because
Foo::Method() may be accessing an internal constructor of Foo.

Cases where MakeUnique<NestedClass>(...) is called within a method of
OuterClass are common but hard to detect automatically, so have been fixed-up
manually.

The only types of manual fix ups applied are:
1) Revert MakeUnique back to WrapUnique
2) Change NULL to nullptr in argument list (MakeUnique cannot forward NULL
   correctly)
3) Add base:: namespace qualifier where missing.

WrapUnique(new Foo) has not been converted to MakeUnique<Foo>() as this might
change behaviour if Foo does not have a user-defined constructor. For example,
WrapUnique(new int) creates an unitialised integer, but MakeUnique<int>()
creates an integer initialised to 0.

git cl format has been been run over the CL. Spot-checking has uncovered no
cases of mis-formatting.

  BUG=637812

Review-Url: https://codereview.chromium.org/2254183002
Cr-Commit-Position: refs/heads/master@{#413397}

A mostly-automated change to convert instances of WrapUnique(new Foo(...)) to
MakeUnique<Foo>(...). See the thread at
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/iQgMedVA8-k
for background.

To avoid requiring too many manual fixups, the change skips some cases that are
frequently problematic. In particular, in methods named Foo::Method() it will
not try to change WrapUnique(new Foo()) to MakeUnique<Foo>(). This is because
Foo::Method() may be accessing an internal constructor of Foo.

Cases where MakeUnique<NestedClass>(...) is called within a method of
OuterClass are common but hard to detect automatically, so have been fixed-up
manually.

The only types of manual fix ups applied are:
1) Revert MakeUnique back to WrapUnique
2) Change NULL to nullptr in argument list (MakeUnique cannot forward NULL
   correctly)
3) Add base:: namespace qualifier where missing.

WrapUnique(new Foo) has not been converted to MakeUnique<Foo>() as this might
change behaviour if Foo does not have a user-defined constructor. For example,
WrapUnique(new int) creates an unitialised integer, but MakeUnique<int>()
creates an integer initialised to 0.

git cl format has been been run over the CL. Spot-checking has uncovered no
cases of mis-formatting.

  BUG=637812

Review-Url: https://codereview.chromium.org/2259823003
Cr-Commit-Position: refs/heads/master@{#413396}

Cr-Commit-Position: refs/heads/master@{#413395}

A mostly-automated change to convert instances of WrapUnique(new Foo(...)) to
MakeUnique<Foo>(...). See the thread at
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/iQgMedVA8-k
for background.

To avoid requiring too many manual fixups, the change skips some cases that are
frequently problematic. In particular, in methods named Foo::Method() it will
not try to change WrapUnique(new Foo()) to MakeUnique<Foo>(). This is because
Foo::Method() may be accessing an internal constructor of Foo.

Cases where MakeUnique<NestedClass>(...) is called within a method of
OuterClass are common but hard to detect automatically, so have been fixed-up
manually.

The only types of manual fix ups applied are:
1) Revert MakeUnique back to WrapUnique
2) Change NULL to nullptr in argument list (MakeUnique cannot forward NULL
   correctly)
3) Add base:: namespace qualifier where missing.

WrapUnique(new Foo) has not been converted to MakeUnique<Foo>() as this might
change behaviour if Foo does not have a user-defined constructor. For example,
WrapUnique(new int) creates an unitialised integer, but MakeUnique<int>()
creates an integer initialised to 0.

git cl format has been been run over the CL. Spot-checking has uncovered no
cases of mis-formatting.

  BUG=637812

Review-Url: https://codereview.chromium.org/2254973004
Cr-Commit-Position: refs/heads/master@{#413394}

To reduce the string comparison in SiteFromURL().

This CL depends on https://codereview.chromium.org/2251633002/.

https://codereview.chromium.org/2249063004/ depends on this CL.

BUG=561209

Review-Url: https://codereview.chromium.org/2250623003
Cr-Commit-Position: refs/heads/master@{#413393}

A mostly-automated change to convert instances of WrapUnique(new Foo(...)) to
MakeUnique<Foo>(...). See the thread at
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/iQgMedVA8-k
for background.

To avoid requiring too many manual fixups, the change skips some cases that are
frequently problematic. In particular, in methods named Foo::Method() it will
not try to change WrapUnique(new Foo()) to MakeUnique<Foo>(). This is because
Foo::Method() may be accessing an internal constructor of Foo.

Cases where MakeUnique<NestedClass>(...) is called within a method of
OuterClass are common but hard to detect automatically, so have been fixed-up
manually.

The only types of manual fix ups applied are:
1) Revert MakeUnique back to WrapUnique
2) Change NULL to nullptr in argument list (MakeUnique cannot forward NULL
   correctly)
3) Add base:: namespace qualifier where missing.

WrapUnique(new Foo) has not been converted to MakeUnique<Foo>() as this might
change behaviour if Foo does not have a user-defined constructor. For example,
WrapUnique(new int) creates an unitialised integer, but MakeUnique<int>()
creates an integer initialised to 0.

git cl format has been been run over the CL. Spot-checking has uncovered no
cases of mis-formatting.

  BUG=637812

Review-Url: https://codereview.chromium.org/2252373002
Cr-Commit-Position: refs/heads/master@{#413392}

https://chromium.googlesource.com/external/github.com/catapult-project/catapult.git/+log/cda4e72f8776..947506bacfb5

$ git log cda4e72f8..947506bac --date=short --no-merges --format='%ad %ae %s'

BUG=639632

TBR=catapult-sheriff@chromium.org

Review-Url: https://codereview.chromium.org/2264903002
Cr-Commit-Position: refs/heads/master@{#413391}

A mostly-automated change to convert instances of WrapUnique(new Foo(...)) to
MakeUnique<Foo>(...). See the thread at
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/iQgMedVA8-k
for background.

To avoid requiring too many manual fixups, the change skips some cases that are
frequently problematic. In particular, in methods named Foo::Method() it will
not try to change WrapUnique(new Foo()) to MakeUnique<Foo>(). This is because
Foo::Method() may be accessing an internal constructor of Foo.

Cases where MakeUnique<NestedClass>(...) is called within a method of
OuterClass are common but hard to detect automatically, so have been fixed-up
manually.

The only types of manual fix ups applied are:
1) Revert MakeUnique back to WrapUnique
2) Change NULL to nullptr in argument list (MakeUnique cannot forward NULL
   correctly)
3) Add base:: namespace qualifier where missing.

WrapUnique(new Foo) has not been converted to MakeUnique<Foo>() as this might
change behaviour if Foo does not have a user-defined constructor. For example,
WrapUnique(new int) creates an unitialised integer, but MakeUnique<int>()
creates an integer initialised to 0.

git cl format has been been run over the CL. Spot-checking has uncovered no
cases of mis-formatting.

  BUG=637812

Review-Url: https://codereview.chromium.org/2253233004
Cr-Commit-Position: refs/heads/master@{#413390}

A mostly-automated change to convert instances of WrapUnique(new Foo(...)) to
MakeUnique<Foo>(...). See the thread at
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/iQgMedVA8-k
for background.

To avoid requiring too many manual fixups, the change skips some cases that are
frequently problematic. In particular, in methods named Foo::Method() it will
not try to change WrapUnique(new Foo()) to MakeUnique<Foo>(). This is because
Foo::Method() may be accessing an internal constructor of Foo.

Cases where MakeUnique<NestedClass>(...) is called within a method of
OuterClass are common but hard to detect automatically, so have been fixed-up
manually.

The only types of manual fix ups applied are:
1) Revert MakeUnique back to WrapUnique
2) Change NULL to nullptr in argument list (MakeUnique cannot forward NULL
   correctly)
3) Add base:: namespace qualifier where missing.

WrapUnique(new Foo) has not been converted to MakeUnique<Foo>() as this might
change behaviour if Foo does not have a user-defined constructor. For example,
WrapUnique(new int) creates an unitialised integer, but MakeUnique<int>()
creates an integer initialised to 0.

git cl format has been been run over the CL. Spot-checking has uncovered no
cases of mis-formatting.

  BUG=637812

Review-Url: https://codereview.chromium.org/2259753003
Cr-Commit-Position: refs/heads/master@{#413389}

A mostly-automated change to convert instances of WrapUnique(new Foo(...)) to
MakeUnique<Foo>(...). See the thread at
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/iQgMedVA8-k
for background.

To avoid requiring too many manual fixups, the change skips some cases that are
frequently problematic. In particular, in methods named Foo::Method() it will
not try to change WrapUnique(new Foo()) to MakeUnique<Foo>(). This is because
Foo::Method() may be accessing an internal constructor of Foo.

Cases where MakeUnique<NestedClass>(...) is called within a method of
OuterClass are common but hard to detect automatically, so have been fixed-up
manually.

The only types of manual fix ups applied are:
1) Revert MakeUnique back to WrapUnique
2) Change NULL to nullptr in argument list (MakeUnique cannot forward NULL
   correctly)
3) Add base:: namespace qualifier where missing.

WrapUnique(new Foo) has not been converted to MakeUnique<Foo>() as this might
change behaviour if Foo does not have a user-defined constructor. For example,
WrapUnique(new int) creates an unitialised integer, but MakeUnique<int>()
creates an integer initialised to 0.

git cl format has been been run over the CL. Spot-checking has uncovered no
cases of mis-formatting.

  BUG=637812

Review-Url: https://codereview.chromium.org/2256813005
Cr-Commit-Position: refs/heads/master@{#413388}

A mostly-automated change to convert instances of WrapUnique(new Foo(...)) to
MakeUnique<Foo>(...). See the thread at
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/iQgMedVA8-k
for background.

To avoid requiring too many manual fixups, the change skips some cases that are
frequently problematic. In particular, in methods named Foo::Method() it will
not try to change WrapUnique(new Foo()) to MakeUnique<Foo>(). This is because
Foo::Method() may be accessing an internal constructor of Foo.

Cases where MakeUnique<NestedClass>(...) is called within a method of
OuterClass are common but hard to detect automatically, so have been fixed-up
manually.

The only types of manual fix ups applied are:
1) Revert MakeUnique back to WrapUnique
2) Change NULL to nullptr in argument list (MakeUnique cannot forward NULL
   correctly)
3) Add base:: namespace qualifier where missing.

WrapUnique(new Foo) has not been converted to MakeUnique<Foo>() as this might
change behaviour if Foo does not have a user-defined constructor. For example,
WrapUnique(new int) creates an unitialised integer, but MakeUnique<int>()
creates an integer initialised to 0.

git cl format has been been run over the CL. Spot-checking has uncovered no
cases of mis-formatting.

  BUG=637812

Review-Url: https://codereview.chromium.org/2257763002
Cr-Commit-Position: refs/heads/master@{#413387}

Spec: https://drafts.css-houdini.org/css-typed-om/#cssurlimagevalue

BUG=545318

Review-Url: https://codereview.chromium.org/2208283002
Cr-Commit-Position: refs/heads/master@{#413386}

TBR=qyearsley@chromium.org

Review-Url: https://codereview.chromium.org/2268483002
Cr-Commit-Position: refs/heads/master@{#413385}

No behavior changes.

BUG=388681

Review-Url: https://codereview.chromium.org/2246143004
Cr-Commit-Position: refs/heads/master@{#413384}

https://chromium.googlesource.com/skia.git/+log/ce25041865e7..577e012e4058

$ git log ce2504186..577e012e4 --date=short --no-merges --format='%ad %ae %s'
2016-08-21 reed add translate to exercise non-identity ctm performance

CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
TBR=bungeman@google.com

Review-Url: https://codereview.chromium.org/2268463002
Cr-Commit-Position: refs/heads/master@{#413383}

Review-Url: https://codereview.chromium.org/2260813003
Cr-Commit-Position: refs/heads/master@{#413382}

BUG=350660
TESTS=Absence of these strings doesn't break any builds or tools

Review-Url: https://codereview.chromium.org/2251523002
Cr-Commit-Position: refs/heads/master@{#413381}

Commit 702d65e4
updated the underlying data file, but the
generated .gperf file was not re-generated because
I forgot to run net/tools/tld_cleanup on it.

TBR'ing because it's a file derived from the
already reviewed CL.

TBR=pkasting@chromium.org
BUG=626532, 639677

Review-Url: https://codereview.chromium.org/2263923002
Cr-Commit-Position: refs/heads/master@{#413380}

BUG=none

Review-Url: https://codereview.chromium.org/2250263007
Cr-Commit-Position: refs/heads/master@{#413379}

A response provider for DNS failures.

BUG=

Review-Url: https://codereview.chromium.org/2259393002
Cr-Commit-Position: refs/heads/master@{#413378}

BUG=638481

Review-Url: https://codereview.chromium.org/2250313002
Cr-Commit-Position: refs/heads/master@{#413377}

The current viewport resize anchor assumes the FrameView is always the layout
viewport. This is not true in the setRootScroller experiment where an arbitrary
<div> may become the layout viewport in RootFrameViewport.

I've moved the anchoring logic into RootFrameViewport to keep this information
encapsulated and used the layout viewport as reported by the RootFrameViewport
class

BUG=505516

Review-Url: https://codereview.chromium.org/2248433002
Cr-Commit-Position: refs/heads/master@{#413376}

Faking {{cpp_class}} and {{c8_class}} doesn't make sense.
Probably it made sense before the introduction of virtual
ScriptWrappable::wrap().

Checking the existence of window->document() doesn't seem
making sense to me, and CQ tests seem passing without the
check.

BUG=

Review-Url: https://codereview.chromium.org/2268433002
Cr-Commit-Position: refs/heads/master@{#413375}