GitLab

PlatformKeysService now supports persisting whether an extension is allowed to sign data with a key an unlimited number of times.

Currently, these permissions are only granted in the accompanying browser test and not in production, because UI is still missing.

BUG=450167

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

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

Summary of changes available at:
https://chromium.googlesource.com/skia/+log/cd87c51..f421ec6

CQ_EXTRA_TRYBOTS=tryserver.blink:linux_blink_rel,linux_blink_dbg
TBR=scroggo@google.com

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

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

Also add HttpStreamParser unit tests for 0 byte final chunks.

BUG=405678

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

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

BUG=402344, 458695
TEST=manually

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

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

BUG=459695
TEST=manually tested

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

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

BUG=459647

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

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

Add a Preference to allow WebRTC only bind to "any address" (all 0s). This way, no local IP or private ISP's public IP leaked when VPN is the default route.

Add webrtc.multiple_routes_disabled preference to RendererPreferences. Default is false. When set to true, a new port allocator flag will be passed to P2PPortAllocator which will have WebRTC only bind to all 0s (any address) IP and the default route will be used as how chrome/http is routed.

Each rtc_peer_connection_handler is associated with a WebFrame and it leads to a webview and then the mapping RenderViewImpl which has RendererPreferences that we care.

The corresponding webrtc change is at https://webrtc-codereview.appspot.com/39129004

BUG=333752

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

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

When reloading a page whose url leads to an error page, a different
pathway is taken in NavigationControllerImpl. We must be careful to
check for unreachable urls in
NavigationControllerImpl::RendererDidNavigateToExistingPage() in this
case, and mark them as error pages.

BUG=458036

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

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

Everything seems to link now.

Tested with the following command lines:

$ gn gen out-gn
$ ninja -C out-gn/ jingle_unittests
$ out-gn/jingle_unittests

This fixes one more TODO(GYP).

BUG=None
TEST=see above
R=sergeyu@chromium.org

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

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

BUG=459429
TBR=jyasskin@chromium.org

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

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

Fix one misplaced header include and use PASSWORD_MANAGER_ENABLE_SYNC
macro to properly guard the other place of sync usage to fix a linking
issue when PASSWORD_MANAGER_ENABLE_SYNC is disabled.

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

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

This was disabled on Windows because:

 - http://crrev.com/274071 made it such that it was asynchronous via the renderer (as only
the process itself can set itself in background mode on Windows).

 - And then this was removed for Windows as part of issue 381820 as true background mode on
Windows was achieved by having the renderer itself change its process priority (which
doesn't work as the unbackgrounding request can be stuck behind other priority tasks
running in background mode).

Also, the test for this was disabled in between (see issue 394368) -- the asynchronicity
introduced in r274071 probably causing the flakes.

Overall there is no need to have the renderer enter PROCESS_MODE_BACKGROUND_BEGIN itself,
IDLE_PRIORITY_CLASS should be sufficient as its the same as far as CPU priority is
concerned and IO is irrelevant in the renderers.

Thus we can get background mode for hidden renderers without running into issue 381820.

Experiment with IDLE_PRIORITY_CLASS/BELOW_NORMAL_PRIORITY_CLASS vs the status quo.

Watching the relevant perf bots (tab_switching.top_10 -> MPArch.RWH_TabSwitchPaintDuration)
and UMA metrics MPArch.RWH_TabSwitchPaintDuration which shouldn't regress.
And others (e.g., SessionRestore related) which will hopefully improve.

Enable the experiment by default in the absence of Finch to get perf waterfall coverage.

The experiment will be called "BackgroundRendererProcesses" and have 4 groups:
 ["Disallow", "AllowBelowNormalFromBrowser",
  "AllowIdleFromBrowser", "AllowBackgroundModeFromRenderer"]

It will be a per-session (rather than per-profile) experiment, randomly assigning a user
to a group every new Chrome session.

BUG=394368, 458594

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

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

WebControllerProvider provides URL-loading and JavaScript injection with
optional dialog suppression.

BUG=459678,429756

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

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

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

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

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

SkImageGenerator is in the process of adding an enum return value to
onGetPixels. For staging, it has been replaced with onGetPixelsEnum.
(See https://codereview.chromium.org/919693002/)

Implement the new API. A follow up change will rename onGetPixelsEnum
to onGetPixels.

No need to check for null pixels; onGetPixels is only called by
getPixels which has already done the check.

R=reed@google.com,fmalita@chromium.org

BUG=skia:3257

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

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

password_manager_util_mac uses hardcoded "com.google.Chrome", since rest of the
code is pretty generic we would like to use this file directly in Opera, however
we want to use something like com.operasoftware.Opera, since that information is
can already be retrieved from [base::mac::MainBundle() bundleIdentifier] we can
just use it and append ".show-passwords".

BUG=447344

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

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

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

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

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

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

Summary of changes available at:
https://chromium.googlesource.com/skia/+log/c119981..cd87c51

CQ_EXTRA_TRYBOTS=tryserver.blink:linux_blink_rel,linux_blink_dbg
TBR=scroggo@google.com

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

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

Build bot recipes have been upgraded to explicitly request the provisioning
options they need.

At this point it should be safe to remove the code that guessed the required
configuration from the bot name.

BUG=450984

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

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

BUG=459326
TEST=open a folder which contains transparent image and confirm that generic thumbnail is not visible behind thumbnail.

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

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

BUG=459165
TEST=Trigger renaming on list and grid view, and check the icons.

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

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

This is a cleanup and should change no functionality. See the issue for detail.

BUG=442214
TEST=browser_test passes
R=fukino@chromium.org

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

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

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}