Comments

[Extensions] Update ExtensionService references in c/b/extensions
Update references to ExtensionService in c/b/extensions to use
extensions::ExtensionService.
Clean up a few other instances when the extensions:: prefix is
unnecessary.
There should be no behavior change as a result of this CL.
Bug: 117261
Change-Id: I95616145a995bdf5828036b682647d6e61649c8c
Reviewed-on: https://chromium-review.googlesource.com/1076974
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#562678}

Make the CrostiniRegistryService::Registration a view on prefs

Comments

Make the CrostiniRegistryService::Registration a view on prefs
Instead of pulling out all the fields from prefs when we want to get a
Crostini app registration into separate data types, we just store a
base::Value from prefs and extract values as needed (for safety we clone
the value in prefs instead of keeping a pointer, as it may be changed
upon updates). This makes it a bit tidier and easier to add new fields.
We also remove the LocaleString (= map<string, string>) type which was
used to represent strings different values for different locales and
only allow users to get the value for the current locale.
Change-Id: Ib91f41d65c009e1ef706b61f4e1546f863f3a077
Reviewed-on: https://chromium-review.googlesource.com/1071269
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Nicholas Verne <nverne@chromium.org>
Commit-Queue: Timothy Loh <timloh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#562680}

performance.memory: report precise values when locked to site

Comments

performance.memory: report precise values when locked to site
This CL plumbs to Blink whether the renderer process is locked to a
site (a scheme plus eTLD+1, like https://google.com) or to other more
granular lock. This is used by MemoryInfo to report precise data when
the process is locked to an origin. The data is still cached / delayed,
but not as much as in the bucketized case.
This CL also changes |total_js_heap_size|, see
https://chromium-review.googlesource.com/c/chromium/src/+/1020140
The two changes are aggregated in the same CL to ensure the bump to
performance.memory occurs only once.
Bug: 807651, 834446
Change-Id: I17917769b43c45172a54cddc5215702ce6032008
Reviewed-on: https://chromium-review.googlesource.com/1012502
Commit-Queue: Nicolás Peña Moreno <npm@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#562688}

Reland "Support late registration of syncable preferences."

Comments

Reland "Support late registration of syncable preferences."
Sync integration tests where flaky on some platforms. Fixed
those integration tests by enabling self-notifications and
only modifying one client (and not the verifier as well).
Inspected try-bot runs from two executions verifying no flakes.
Original CL description:
Support late registration of syncable preferences.
Today, there's already a race when registering a preference
through the mojo preference service: the asynchronous
registration
...skip...
s for a whitelisted set of preferences.
More details about the approach can be found in the design
doc linked from the crbug/840332.
Bug: 840332
Change-Id: I5fd2883d403b961a6332d7ee7bcdbad72f5cab8f
Reviewed-on: https://chromium-review.googlesource.com/1074688
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Reviewed-by: Dominic Battré <battre@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Commit-Queue: Tim Schumann <tschumann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#562689}