Skip to content

GitLab

T
tangled
Switch branch/tag
  1. 26 Feb, 2018 8 commits
  3. 25 Feb, 2018 28 commits
  5. 24 Feb, 2018 4 commits
    • Wez's avatar
      Broaden test filter for TaskSchedulerWorkerPoolHistogramTests. · 35b3464d
      Wez authored 
      These tests rely on thread sleeps for synchronization, which makes them
racey when run on heavily-loaded systems.

TBR: scottmg
Bug: 816170, 735701
Change-Id: I9cad471cf8bc88fd91dc33662489983f13f18786
Reviewed-on: https://chromium-review.googlesource.com/936446Reviewed-by: default avatarWez <wez@chromium.org>
Commit-Queue: Wez <wez@chromium.org>
Cr-Commit-Position: refs/heads/master@{#539025}
      35b3464d
    • Michael Giuffrida's avatar
      Don't set active browser until browser window exists · 3ca12c85
      Michael Giuffrida authored 
      BrowserView should not call BrowserList::SetLastActive(Browser* browser)
before the Browser's |window_| is set. This can currently happen if a
BrowserView's widget receives an activation event before
CreateBrowserWindow() returns. This also means SetLastActive is called
before the Browser adds itself to the BrowserList.

Since Browser only calls BrowserList::AddBrowser() after the Browser and
BrowserWindow have been initialized, it's safe for BrowserList to check
whether the window is active for itself and, if so, call SetLastActive()
when the browser is added.

Bug: 811243,811191
Change-Id: I621238e942ab689fdbfe00b1776957477a7b0c4e
Reviewed-on: https://chromium-review.googlesource.com/915202Reviewed-by: default avatarScott Violet <sky@chromium.org>
Commit-Queue: Michael Giuffrida <michaelpg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#539024}
      3ca12c85
    • Yash Malik's avatar
      VR: Added a test for clamping composition and selection indices · c6c3b744
      Yash Malik authored 
      Also moved the relavant tests from content_element_unittest.cc to
text_input_info_unittest.cc

This is a post-commit followup to
https://chromium-review.googlesource.com/c/chromium/src/+/933701

Bug: 641470
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_vr;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Id2b938ae48049c2362ca9841fb6cc29388ac07bd
Reviewed-on: https://chromium-review.googlesource.com/935286Reviewed-by: default avatarIan Vollick <vollick@chromium.org>
Commit-Queue: Yash Malik <ymalik@chromium.org>
Cr-Commit-Position: refs/heads/master@{#539023}
      c6c3b744
    • David Benjamin's avatar
      Request a new client certificate if a cached one is stale. · 76a40adc
      David Benjamin authored 
      If an SSLPrivateKey is backed by a smartcard or other interesting
module, the handle may eventually stop working. In particular, the
smartcard may be removed at some point.

Ideally, the OS would provide reliable fine-grained signals to clear
relevant the cache entries, but the OS tends not to provide these APIs.
We do drop the cache entry on failure, but the user is required to retry
the operation.

Instead, if an SSLPrivateKey was grabbed from the SSLClientAuthCache,
assume it is potentially stale. Should the signing operation fail, we
can not only drop the cache entry, but retry the request.

This CL does not implement this logic for proxy client certificates,
only server client certificates. Proxy client certificates a missing the
cache clearing logic (https://crbug.com/814911), so we can fill this in
once the plumbing is in place.

Along the way, fill in some URLRequest-level client certificate unit
tests.

Bug: 813022
Change-Id: I9f0450e9f4df1383dd8b73d0297ebea5e3368fec
Reviewed-on: https://chromium-review.googlesource.com/935723Reviewed-by: default avatarRyan Sleevi <rsleevi@chromium.org>
Commit-Queue: David Benjamin <davidben@chromium.org>
Cr-Commit-Position: refs/heads/master@{#539022}
      76a40adc