GitLab

BUG=402344
TEST=compared with the design spec manually.

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

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

- Update filetype icons.
- Use PNG images as icons in directory tree, instead of SVG images.

BUG=402344,455158
TEST=manually checked.

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

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

Summary of changes available at:
https://chromium.googlesource.com/chromium/blink/+log/fa54650..a1303a8

TBR=kbr@chromium.org,yosin@chromium.org

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

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

Android binaries were relying on -Wl,--exclude-libs=ALL to prevent
unnecessary symbols from being exported in the final shared libraries
built in Chromium, however several changes were submitted that actually
disabled this linker flag in virtually all binaries, and thus it was not
really being used and many symbols were exported by mistake.

Remove --exclude-libs=ALL entirely from the Android build, as well as
all the places which were previously having to unset it, and instead
exclude the specific libraries which incorporate visible symbols that we
don't want: the NDK libraries which we statically link into the binary,
and a number of components of chromium which contain assembly code which
has not yet been fixed to set symbol visibilities correctly.

This reduces the number of exported symbols in the shared libraries to
only the ones we intended to export, which saves ~120KB binary size.

The GN build does not build the same set of things as static libraries,
so the list is slightly different there and several more symbols are
left in the final binaries which shouldn't be there, but are not pulled
in via a static library and so no --exclude-libs flag will ever fix it;
the symbol visibilities will need to be fixed at source.

BUG=448386
TBR=ben@chromium.org

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

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

Existing code has assumed a trace function call delegating to a base class has
the same name as the name of the function where the trace call is written (e.g.
Base::trace(visitor) in Derived::trace(), and Base::traceAfterDispatch(visitor)
in Derived::traceAfterDispatch()).

After the introduction of traceImpl(), however, this is no longer true. This
patch fixes this issue.

BUG=none
R=kouhei@chromium.org
CC=zerny@chromium.org, oilpan-reviews@chromium.org

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

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

Summary of changes available at:
https://chromium.googlesource.com/v8/v8/+log/209cf09a..b696572d

TBR=machenbach@chromium.org

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

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

BUG=452613,456193

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

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

This is because the hotword stream requires that it be closed and
re-opened after triggering and currently, the only way to do this is to
shutdown the detector since its stream cannot be replaced.

BUG=403138

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

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

BUG=400674
TBR=isherman@chromium.org

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

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

Directory rescan sometimes uses up IO and blocks other IOs which are necessary
for updating the top-left breadcrumb. While this CL does not solve the real
cause of the issue, this CL mitigates the problem by dispatching event earlier.

BUG=459864
TEST=manually tested as described in the issue

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

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

Summary of changes available at:
https://chromium.googlesource.com/chromium/blink/+log/37a8479..fa54650

TBR=kbr@chromium.org,yosin@chromium.org

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

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

BUG=410766
TEST=None

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

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

BUG=459872

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

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

When the affiliated invalidation service provider, it should:
1) unregister itself as an observer of various objects
2) tell consumers to stop using the current invalidation service
3) destroy the device-global invalidation service, if any

Steps 2 and 3 were swapped. This meant that if the device-global
invalidation service happened to be in use, it would be destroyed
without giving consumers a chance to remove their handlers from it.

BUG=455504
TEST=None

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

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

This is because on Windows, we close some handles opened by Windows DLLs to prevent them from leaking into sandboxed processes, and this can cause INVALID_HANDLE_EXCEPTION to be raised if "bad handle detection" gflag is enabled, as it currently is by default on Windows 10.

Only replace File and Event handles at the moment, as File handles are the ones causing the issues on Windows 10.

BUG=452613
TEST=sbox_integration_tests
TEST=Run Chrome on Windows 10 with crash reporting enabled, and check there are no crashes listed in chrome://crashes

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

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

Audio player refers 'media.title' and 'media.artist' properties that are fetched
by ContentMetadataProvider. Because these properties are not related with
thumbnail, the CL moves ContentMetadataProvider to FileSystemMetadata for
preparing to use new metadata class in Audio player.

BUG=410766
TEST=FileManagerJsTest.FileSystemMetadata

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

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

BUG=none
TEST=none
R=rogerta@chromium.org, sky@chromium.org

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

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

The world isn't quite ready for them....

BUG=459504
TBR=benwells@chromium.org,thestig@chromium.org
Original patch from benwells; reviewed in http://crrev.com/938603002

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

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

If an extension printer does not declare support for PDF in its
capabilities, convert print data to PWG raster before dispatching
print request to the extension.

BUG=408772

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

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

Extensions with background pages (e.g. Google Cast) currently have a
shorter code path when showing an extension popup that can cause the
renderer to ask for screen metrics before the hosting NSView is added to
the view hierarchy. Since the NSWindow is nil in this case, screen
metrics for the primary screen are used, and they may be the incorrect
screen for the popup.

On non-Mac, toolkit-views platforms get around this problem by deferring
creation until View::ViewHierarchyChanged is triggered. However, there
is no NSView apart from the render view on the extension-side on Mac, so
to do the same we'd either need to add one (and keep it sized
appropriately), or modify the WebContents view itself to override
[NSView viewDid/WillMoveToSuperview] and feed it through to embedders.

Instead, this CL tweaks the ExtensionPopupController initialization to
always create the popup NSWindow (initially hidden), before creating the
ExtensionViewHost.

BUG=324748, 305620
TEST=On a retina mac, plug in a (non-retina) external monitor, move
Chrome there, and open the Chromecast dialog. It should look "nice" (not
as nice as the retina screen, but consistent with other text in Chrome).
See http://crbug.com/324748#c41

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

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

It may not be readily apparent how to the fix the error otherwise.

BUG=457097

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

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

Some users of the checkbox reported not expecting the SW to pause on startup.

BUG=455708

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

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

Add a test which covers the case of exporting all the keys
and installing them back to fully bootstrap another cryptographer.

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

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

BUG=459326
TEST=Manually tested as described in the issue.

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

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

This CL makes the app list search results use the short names of apps
to be consistent with the name shown in the apps grid view.

BUG=456961

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

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

BUG=459556
TBR=jyasskin@chromium.org
NOTRY=true

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

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

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

Placeholder strings should be sentence case (even when use_titlecase is
enabled). This fixes the search box placeholder text which was missing
"or type URL" in titlecase environments (because I forgot to update that
version of the string).

Also fixed some minor comma placement in some "Ok Google" strings.

BUG=459537
TBR=cpu@chromium.org

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

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

BUG=None
TEST=None
TBR=smckay@chromium.org

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

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

While looking through the code, found some places where we are using pointers
even though their values can be null. This patch adds null checks so as not to
have any crashes due to pointer value being null.

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

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

To handle device connection status, MidiManager and MidiMessageFilter
hold all devices as a list. These lists are modified by event
notifications that are delivered asynchronously.

They do not remove disconnected devices, but just mark as disconnected.
This is useful when JavaScript has a reference to a device
that got disconnected. The reference can be availalbe if the device
gets connected again.

BUG=422333
TEST=media_unittests

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

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

Revert of Now that the cq runs tests on rel, the compile-only bug should be dbg. (patchset #1 id:1 of https://codereview.chromium.org/937853002/)

Reason for revert:
Too many red builds on the dbg not, need to investigate tomorrow. Also, it does a static build for some reason.

Original issue's description:
> Now that the cq runs tests on rel, the compile-only bug should be dbg.
>
> Depends on https://codereview.chromium.org/913223007
>
> BUG=456396
> TBR=sergiyb@chromium.org
>
> Committed: https://crrev.com/3d0efdf9afa56e55b8d8c62fd883a1992f35cf45
> Cr-Commit-Position: refs/heads/master@{#316998}

TBR=jam@chromium.org,sergiyb@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=456396

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

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

Depends on https://codereview.chromium.org/913223007

BUG=456396
TBR=sergiyb@chromium.org

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

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

Revert of Re-land: base: Enable browser-wide discardable memory on Linux, CrOS and Windows. (patchset #1 id:1 of https://codereview.chromium.org/793443003/)

Reason for revert:
Caused random crashes on GPU bots with this assertion failure:
WebglConformance.conformance_ogles_GL_log_log_001_to_008:
Error installing extension 'v8/gc'.
[3060:3996:0218/193241:FATAL:discardable_shared_memory_heap.cc(205)] Check failed: spans_.find(span->start_ + span->length_ - 1) != spans_.end().

Original issue's description:
> Re-land: base: Enable browser-wide discardable memory on Linux, CrOS and Windows.
>
> This makes SHMEM implementation of discardable memory preferred
> over EMULATED implementation. This effectively makes SHMEM the
> implementation used by default on Linux, CrOS and Windows.
>
> SHMEM implementation of discardable memory gives the browser
> process control over the total amount of discardable memory used
> and allows us to enforce a global limit of 512MB across all
> renderers.
>
> BUG=429415,429416
>
> Committed: https://crrev.com/2f7a8e80b83aa581aa6de86117a692093d16c217
> Cr-Commit-Position: refs/heads/master@{#316977}

TBR=avi@chromium.org,danakj@chromium.org,reveman@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=429415,429416

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

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

BUG=None
TEST=None
TBR=kenobi@chromium.org

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

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

BUG=430635

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

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

Now that volumes other than Google Drive can be expanded in the directory tree,
there is a case that subdirectories are queried befor the displayroot of volume is
obtained. In this case, we should skip updating subdirectories. After the displayroot
is obtained, updateSubDirectories will be called.

BUG=459534
TEST=manually check the steps described in the issue.

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

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

2) Don't show details header panel once user has completed import.
3) Introduce a local storage wrapper and make all existing importer uses of chrome.storage.local use this...much shorter and safer.
4) Auto-hide details panel when user clicks out.
5) Fix jank on the panel transition (and switch to vertical swoosh).

BUG=420680
TEST=browser_test: FileManagerJsTest.*

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

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

Undo and redo are mapped in a similar way to cut/copy/paste on Mac, via
the mainMenu's performKeyEquivalent, and the Cocoa responder chain.

This CL adds responders for undo: and redo:

Single-character editing commands were not being merged into a single
edit. For example, typing {'c', 'a', 't', Cmd+Z} would only undo the 't'
not the entire 'cat'. This CL fixes by detecting single-character
inserts in response to a keyDown event.

Then, for "redo", some of the textfield unittests would send both Ctrl+Y
and Ctrl+Shift+Z. Cmd+Y for undo isn't supported on Mac (it's mapped to
History -> Show Full History). So a wrapper is added that just sends
Cmd+Shfit+Z again.

Gets the following tests passing:
     TextfieldTest.DragAndDrop_ToTheLeft
     TextfieldTest.DragAndDrop_ToTheRight
     TextfieldTest.UndoRedoTest

BUG=454353

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

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

Previously Files.app uses @typedef for expressing metadata item.
The CL introduces new class instead, for better compiler check.

BUG=410766
TEST=None

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

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