GitLab

Android framework does not seem to release ResultReceiver passed in
InputMethodManager#showSoftInput() after use. As a result, WebView
will not be garbage collected after it's removed, if keyboard shows up
on the screen once.

ResultReceiver cannot be avoided since we want to scroll to the editable
node only after input method window shows up.

This is a fix to weak-reference CVC object (and thus WebView as well) from
ResultReceiver. Unfortunately, ResultReceiver will still be leaked,
but the leak can be significantly reduced.

A test is added to AwContentsGarbageCollectionTest to test that references
to WebView can be removed even when showSoftInput() is called before
garbage collection.

Also, I've manually tested that the new test can catch the memory leak
issue when we strong-reference CVC.

BUG=595613

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

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

I don't know why http://crrev.com/293913 has moved these flags outside
if(is_android),
but the corresponding GYP code (build/config.gypi) is still applying
these flags only to Android.

BUG=433082

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

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

TBR=sky@chromium.org

BUG=

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

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

TBR=hashimoto@chromium.org

Original CL:
Create hard links in file migration if necessary.

BUG=533750
TEST=unit_tests:FileCacheTest.MigrateCacheFiles

Committed: https://crrev.com/c5c297d58dc4d90423ed222f5bc7c06a84156324
Cr-Commit-Position: refs/heads/master@{#375836}

patch from issue 1698793003 at patchset 20001 (http://crrev.com/1698793003#ps20001)

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

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

Several of them pass, so only blacklist the ones that actually fail.

BUG=318978

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

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

Summary of changes available at:
https://chromium.googlesource.com/v8/v8/+log/79f4376c..5f69d999

Please follow these instructions for assigning/CC'ing issues:
https://github.com/v8/v8/wiki/Triaging%20issues

Please close rolling in case of a roll revert:
https://v8-roll.appspot.com/
This only works with a Google account.

TBR=hablich@chromium.org,machenbach@chromium.org,yangguo@chromium.org,vogelheim@chromium.org

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

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

BUG=563721

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

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

BUG=547073

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

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

Adds per-file BUILD.gn=* to chrome/test/OWNERS for adds/renames

BUG=NONE

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

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

1) The follow cursor window should NOT be auto shown when focusing to an
input field.
2) The normal window should NOT show the extension's name on the title
bar.

BUG=517773

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

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

Rlz already passed on Windows.

GPU had a bunch of errors which are fixed here by adding the necessary dependencies and in a few cases removing unnecessary headers.

gpu_memory_buffer_manager.h included stuff from ui/gfx but adding a dependency on //ui/gfx pulls Skia into the NaCl IRT (and mesa into Android) and everything goes badly. The GPU memory buffer stuff turns out to be separable from gfx so I created a new target for this.

The same is true for ui/gfx/native_widget_types.h (this is just some enums in a .h file) so I made a separate target for this as well.

In support of the Skia-in-NaCl problem, I added an assert_no_deps annotation on the NaCl IRT so people will get an error if they accidentally add this Skia dependency (this has come up before, it's easy to add a //ui/gfx dependency in the wrong place). It also fixes the Skia build in NaCl by updating the condition for extra warning to match build config. Without this update, the assert_no_deps won't be reached before an error running the skia build file, which won't make any sense in the context of addnig a random dependency.

Minor cleanup of the use_libpci conditionals that was exposed by this (the define that controlled the header didn't exactly match the corresponding dependencies).

CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel
TBR=jschuh (gpu/ipc build changes)

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

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

Previously the code had a check that we use exactly the same WTF::String object
for GetSerializedSize_ and Serialize_ call. However, because WTF::String is
ref-counted, we may end up using different WTF::String objects referring to the
same contents. That may happen, e.g., when moving WTF::String to a different
container.

This CL changes the sanity check to verify that the size of WTF::String remains
unchanged.

BUG=595791

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

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

This is a more faithful implementation of more_rbsp_data().

There are two ways this could happen despite being invalid:
  (1) H264Parser does not strip trailing null bytes from NAL units as it
      should. This is generally not a problem because the conversion to
      Annex B won't introduce them either.
  (2) There could be trailing null bytes before the Annex B conversion.
      This isn't valid (at least for PPS NAL units), but the referenced
      bug includes a sample where the PPS in the avcC record includes a
      trailing null byte.

BUG=479229

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

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

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

BUG=595951
TBR=reed@chromium.org

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

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

For multipart responses, in the first ResourceLoader::didFinishLoadingOnePart(),
(1) the ResourceLoader is moved from |m_loaders| to |m_nonBlockingLoaders|
    in ResourceFetcher::subresourceLoaderFinishedLoadingOnePart(), and
(2) it is removed from |m_nonBlockingLoaders| in
    ResourceFetcher::willTerminateResourceLoader() called in didFinishLoading().
Therefore, if we call window.stop() just after multipart <img>'s onload event,
we cannot stop loading of the multipart response because it is no longer in
|m_loaders| nor |m_nonBlockingLoaders|.

However, in the second didFinishLoadingOnePart(),
(3) In subresourceLoaderFinishedLoadingOnePart(),
    the ResourceLoader is added again to |m_nonBlockingLoaders|, and
(4) We don't call didFinishLoading()/willTerminateResourceLoader().
Therefore, we can stop loading of the image after that by window.stop().

This CL makes the ResourceLoader to be kept in |m_nonBlockingLoaders| after (1)
and to be remove from |m_nonBlockingLoaders| when
ResourceLoader::didFinishLoading() is called.
This CL enables to stop loading of multipart responses at any time, and also
enables https://codereview.chromium.org/1756953002/ to stop dispatching
didFinishLoadingOnePart() for each part without affecting window.stop()
behavior on multipart responses.

BUG=570608

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

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

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState, newPaintInvalidationContainer);
    PaintInvalidationState childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(newPaintInvalidationState);
  }

This is like how PaintPropertyTreeBuilderContexts are inherited and updated:
copy from parent first, then update in multiple steps. We may use the state
for different purposes after different steps.

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded()
  by letting paintInvalidationState parameter contain the correct
  paintInvalidationContainer for the current object;
- We move the logic to find the paintInvalidationContainer from LayoutObjects
  into PaintInvalidationState which knows more information;
- This is a preparation for the next step works to avoid some
  ForcedHorriblySlowRectMappings because we need to track correct
  paintInvalidationContainer (for normal objects and stacked objects) in
  PaintInvalidationState, instead of being passed in from
  LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199

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

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

BUG=590825
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel

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

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

PAGE_TRANSITION_AUTO_TOPLEVEL is used to indicate a wide variety of
transitions. For example, New page transitions
(https://codereview.chromium.org/1397673004), EmbedContentViewActivity.

BUG=595909

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

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

and move the 'masters' section to the top of the file, since that seems
like it's probably the more common starting point.

R=estaab@chromium.org

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

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

Mus server might prevent some windows from becoming system modals. In
this case, SetModal would fail and the client needs to handle the
failure and revert the modality set locally for the window.

BUG=548402

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

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

The DrMemory update process only runs when it thinks that it needs to
but its heuristic is not accurate. A better thing to do is to always
update.

This change also adds setlocal so that environment variables don't
leak outside. This may also help with making this script more robust
in the future, once it has been in place for long enough for all
machines affected by the environment variable leakage to have rebooted.

BUG=595867
R=scottmg@chromium.org

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

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

BUG=584819

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

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

On Windows 10 in particular, active and inactive windows may have very different frame colors, and the incognito icon for one may be invisible on the other.

We should probably also consider toggling the TOOLBAR_TOP_SEPARATOR_COLOR.  That also makes me wonder if this is the right way to do this; perhaps both these should have _INACTIVE colors and whatever draws the frame in the correct color should draw these as well.

It's also not clear to me whether the nonclient view really needs the widget destruction overload (as noted in a comment).

BUG=none
TEST=Run Chrome on Windows 10 with window titlebars set to a dark color.  Open an incognito window.  Toggle the window between active and inactive and check that the incognito icon toggles between white and grey.

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

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

BUG=595789

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

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

BUG=298951

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

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

This patch moves the routines for consuming <color> and <position> out
of CSSPropertyParser.cpp and into CSSPropertyParserHelpers. We expect
that we'll require these routines for various Houdini APIs.

BUG=499780

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

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

Make parsing of <transform> more strict by checking
that something valid follows after a comma.

BUG=593321

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

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

BUG=

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

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

This feature will (hopefully) improve the performance of Syzyasan builds.

BUG=

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

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

MojoAudioDecoder is the client side part of the decoder
that runs in the renderer process.

This CL connects it to the remote service and propagates
the media task runner to it.

BUG=542910

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

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

The settings breadcrumb feature is being removed.
That location on the title bar will become the search
within settings.  This CL removes the breadcrumb
code.

BUG=589630

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

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

We use fixed color format (kN32_SkColorType) to decode images. Since the default
preferred format is 16-bit color on low-end devices, we can reduce memory
footprint by storing decoded image in 16-bit color format when we use the
default settings for the preferred format. This CL makes
SoftwareImageDecodeController allocate memory based on the preferred format.

I ran memory.blink_memory_mobile 20 times. The results can be found at [1].
I removed SimulateMemoryPressureNotification() so that I can observe memory usage in
common patterns (still, memory pressure notifications would be sent if memory
usage is high). According to the results, we could reduce ~40% discardable
memory on average.

Note that Blink still uses fixed 32-bit color for decoding. This means that
skia/cc will convert decoded images when we store decoded image in 16-bit color.
We might want to make Blink's decoding format configurable in the future.

[1] https://drive.google.com/file/d/0B6NYyLPujP4TaWItc3lsZXR6TTg/view?usp=sharing

BUG=519146
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

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

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

BUG=593910

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

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

This contains the last fixes necessary for VS2015 compatibility.

TBR=siggi@chromium.org
BUG=

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

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

Rather than keeping it around forever, we should kill it. Now that the user shell is acting as the login broker for apps run for that user, it's not necessary to keep login too. This simplifies the login app a bit.

BUG=

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

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

BUG=589194
TEST=Put too many icons on shelf, move shelf to left, click chevron to
open overflow bubble.  Observe that bubble doesn't overlap shelf.

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

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

This CL extends the ChromeAnimation class to notify
Animatable interfaces that a particular property
animation has finished.

BUG=

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

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

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

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

On OSX, NodeChannel::ShutDown() calls into
NodeController::GetMachPortRelay() which acquires |parent_lock_| and
deadlocks due to a recursuve lock acquisition.

BUG=582468

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

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