GitLab

This CL uses ScopedBlockingCall to mark blocking calls in /components/signin.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=droger@chromium.org

Bug: 874080
Change-Id: I8299421165b4f9be1a6f45c8ba4e013853468073
Reviewed-on: https://chromium-review.googlesource.com/1191097Reviewed-by: David Roger <droger@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587568}

When starting the sandbox early, the Mali driver needs to be whitelisted
such that the GPU process can load the graphics libraries.

This also whitelists all the vendor specific paths such that the
libraries can be overwritten by vendors.

Bug: b/112538435
Test: Ran on device and verified GPU process starts up sandboxed.
Change-Id: If02ef2dc0585999bca36b4accd8c847111fe1909
Reviewed-on: https://chromium-review.googlesource.com/1177635
Commit-Queue: Daniel Nicoara <dnicoara@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Reviewed-by: Luke Halliwell <halliwell@chromium.org>
Reviewed-by: Sergey Volk <servolk@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587567}

This is a clean up following this CL:
https://chromium-review.googlesource.com/c/chromium/src/+/1189136

There is no behavior change.

TBR=alexmos@chromium.org

Bug: None
Change-Id: I5c5205738b649578e4734dcd14e326db0d48cccd
Reviewed-on: https://chromium-review.googlesource.com/1196922Reviewed-by: Xida Chen <xidachen@chromium.org>
Commit-Queue: Xida Chen <xidachen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587566}

Change-Id: I10c2205a7ff3a53d836f177256f72a5f1a27bbd2
Reviewed-on: https://chromium-review.googlesource.com/1195839
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587565}

We're getting a lot of gibberish reports from this link.

TBR=dgozman

Change-Id: Ieee93995040d92ad1970c1abfd8c32f061657af4
Reviewed-on: https://chromium-review.googlesource.com/1196385Reviewed-by: Andrey Lushnikov <lushnikov@chromium.org>
Commit-Queue: Andrey Lushnikov <lushnikov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587564}

Implements the WebAppPolicyManager side of uninstalling policy-installed
apps.

WebAppPolicyManager saves a set of the apps it last installed. Then when
a new policy arrives, it compares the saved set with the most recent
set and uninstalls any apps that are not in the latest policy.

We keep this set of last installed apps because if we were to retrieve
the list of installed apps from the ExtensionIdsMap, we could miss some
uninstalls i.e. uninstalling apps that are in the process of being
installed. For example, if we get a new policy with apps A and B. While
we install A, a new policy arrives only with app A. If we were to
retrieve the list of installed apps, we would only see A and would miss
uninstalling B.

Bug: 876174
Change-Id: I8805565ed8e38f2264a27a802b025bd8d4480cc2
Reviewed-on: https://chromium-review.googlesource.com/1195293
Commit-Queue: Giovanni Ortuño Urquidi <ortuno@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587563}

This CL uses ScopedBlockingCall to mark blocking calls in /ios/chrome/app.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=marq@chromium.org

Bug: 874080
Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs
Change-Id: I36b97957e5ad5b73a677a5fc17324c39e5901114
Reviewed-on: https://chromium-review.googlesource.com/1191793Reviewed-by: Mark Cogan <marq@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587562}

A new feature switch is added to enable hiding user data from incognito
notifications.

Bug: 629887
Change-Id: Ia93a2f76d7460249c87b517696948670336ccb2d
Reviewed-on: https://chromium-review.googlesource.com/1196882
Commit-Queue: Ramin Halavati <rhalavati@chromium.org>
Reviewed-by: Martin Šrámek <msramek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587561}

Initializing ShelfWidget::delegate_view_ causes
DelegateView::UpdateOpaqueBackground() to run, which refers back to
ShelfWidget::background_animator_ which hasn't been initialized yet.
This caused MSan failures with a new Clang version, see
https://ci.chromium.org/p/chromium/builders/luci.chromium.try/linux_chromium_chromeos_msan_rel_ng/894

The fix is to initialize background_animator_ first.

Bug: 871418
Change-Id: I1cc4888e9ba5b3f2c5a9166f3e99125c84b3d796
Reviewed-on: https://chromium-review.googlesource.com/1196426Reviewed-by: Stefan Kuhne <skuhne@chromium.org>
Commit-Queue: Hans Wennborg <hans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587560}

In blink-gen-property-trees mode we were only calling update
animations on the top level document, so animation content in
subframes (like iframes) was not being processed.

This adds a simpler reproduction case to point at this behavior too.

R: pdr@chromium.org
Bug: 855688
Cq-Include-Trybots: luci.chromium.try:linux-blink-gen-property-trees;luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ic4707bda5fa67cd5bfd2894040d71ef34d5b0c2c
Reviewed-on: https://chromium-review.googlesource.com/1195887
Commit-Queue: Peter Mayo <petermayo@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587559}

The new API for ignoring input is on the WebContents. Given
that the exposed devtools protocol says that it disables
input events on the page, use the new API.

This removes the last user of the widget-level ignore flag
so it removes the flag as well.

BUG=863582

Change-Id: I2602f1c1d86bd4d73e7877e708d0eb201048ff2d
Reviewed-on: https://chromium-review.googlesource.com/1195833Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587558}

This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/media_galleries/fileapi.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=tzik@chromium.org

Bug: 874080
Change-Id: Ia1551113275376856e8d0492acf7ba359a548daf
Reviewed-on: https://chromium-review.googlesource.com/1191132Reviewed-by: Taiju Tsuiki <tzik@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587557}

- Added error handling as suggested in https://github.com/web-platform-tests/wpt/pull/12162
- changed XHR calls to FetchAPI
- changed async tests to Promise tests
- corrected the existing redirect tests and reported bug: crbug/872285
- removed Same-Site and Cross-Origin XSLT tests as they seemed to fail because loading
    cross origin xslt is not supported "Unsafe attempt to load URL from frame"
    (No idea why they passed before)
- added two test cases for multiple redirects. The idea is that the Sec-Metadata header
    should be "downgraded" to less secure and should carry the value to the end.
    If a cross-origin domain controls a redirect at any point of the redirect chain,
    then the final requests are potentially influenced by the attacker.
    - (Same-Origin -> Cross-Site -> Same-Origin -> Same-Origin) -> site=cross-site
    - (Same-Origin -> Same-Site -> Same-Origin -> Same-Origin) -> site=same-site

Change-Id: I591af1948cc1f16e3b5c44f51020149e43fc2746
Reviewed-on: https://chromium-review.googlesource.com/1193953
Commit-Queue: Maciek Trzos <mtrzos@google.com>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587556}

Bug: 878652
Change-Id: Ibbf18905c3aad4160cb5476542504dc2ef30ba91
Reviewed-on: https://chromium-review.googlesource.com/1195795Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Commit-Queue: Adithya Srinivasan <adithyas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587555}

Bug: 867919
Change-Id: I3804c09877d8b1f44fadcd062a3930e76a4684c4
Reviewed-on: https://chromium-review.googlesource.com/1196445
Commit-Queue: Markus Heintz <markusheintz@chromium.org>
Reviewed-by: vitaliii <vitaliii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587554}

This CL removes the wasm section fuzzer from clusterfuzz. A separate CL
will remove the implementation of these fuzzers from V8.

The wasm section fuzzers used the input bytes as sections in a
WebAssembly module. However, some of these sections have dependencies
on each other which was not considered in the fuzzers. The code which
is tested by these fuzzers is quite stable at the moment, and this
code also gets tested by the v8_wasm_fuzzer and the
v8_wasm_async_fuzzer. That's why I think it's good to retire these
fuzzers now.

R=mmoroz@chromium.org

Change-Id: I2e8584c2d09cf61d42eaeb02364788c3b62204af
Reviewed-on: https://chromium-review.googlesource.com/1194228Reviewed-by: Max Moroz <mmoroz@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587553}

AutofillWalletSyncBridge did not notify changes in PaymentsCustomerData
to WebDataBackend. This was a bug because PersonalDataManager relies on
such notifications.

This CL fixes the bug (and also aligns the behaviour of the bridge to
to other wallet data so that it writes changes only when needed).

Bug: 878697
Change-Id: Id69c0520f192e401380c1eb2dbd55d28f25770b6
Reviewed-on: https://chromium-review.googlesource.com/1196382Reviewed-by: Sebastien Seguin-Gagnon <sebsg@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Commit-Queue: Jan Krcal <jkrcal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587552}

This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/sync_file_system.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=tzik@chromium.org

Bug: 874080
Change-Id: I12d0e731ef9d052129bec273df61cf1ccd670568
Reviewed-on: https://chromium-review.googlesource.com/1191194Reviewed-by: Taiju Tsuiki <tzik@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587551}

This CL uses ScopedBlockingCall to mark blocking calls in /ios/chrome/browser/ui.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=marq@chromium.org

Bug: 874080
Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs
Change-Id: I519b492dc31621ebc2f85fb7952a48e286e21d9f
Reviewed-on: https://chromium-review.googlesource.com/1191532Reviewed-by: Mark Cogan <marq@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587550}

Before this patch, the inspector overlay was updated via two lifecycle hooks:
1) WebViewImpl::MainFrameLayoutUpdated would call PageOverlay::Update
which attached and sized the overlay graphics layer.
2) WebViewImpl::UpdateLifecycle (main frame) and
WebFrameWidgetImpl::UpdateLifecycle (local roots) would update the inspector
overlay after updating the main frame's lifecycle.

This approach is problematic for blink-gen-property-trees which needs all layers
to be attached and painted before layers are collected.

This patch unifies all of the inspector overlay updates into a single call:
WebLocalFrameImpl::UpdateDevToolsOverlays. Because WebLocalFrameImpl owns the
devtools agent, there is no need to have different paint codepaths for the
main frame and local frame, and WebViewImpl no longer needs to participate in
the devtools update at all. The unified devtools overlay update has been put
after the inspected page's paint phase completes but before layers are
collected. With this change, all inspector tests now pass with
blink-gen-property-trees.

Bug: 870422

Cq-Include-Trybots: luci.chromium.try:linux-blink-gen-property-trees;luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ia99c10e374dbaf672dee2b461f3791ddd81a1555
Reviewed-on: https://chromium-review.googlesource.com/1188694
Commit-Queue: Philip Rogers <pdr@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587549}

Also remove author from tests. The commit log is more reliable anyway.

R=foolip@chromium.org

Change-Id: Ibd5a9f7089a8d10bbe77db071b2e1147b05817f4
Reviewed-on: https://chromium-review.googlesource.com/1196429
Commit-Queue: Philip Jägenstedt <foolip@chromium.org>
Reviewed-by: Philip Jägenstedt <foolip@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587548}

ProfileSyncService::IsSyncConfirmationNeeded is used by the UI as a signal
for showing a Sync error (see
AvatarButtonErrorController::SyncErrorObserver::HasSyncError). This is not
appropriate if Sync is running in transport-only mode for a secondary
account (there's nothing to confirm). So this CL changes
IsSyncConfirmationNeeded to return false if the current account isn't
primary. This fixes a wrongly-shown "Sync error" in the avatar button.

Bug: 871221
Change-Id: Icdaa5f7b46acd6eac1a65adc4d49d20296a6f044
Reviewed-on: https://chromium-review.googlesource.com/1196364Reviewed-by: Jan Krcal <jkrcal@chromium.org>
Commit-Queue: Marc Treib <treib@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587547}

This adds support to build Chromium for Fuchsia on macOS. Currently,
this configuration is to be treated as best-effort.

CQ_INCLUDE_TRYBOTS=luci.chromium.try:fuchsia_arm64_cast_audio;luci.chromium.try:fuchsia_x64_cast_audio

Bug: 707030
Test: Locally, builds on mac.
Change-Id: I9e4bde1b7ff658f51586856ae80598c93a2b2e33
Reviewed-on: https://chromium-review.googlesource.com/1185020Reviewed-by: John Budorick <jbudorick@chromium.org>
Reviewed-by: Kevin Marshall <kmarshall@chromium.org>
Reviewed-by: Wez <wez@chromium.org>
Commit-Queue: Fabrice de Gans-Riberi <fdegans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587546}

Bug: 853221
Change-Id: I0ffe2062ec61d281ac141ee73e9296b323c3f71c
Reviewed-on: https://chromium-review.googlesource.com/1196545
Commit-Queue: Michael van Ouwerkerk <mvanouwerkerk@chromium.org>
Commit-Queue: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587545}

Move offset member from NGPhysicalFragment to the new NGLink class thus
making physical fragments truly immutable and allowing us to remove the
CloneWithoutOffset method. This goes back to the design outlined in the
original design doc, with the distinction that NGLinks are data members
as opposed to pointers, avoiding the extra indirection which caused the
removal of NGLinks early on.

This change also marks all pointers to NGPhysicalFragment, and friends,
as const.

Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng;luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ic4a90b9cb795beb0222212a3bd42d4d812688243
Reviewed-on: https://chromium-review.googlesource.com/1194022
Commit-Queue: Emil A Eklund <eae@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587544}

This CL may cause a small binary size increase, roughly proportional
to how long it's been since our last AFDO profile roll. For larger
increases (around or exceeding 100KB), please file a bug against
gbiv@chromium.org. Additional context: https://crbug.com/805539

The AutoRoll server is located here: https://autoroll.skia.org/r/afdo-chromium-autoroll

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.


TBR=gbiv@chromium.org

Change-Id: I0b44e88a6953da7dc93664935e482ce8b9489918
Reviewed-on: https://chromium-review.googlesource.com/1196762
Commit-Queue: afdo-chromium-autoroll <afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Reviewed-by: afdo-chromium-autoroll <afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#587543}

This is a roll-back to V8 7.0.276.3. This is the most stable candidate out of the latest Canaries.

If this commit results in failures in Blink please contact the Blink sheriff. They may need to make changes to Blink because of the roll-back.

When in doubt please try to contact the committer and reviewers of this CL before reverting it.

R=jkummerow@chromium.org
TBR=machenbach@chromium.org

Change-Id: I11922beb5164e7e07092eca778218fab5960c588
Reviewed-on: https://chromium-review.googlesource.com/1196404
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587542}

I missed a call to new function SelectionAtEnd(), and new function
could be implemented in a manner more consistent with the rest of
the file.

Bug: 868511
Change-Id: Ic5cfaba9ad4413ba5a9f7b311468ba11cd8037b6
Reviewed-on: https://chromium-review.googlesource.com/1195642
Commit-Queue: Kevin Bailey <krb@chromium.org>
Reviewed-by: Justin Donnelly <jdonnelly@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587541}

This CL disables:
org.chromium.chrome.browser.vr.jsdialog.VrBrowserJavaScriptModalDialogTest#testConfirmModalDialog
org.chromium.chrome.browser.vr.jsdialog.VrBrowserJavaScriptModalDialogTest#testPromptModalDialog
org.chromium.chrome.browser.vr.jsdialog.VrBrowserJavaScriptModalDialogTest#testAlertModalDialog

These tests are constantly failing on Nougat Phone Tester.

TBR: bsheedy@chromium.org
Bug: 879130
Change-Id: I7e9677764274d33909907ed28cfed6a6aa88e2d9
Reviewed-on: https://chromium-review.googlesource.com/1196446Reviewed-by: Alexandr Ilin <alexilin@chromium.org>
Commit-Queue: Alexandr Ilin <alexilin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587540}

This removes all the fields which can be passed in via. PositionFloat(s)
There should be no functionality change.

Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: I1b05c0f58bb2aa1ba17374f6600deda56912408c
Bug: 635619
Reviewed-on: https://chromium-review.googlesource.com/1196428Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587539}

The error message when trying to prepare a device build on iOS with
an expired code signing certificate was confusing, since it mentioned
a code signing identity "not being specified". This might (as I can
attest) lead a user to believe that some configuration had been changed.

I suspect the most common way to hit this error is to either have only
expired certs, or no certs at all, so this CL clarifies the error
message for those cases.

Change-Id: Ia72a7a40767b516ca47bdb219d078ea7f9a96035
Reviewed-on: https://chromium-review.googlesource.com/1188463Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Commit-Queue: Mark Cogan <marq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587538}

When producing a CSSStyleValue from a string for a registered custom
property, parse the value according to the syntax instead of always
creating a CSSUnparsedValue.

Note that <color> and <url> are still not supported, because
CSSUnsupportedProperty does not work properly for registered custom
properties (yet).

R=futhark@chromium.org

Bug: 641877
Change-Id: I806eb5b0c5112956e34457808791367423587c76
Reviewed-on: https://chromium-review.googlesource.com/1177755
Commit-Queue: Anders Ruud <andruud@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587537}

PersonalDataManager now checks the sync feature state in its
OnStateChanged method, and if the sync the feature is not on, it will
use the ephemeral account storage, instead of the persistent store.

Note that we previously wanted to use the USS bridge as a source of this
information, instead of observing the sync service directly. However,
using that approach means that all updates need to switch from the db
thread to the main thread. That could mean that while an account switch
update is underway from the bridge to PDM, the PDM is still committing
changes to the database for the previous account.

A cleaner fix may be to do the entire switch on the database thread, at
which point PDM only needs to be notified that the storage changed.

Bug: 878858
Change-Id: I6581eb45f7e3510142142e25ede5e8b296fcaf9d
Reviewed-on: https://chromium-review.googlesource.com/1194126
Commit-Queue: Sebastien Seguin-Gagnon <sebsg@chromium.org>
Reviewed-by: Sebastien Seguin-Gagnon <sebsg@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587536}

This test is broken; every browser fails it in the same way, and the
thing it actually intends to cover is addressed by the other six tests
in https://wpt.fyi/results/cookies/secure.

Change-Id: Ib7b8534b35ae16490f2cf71e67936b5636e33fbe
Reviewed-on: https://chromium-review.googlesource.com/1196544Reviewed-by: Friedrich Horschig [CEST] <fhorschig@chromium.org>
Commit-Queue: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587535}

Added TrustedTypes.getExposedPolicy(name) and bool exposed in TrustedTypePolicyOptions
Added test
Changed Vector of created policies into Map of created policies

Bug: 739170
Change-Id: Ib5fe7a14ddadb88e3de70ee55f2783b9d10a01b5
Reviewed-on: https://chromium-review.googlesource.com/1193869
Commit-Queue: Orsolya Bernadett Batiz <orsibatiz@google.com>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587534}

We want to know on the sync server whether full sync is enabled or not
so that we can separate the different types of users in dashboards and
monitoring, and so that we can decide to hit the new payments backend
for transport-only users.

We're adding this boolean to ClientStatus, because we're already sending
that on all ClientToServerRequest messages.

Whenever we switch between full sync and transport-only sync, the sync
engine gets reconfigured. This CL adds a boolean to that configure call,
which gets forwarded to the sync_cycle_context. The syncer_proto_util.cc
picks it up from there, together with other information that was already
part of ClientStatus.

Change-Id: Ie9283e83c2fa92c1d1467fcce59057ffced577d2
Bug: 878857
Reviewed-on: https://chromium-review.googlesource.com/1193878
Commit-Queue: Florian Uunk <feuunk@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587533}

|scope_url| and |script_url| are verified in RegisterServiceWorker().


Change-Id: I8f397298f266006b8be57f1c6aa01f445e21c646
Reviewed-on: https://chromium-review.googlesource.com/1177441Reviewed-by: Peter Beverloo <peter@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Makoto Shimazu <shimazu@chromium.org>
Commit-Queue: Han Leon <leon.han@intel.com>
Cr-Commit-Position: refs/heads/master@{#587532}

This change adds a skeleton for a fake implementation of IDeviceWatcher.
No functionality is added yet, this will be done in a follow-up CL.

Bug: 821766
Change-Id: If51716beac17543975d42632b17c8af7f269ac5c
Reviewed-on: https://chromium-review.googlesource.com/1193890Reviewed-by: Giovanni Ortuño Urquidi <ortuno@chromium.org>
Commit-Queue: Jan Wilken Dörrie <jdoerrie@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587531}

The test pushes a policy and then waits for the extension to be
installed. Installing the extension requires loading a website, waiting
for a service worker, parsing the website and finally installing the
app. This takes time but, on Windows, it takes so long that the test
times out.

We have extensive unit tests for all portions of the flow so we could
delete the test and wouldn't loose any coverage, but we just disable
it on Windows since it's the only platforms where the test times out.

Bug: 878797
Change-Id: I12a59e959d8e8dde12c67fac5cb1ce72636bd6ce
Reviewed-on: https://chromium-review.googlesource.com/1195306
Commit-Queue: Giovanni Ortuño Urquidi <ortuno@chromium.org>
Reviewed-by: Pavol Marko <pmarko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587530}

When the CustomTabBottomBarDelegate is notified of the Contextual
Search Bar being triggered, it hides the Bottom Bar (setting its alpha
to zero). However, it is still present in the View Hierarchy (and will
be above the Contextual Search Bar) so it will intercept touches.

This CL sets the Bottom Bar View Visibility to GONE so touches reach
the Contextual Search Bar.

Bug: 875458
Change-Id: I9491158ab540b0637a8828eabca9fb56a9a54979
Reviewed-on: https://chromium-review.googlesource.com/1196602
Commit-Queue: Peter Conn <peconn@chromium.org>
Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Reviewed-by: Michael van Ouwerkerk <mvanouwerkerk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587529}