- 28 Aug, 2018 40 commits
-
-
Friedrich Horschig authored
This CL ensures that any access to the ManualFillingCoordinator checks whether the latter exists in the first place. Because its initialization happens after the native initialization, this is a possible source of crashes. Also, this CL handles that cases in which the bottom control space changes even if there is no accessory to fill it. Bug: 876215, 877687 Change-Id: I713ab1343742c858d6ab0277b94cf3190e88e5e2 Reviewed-on: https://chromium-review.googlesource.com/1189805 Commit-Queue: Friedrich Horschig [CEST] <fhorschig@chromium.org> Reviewed-by:
Bernhard Bauer <bauerb@chromium.org> Cr-Commit-Position: refs/heads/master@{#586732}
-
John Budorick authored
TBR=martiniss@chromium.org NOTRY=true Bug: 855319 Change-Id: Ia760d2ff0e5c7bfe6cf1508464d0c1e5bc1e2026 Reviewed-on: https://chromium-review.googlesource.com/1194325Reviewed-by:
John Budorick <jbudorick@chromium.org> Commit-Queue: John Budorick <jbudorick@chromium.org> Cr-Commit-Position: refs/heads/master@{#586731}
-
Florian Uunk authored
This CL makes the tests run for both the directory-based implementation and the new USS based implementation. Bug: 876301 Change-Id: Id613f23514b52bf01d1d0ed3bdc73b87e758a03b Reviewed-on: https://chromium-review.googlesource.com/1189963Reviewed-by:
Jan Krcal <jkrcal@chromium.org> Commit-Queue: Florian Uunk <feuunk@chromium.org> Cr-Commit-Position: refs/heads/master@{#586730}
-
Xi Cheng authored
This change also simplifies the approach to getting the profiler callback across CallStackProfileMetricsProvider and ChildCallStackProfileCollector by directly calling ChildCallStackProfileCollector::Collect() or CallStackProfileMetricsProvider::ReceiveCompletedProfile() from CallStackProfileBuilder::OnProfileCompleted(). Bug: 851163 Change-Id: Ia9a39510342cf6f4f1e43464b4c54345ba5e4d63 Reviewed-on: https://chromium-review.googlesource.com/1185854Reviewed-by:
Mike Wittman <wittman@chromium.org> Reviewed-by:
Scott Violet <sky@chromium.org> Commit-Queue: Xi Cheng <chengx@chromium.org> Cr-Commit-Position: refs/heads/master@{#586729}
-
Eric Seckler authored
This allows using //base/task/post_task.h for posting tasks to a BrowserThread by specifying a BrowserThread::ID as a task trait. Also adds a content::NonNestable task trait to support non-nestable tasks in base::PostTaskWithTraits. In the future, we will add further traits to facilitate scheduling tasks onto different SequenceManager queues on the UI thread, see: https://docs.google.com/document/d/1z1BDq9vzcEpkhN9LSPF5XMnZ0kLJ8mWWkNAi4OI7cos/edit?usp=sharing Bug: 867421, 863341, 878356 Change-Id: Id8b7bc2e374917ceb421c7f6139790e6f1457511 Reviewed-on: https://chromium-review.googlesource.com/1181364 Commit-Queue: Eric Seckler <eseckler@chromium.org> Reviewed-by:
Sami Kyöstilä <skyostil@chromium.org> Reviewed-by:
Avi Drissman <avi@chromium.org> Reviewed-by:
François Doray <fdoray@chromium.org> Reviewed-by:
Alex Clarke <alexclarke@chromium.org> Cr-Commit-Position: refs/heads/master@{#586728}
-
Morten Stenshorne authored
Bug: 878309 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng Change-Id: I961a8c962ca3b77b86a4cca37fdda81333ad8a88 Reviewed-on: https://chromium-review.googlesource.com/1194028Reviewed-by:
Koji Ishii <kojii@chromium.org> Commit-Queue: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#586727}
-
Tetsui Ohkubo authored
Height of sliders were wrong. 40dip -> 32dip It affected both slider bubble and main bubble. TEST=manual BUG=877558 Change-Id: I7b2822e263c4e335b845f0ea40a9b52866ced60e Reviewed-on: https://chromium-review.googlesource.com/1192374Reviewed-by:
James Cook <jamescook@chromium.org> Commit-Queue: Tetsui Ohkubo <tetsui@chromium.org> Cr-Commit-Position: refs/heads/master@{#586726}
-
Marc Treib authored
SyncAuthManager has a supposed invariant that only one of an access token, an access token request, or a pending retry can exist at any one time. However, it didn't properly enforce this, so in some cases the invariant could be violated. This CL fixes that, and adds a bunch of DCHECKs to make sure. Bug: 877440 Change-Id: I756e41d5045edb36fcfaa53104092a4f299a1e20 Reviewed-on: https://chromium-review.googlesource.com/1188472 Commit-Queue: Marc Treib <treib@chromium.org> Reviewed-by:
Mohamed Amir Yosef <mamir@chromium.org> Cr-Commit-Position: refs/heads/master@{#586725}
-
Marton Hunyady authored
Send a histogram value from UpgradeDetector when the device did install a rollback image and shows a notification before reboot. The metric records whether the rollback is happening because of a channel switch or because of an admin-initiated enterprise rollback. Bug: 871759 Change-Id: I38fad1792ba87b6bdbd788b3cd0f736dfa2d363c Reviewed-on: https://chromium-review.googlesource.com/1190703 Commit-Queue: Marton Hunyady <hunyadym@chromium.org> Reviewed-by:
Ilya Sherman <isherman@chromium.org> Reviewed-by:
Greg Thompson <grt@chromium.org> Cr-Commit-Position: refs/heads/master@{#586724}
-
Marton Hunyady authored
This fixes the issue that we're showing a misleading "Your administrator rolled back this device" notification on non-enrolled devices too if they switch the channel to a more stable version. Bug: 871759 Change-Id: I75e9e3faacaed0499fedef1aafda290cf0b87e19 Reviewed-on: https://chromium-review.googlesource.com/1188665Reviewed-by:
-
Avi Drissman authored
This test apparently: - Tries to use something called "objCPlugin" for Obj-C bindings, which doesn't exist in Blink - Then adds /etc/passwd as the canonical "local file" URL - Then attempts to instantiate an NSPasteboard Objective-C object - So that it can try to read the "NSFilenamesPboardType" obsolete data type off of it. This is not a useful test in any way. BUG=none Change-Id: If7b17055536eda22d401bed1b48ab4f35b53c3f5 Reviewed-on: https://chromium-review.googlesource.com/1192262Reviewed-by:
Philip Jägenstedt <foolip@chromium.org> Commit-Queue: Avi Drissman <avi@chromium.org> Cr-Commit-Position: refs/heads/master@{#586722}
-
Christian Biesinger authored
Allows passing in a precomputed border+padding struct to various length util functions. No-Try: True Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng Change-Id: I330dfc77e7392928f2475a05ecfdb6c643c9a5f4 Reviewed-on: https://chromium-review.googlesource.com/1193403 Commit-Queue: Christian Biesinger <cbiesinger@chromium.org> Reviewed-by:
Ian Kilpatrick <ikilpatrick@chromium.org> Reviewed-by:
Emil A Eklund <eae@chromium.org> Cr-Commit-Position: refs/heads/master@{#586721}
-
Etienne Pierre-doray authored
This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/shell_integration_linux.cc. 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=thomasanderson@chromium.org Bug: 874080 Change-Id: I64920670d2ccb62299815969d324003f462d8ecd Reviewed-on: https://chromium-review.googlesource.com/1191801Reviewed-by:Thomas Anderson <thomasanderson@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#586720}
-
Etienne Pierre-doray authored
This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/web_applications/components/web_app_shortcut_mac.mm. 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=rsesek@chromium.org Bug: 874080 Change-Id: Iffe2955c934c9a81ffddefd2d42cfb277aec0ddb Reviewed-on: https://chromium-review.googlesource.com/1191665Reviewed-by:Robert Sesek <rsesek@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#586719}
-
Jeremy Roman authored
It is always false and has been for over a year. Change-Id: Ibd2b6b8c3f6dc5e9e6ba4a877bdec98e0482f9af Reviewed-on: https://chromium-review.googlesource.com/1193750Reviewed-by:
Kentaro Hara <haraken@chromium.org> Commit-Queue: Jeremy Roman <jbroman@chromium.org> Cr-Commit-Position: refs/heads/master@{#586718}
-
Daniele Castagna authored
DrmThread::IsDeviceAtomic currently can cause a SIGSEGV since it assumes that |drm_device| is a valid pointer. |drm_device| device can be nullptr if the widget has been disabled. This patch fixes the issue checking that |drm_device| is a valid pointer before dereferencing it. Bug: 875882, 876385 Change-Id: I01527e9d9d294e0f98146ccd5e6d5ef70e0dfdf0 Reviewed-on: https://chromium-review.googlesource.com/1193963Reviewed-by:
Michael Spang <spang@chromium.org> Commit-Queue: Daniele Castagna <dcastagna@chromium.org> Cr-Commit-Position: refs/heads/master@{#586717}
-
Elly Fong-Jones authored
Combobox menus support this already, but on Mac all menus should support it instead of Windows/Linux-style mnemonics for items. This change: 1) Adds a new MenuConfig knob for whether the platform behaves this way; 2) Adds PrefixSelector::WillContinueSelection() to expose whether the PrefixSelector search is still "live" (versus having timed out); 3) Adds logic to MenuController to only activate items on VKEY_SPACE when the PrefixSelector is not still accumulating a prefix search; 4) Changes SubmenuView::GetTextForRow() to use the accessible name for the row instead of the raw title. Not doing this causes prefix searches to fail because the raw title includes mnemonic-marking ampersands; 5) Disables MenuRunnerTest.{,Non}LatinMnemonic on Mac; 6) Adds MenuRunnerTest.PrefixSelect to test most of this behavior on Mac. Bug: 845466 Change-Id: I5d1e2c940026560d1e542263d99911889f52c742 Reviewed-on: https://chromium-review.googlesource.com/1187062 Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org> Reviewed-by: -
Etienne Pierre-doray authored
This CL uses ScopedBlockingCall to mark blocking calls in /ios/chrome/browser/ui/image_util. 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=gambard@chromium.org Bug: 874080 Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet Change-Id: I14f3200988ea3482fbccd94e0ff43e46dd192504 Reviewed-on: https://chromium-review.googlesource.com/1191130Reviewed-by:Gauthier Ambard <gambard@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#586715}
-
Xida Chen authored
TBR=beaufort.francois@gmail.com NOTRY=true Bug: 878396 Change-Id: I6216c7273e514fde365f591b0607eb8a69ab133e Reviewed-on: https://chromium-review.googlesource.com/1194243Reviewed-by:
Xida Chen <xidachen@chromium.org> Commit-Queue: Xida Chen <xidachen@chromium.org> Cr-Commit-Position: refs/heads/master@{#586714}
-
nednguyen authored
NOTRY=true TBR=pasko@chromium.org Bug: 878175 Change-Id: I399e3e0d905ade42d67985a1808f4b7a7ccd541a Reviewed-on: https://chromium-review.googlesource.com/1194242Reviewed-by:
Ned Nguyen <nednguyen@google.com> Commit-Queue: Ned Nguyen <nednguyen@google.com> Cr-Commit-Position: refs/heads/master@{#586713}
-
Ben Wagner authored
Remove the local SkFontMgr and SkTypeface mocks and replace them with a FakeFontCollection. This makes the test a better representation of what happens at runtime, makes the test smaller and easier to understand, and makes it easier for Skia to evolve the API of SkFontMgr and SkTypeface. Change-Id: I94866b5e9645e1a461c71807c9349b2e9f612032 Reviewed-on: https://chromium-review.googlesource.com/1185749Reviewed-by:
-
Xi Han authored
[FeatureList] Change GetApplicationLocale() in VariationsServiceClient to be a local function. [2/3] Before this function uses a pref in Chrome so we need to override it in Chrome to access that pref value. As a followup for this cl https://crrev.com/c/1135198, now we can access the pref directly in componment/ and we no longer need to do that. This CL comes from https://crrev.com/c/1140356. See previous discussion there. Bug:729596 TBR=asvitkine@chromium.org Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet Change-Id: I7bf5631b81436344ccb17aaa2a8d6ac4167f5d7f Reviewed-on: https://chromium-review.googlesource.com/1147481 Commit-Queue: Xi Han <hanxi@chromium.org> Reviewed-by:
John Abd-El-Malek <jam@chromium.org> Cr-Commit-Position: refs/heads/master@{#586711}
-
Robert Phillips authored
Bug: 875268 Change-Id: I1b830543820a49b0954814721b359a57469b9e44 Reviewed-on: https://chromium-review.googlesource.com/1191202Reviewed-by:
Brian Salomon <bsalomon@google.com> Reviewed-by:
Florin Malita <fmalita@chromium.org> Commit-Queue: Robert Phillips <robertphillips@google.com> Cr-Commit-Position: refs/heads/master@{#586710}
-
Andrew Grieve authored
This class doesn't have broad utility, so doesn't belong in base. Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel Change-Id: Ia877af08d8fd635c738e3c0c2cee588c8cba7be1 Reviewed-on: https://chromium-review.googlesource.com/1191091Reviewed-by:
Bo <boliu@chromium.org> Reviewed-by:
Sadrul Chowdhury <sadrul@chromium.org> Commit-Queue: agrieve <agrieve@chromium.org> Cr-Commit-Position: refs/heads/master@{#586709}
-
Balazs Engedy authored
Bug: 849323 Change-Id: If9701534446183c2d9bc78349a2e70e277e46916 TBR: hongjunchoi@chromium.org Reviewed-on: https://chromium-review.googlesource.com/1194025Reviewed-by:
Balazs Engedy <engedy@chromium.org> Commit-Queue: Balazs Engedy <engedy@chromium.org> Cr-Commit-Position: refs/heads/master@{#586708}
-
David Bokan authored
The CSS overscroll-behavior feature controls whether scrolling should continue to propagate up to the parent scroller. This CL adds the necessary plumbing to set the correct values on the CC ScrollNodes when Blink is responsible for creating the property trees (i.e. with --enable-blink-gen-property-trees is used). TEST=virtual/threaded/fast/scroll-behavior/overscroll-behavior.html Bug: 866051 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;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: I55938ec5801083e3cdcbf1e3d2da1cb7791d2c43 Reviewed-on: https://chromium-review.googlesource.com/1188647 Commit-Queue: David Bokan <bokan@chromium.org> Reviewed-by:
Philip Rogers <pdr@chromium.org> Reviewed-by:
Jianpeng Chao <chaopeng@chromium.org> Cr-Commit-Position: refs/heads/master@{#586707}
-
Henrique Grandinetti authored
Bug: 876357 Change-Id: Ia1e67b5c5d3cc20c67841108e6c055bc918f086e Reviewed-on: https://chromium-review.googlesource.com/1184082Reviewed-by:
Xiyuan Xia <xiyuan@chromium.org> Commit-Queue: Henrique Grandinetti <hgrandinetti@google.com> Cr-Commit-Position: refs/heads/master@{#586706}
-
Charlie Harrison authored
This CL stores a vector of URLs in a UkmSource rather than two separate URL members (final / initial). This will aid in future changes like storing the entire redirect chain. This CL should not change behavior. Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet Change-Id: If762a287601849dbf5c62d3a82477aca4f00fbac Reviewed-on: https://chromium-review.googlesource.com/1187070 Commit-Queue: Charlie Harrison <csharrison@chromium.org> Reviewed-by:
David Roger <droger@chromium.org> Reviewed-by:
Robert Kaplow (slow) <rkaplow@chromium.org> Cr-Commit-Position: refs/heads/master@{#586705}
-
Ken Rockot authored
Ensures that we don't blindly trust specified buffer size and offset metadata when deserializing data pipe consumer and producer handles. Bug: 877182 Change-Id: I30f3eceafb5cee06284c2714d08357ef911d6fd9 Reviewed-on: https://chromium-review.googlesource.com/1192922Reviewed-by:
Reilly Grant <reillyg@chromium.org> Commit-Queue: Ken Rockot <rockot@chromium.org> Cr-Commit-Position: refs/heads/master@{#586704}
-
Florian Uunk authored
The server currently sends version_watermark based GC directives in order to clear the clients entire sync storage for that datatype. This doesn't work in USS, because the processor only clears the metadata when receiving a GC directive. This means that the data itself is left as-is. This CL changes the expectations on the client when receiving a version_watermark GC directive to always clear the entire client storage. This is implemented in USS by handling an update that includes that GC directive as a full update that replaces any existing client data. We do this by allowing bridges to specify whether they support incremental updates or if they require full data updates. The processor then reports a ModelError when receiving an incremental update for a bridge that doesn't support incremental updates, or when receiving a full update for a bridge that supports incremental updates. When receiving a full update, the processor calls MergeSyncData instead of ApplySyncChanges on the bridge. Bug: 876308 Change-Id: I7fc83e75eb039346866cc6ebd7cf5aa4d9546fdb Reviewed-on: https://chromium-review.googlesource.com/1183902 Commit-Queue: Florian Uunk <feuunk@chromium.org> Reviewed-by:
Marc Treib <treib@chromium.org> Cr-Commit-Position: refs/heads/master@{#586703}
-
Etienne Pierre-doray authored
This CL uses ScopedBlockingCall to mark blocking calls in /ash/display. 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=afakhry@chromium.org Bug: 874080 Change-Id: Ibbeed96def34b810b6ed2d2b746f8700d2f4c8d0 Reviewed-on: https://chromium-review.googlesource.com/1191807Reviewed-by:Ahmed Fakhry <afakhry@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#586702}
-
Etienne Pierre-doray authored
This CL uses ScopedBlockingCall to mark blocking calls in /components/crash. 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=mark@chromium.org Bug: 874080 Change-Id: I85dff1e7321fcebb76a6fa2ff98046bd78377154 Reviewed-on: https://chromium-review.googlesource.com/1191803Reviewed-by:Mark Mentovai <mark@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#586701}
-
Etienne Pierre-doray authored
This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/ui/webui/print_preview. 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=weili@chromium.org Bug: 874080 Change-Id: Ib9f4215acff0afbbcdac414bf4d5617c09c81078 Reviewed-on: https://chromium-review.googlesource.com/1190931Reviewed-by:Wei Li <weili@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#586700}
-
Etienne Pierre-doray authored
This CL uses ScopedBlockingCall to mark blocking calls in /components/subresource_filter. 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=melandory@chromium.org Bug: 874080 Change-Id: I23a4bee02df67722e41dc8c0afb4b94073eb8d95 Reviewed-on: https://chromium-review.googlesource.com/1191135Reviewed-by:Charlie Harrison <csharrison@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#586699}
-
Eric Seckler authored
This prepares for replacing GetTaskRunnerForThread() inside HeadlessDevToolsClient::Create() with base::CreateSingleThreadTaskRunnerWithTraits(), which can only be called after browser initialization. Bug: 878356 Change-Id: I851788ee9926cddd4662876c84e98a1fb9d0d47e Reviewed-on: https://chromium-review.googlesource.com/1193367Reviewed-by:
-
Josh Karlin authored
The MatchRules test had non-deterministic sorting behavior on different platforms. Fix this by avoiding situations in the test where there are ties for the number of matches. Bug: 878328, 877148 Change-Id: I4883141c0c5c8ab02ace9365b4a446f132d6cea1 Reviewed-on: https://chromium-review.googlesource.com/1193902 Commit-Queue: Josh Karlin <jkarlin@chromium.org> Commit-Queue: Charlie Harrison <csharrison@chromium.org> Reviewed-by:
-
Etienne Pierre-doray authored
This CL uses ScopedBlockingCall to mark blocking calls in /components/webrtc_logging. 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=grunell@chromium.org Bug: 874080 Change-Id: I2f3f9d36b4dc8ed464fef884f87b898f06e47555 Reviewed-on: https://chromium-review.googlesource.com/1191098Reviewed-by:Henrik Grunell <grunell@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#586696}
-
Etienne Pierre-doray authored
This CL uses ScopedBlockingCall to mark blocking calls in /components/password_manager. 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=dvadym@chromium.org Bug: 874080 Change-Id: If6f3ead08018decf2c8a2be44d810f4fa23cc190 Reviewed-on: https://chromium-review.googlesource.com/1191409Reviewed-by:Vadym Doroshenko <dvadym@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#586695}
-
Brian Salomon authored
Change-Id: I970adfa9998f261d1f2d604aa7fe31c73335a80f Reviewed-on: https://chromium-review.googlesource.com/1188608Reviewed-by:
Robert Phillips <robertphillips@google.com> Commit-Queue: Brian Salomon <bsalomon@google.com> Cr-Commit-Position: refs/heads/master@{#586694}
-
Justin Cohen authored
Bug: 865834 Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs Change-Id: If4c9293870035e62828bfa44714a8dec2df673e2 Reviewed-on: https://chromium-review.googlesource.com/1191285Reviewed-by:
-
