Comments

[Duet] Make BottomToolbarCoordinator#getMenuButtonWrapper() always return browsing mode button
The browsing mode menu button is the one that has all of the changing
state (badge and animation) so it should be the one returned in the
getMenuButtonWrapper() method. The top toolbar already always returns
the browsing mode menu button.
Bug: 933529
Change-Id: I84221e30652d0c2c082e7f89b39d14ab14f073f9
Reviewed-on: https://chromium-review.googlesource.com/c/1478098
Commit-Queue: Pedro Amaral <amaralp@chromium.org>
Reviewed-by: Theresa <twellington@chromium.org>
Cr-Commit-Position: refs/heads/master@{#633564}

Use base::BindOnce for PostTask callbacks.

Comments

Use base::BindOnce for PostTask callbacks.
TaskRunner::PostTask() takes a OnceCallback. Replace usage of
base::Bind(), which produces a RepeatingCallback, with base::BindOnce()
when the callback is created as a temporary inside of PostTask(). The
following regex was used to find instances that could be replaced:
(Post(?:Delayed)?Task)\((?:\n\s*)?FROM_HERE,(?:\n)?\s*base::Bind\(
Also replace any usage of base::Passed(&var) with std::move(var) for
variables passed to base::BindOnce(). base::Passed() isn't needed for
move-only types with OnceCallbacks.
This CL was uploaded by git cl split.
R=bbudge@chromium.org
Bug: 714018
Change-Id: I3dfbf9194abf30d0f9c36363ef00033eb04b102e
Reviewed-on: https://chromium-review.googlesource.com/c/1475645
Auto-Submit: kylechar <kylechar@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#633569}

[DevTools] Do not reroute flatten protocol message in forwarding DTAH

Comments

[DevTools] Do not reroute flatten protocol message in forwarding DTAH
For forwarding agent host we should first deliver the whole message
to the real recipient, who will then reroute it to the child session
if needed. This way we can debug child targets with flatten protocol
on remote devices.
Bug: 921059
Change-Id: I66963171ee109fa4718149b373b4f475103700ec
Reviewed-on: https://chromium-review.googlesource.com/c/1478393
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#633583}

Changed files

content/browser/devtools/devtools_session.cc

BlinkMemoryMgt: Apply the macros of Allocator to the classes of renderer/core/paint

Comments

BlinkMemoryMgt: Apply the macros of Allocator to the classes of renderer/core/paint
The OnionSoup effort has a goal of allocating all garbage-collectable Blink objects
with Oilpan or PartitionAlloc. However, the 2 classes of //blink/renderer/core/paint
has not yet been allocated with them so far. So their uses of non-garbage-collected
objects should be restricted to cases where the garbage collector can discover their
references. The macros of Allocator will be useful for the non-garbage-collected
ob
...skip...
SelectionPaintingUtils classes have only static
functions. So it makes sense to use STATIC_ONLY.
Lastly, the rest of classes weren't used by member variables or any smart pointer type.
So they makes sense to use STACK_ALLOCATED.
Bug: 919389
Change-Id: I08735208922bd1a4d12878a0788fd60bcd4a325e
Reviewed-on: https://chromium-review.googlesource.com/c/1477142
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Gyuyoung Kim <gyuyoung@igalia.com>
Cr-Commit-Position: refs/heads/master@{#633584}

fido: only instantiate the USB discovery for cryptotoken requests

Comments

fido: only instantiate the USB discovery for cryptotoken requests
This changes AuthenticatorImpl to never instantiate discoveries other
than USB for requests originating from cryptotoken.
Previously, it would instantiate all available discoveries, though
Bluetooth is hidden behind a flag, cryptotoken never sends a caBLE
extension, and NFC doesn't exist. The "internal" transport discovery
exists on macOS, and was inadvertently instantiated for cryptotoken
requests. However, ChromeAuthenticatorRequest
...skip...
h() to return false for the Touch ID
authenticator so that any request gets immediately dispatched to the
Touch ID authenticator, resulting in an immediate Touch ID prompt for
all U2F sign requests (crbug/932723).
Bug: 932723,897757
Change-Id: I3cf4a921ca43444e412599772b334649800526ee
Reviewed-on: https://chromium-review.googlesource.com/c/1478390
Reviewed-by: Kim Paulhamus <kpaulhamus@chromium.org>
Commit-Queue: Martin Kreichgauer <martinkr@google.com>
Cr-Commit-Position: refs/heads/master@{#633589}

Update GCMS::AddAccountToCookie() to take a callback that is invoked on completion

Comments

Update GCMS::AddAccountToCookie() to take a callback that is invoked on completion
Similarly to crbug.com/927749, this CL uses a completion callback to signal
GCMS::AddAccountToCookie's completion.
As of today, this is done with a GCMS::Observer callback: OnAddAccountToCookieCompleted.
Benefits of this approach:
- cleaner the API surface
- it fixes the issue that today all observers of IdentityManager::Observer::OnAddAccountToCookieCompleted
get called, no matter if it was the one calling GCMS::AddAccountToCookie or not.
BUG=932180
Change-Id: I9307d14996f96dc8f8ab483271b4a36d27f6673b
Reviewed-on: https://chromium-review.googlesource.com/c/1474030
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Reviewed-by: David Roger <droger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#633592}