- 14 Aug, 2018 40 commits
-
-
Vlad Tsyrklevich authored
SafeStack [1] introduces a secondary thread stack called the unsafe stack that also needs to be scanned for object references. Introduce matching logic in oilpan to scan the unsafe stack for heap references. [1] https://clang.llvm.org/docs/SafeStack.html Bug: 864705 Change-Id: I376077bd985e2077aa3771101c1822e1570c7807 Reviewed-on: https://chromium-review.googlesource.com/1169772Reviewed-by:
Kentaro Hara <haraken@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org> Cr-Commit-Position: refs/heads/master@{#583056}
-
Stefan Zager authored
This patch adds a flag indicating whether an iframe element is occluded or has visual effects applied in the parent document; and adds the flag to the IPC message containing the iframe's intersection with the parent's viewport. BUG=869049 R=kenrb@chromium.org,chrishtr@chromium.org Change-Id: I0891a3e6740dbce39f0cf0120353feb8c9fca173 Reviewed-on: https://chromium-review.googlesource.com/1167960Reviewed-by:
Alex Moshchuk <alexmos@chromium.org> Reviewed-by:
Chris Harrelson <chrishtr@chromium.org> Reviewed-by:
Ken Buchanan <kenrb@chromium.org> Commit-Queue: Stefan Zager <szager@chromium.org> Cr-Commit-Position: refs/heads/master@{#583055}
-
Eric Roman authored
Bug: 851609 Cq-Include-Trybots: luci.chromium.try:linux_mojo Change-Id: I2f261550d21f80e4b2143c0253a3867f11091885 Reviewed-on: https://chromium-review.googlesource.com/1175054 Commit-Queue: Eric Roman <eroman@chromium.org> Reviewed-by:
Matt Menke <mmenke@chromium.org> Cr-Commit-Position: refs/heads/master@{#583054}
-
Mike Dougherty authored
This fully enables support for context menu in iFrames. Bug: 873660, 873662 Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet Change-Id: I3345f56f6812ef619c6ed5b7bcabd34e09de410f Reviewed-on: https://chromium-review.googlesource.com/1174052 Commit-Queue: Mike Dougherty <michaeldo@chromium.org> Reviewed-by:
Eugene But <eugenebut@chromium.org> Cr-Commit-Position: refs/heads/master@{#583053}
-
Wei-Yin Chen (陳威尹) authored
For those subfolders of //chrome/ without violations, add them to gn check targets. Otherwise, add number of errors in comments. Bug: 367595 Change-Id: I8a2dc703f9b415e47f6fa3c1910b6338dd02ae69 Reviewed-on: https://chromium-review.googlesource.com/1174095Reviewed-by:
Dirk Pranke <dpranke@chromium.org> Commit-Queue: Wei-Yin Chen (陳威尹) <wychen@chromium.org> Cr-Commit-Position: refs/heads/master@{#583052}
-
Martin Kreichgauer authored
Currently, the |FidoRequestHandlerBase::AddAuthenticator| method synchronously invokes the virtual |DispatchRequest| method, which subclasses implement to process the request and invoke the response handling callback. Most authenticators are instantiated by a |FidoDiscovery| which does some asynchronous discovery work and then calls |AddAuthenticator|. Platform authenticators, on the other hand, are instantiated by |MaybeAddPlatformAuthenticator|, which gets invoked synchronously with request handler instantiation. This makes it possible to have a synchronous code path from request handler instantation to response callback invocation (i.e. hairpinning). In those cases, |AuthenticatorImpl| is unable to handle the response (see e.g. https://cs.chromium.org/chromium/src/content/browser/webauth/authenticator_impl.cc?sq=package:chromium&dr&g=0&l=749). This change makes |DispatchRequest| invocation asynchronous, which eliminates any possibility of response callback hairpinning. Bug: 678128 Change-Id: I6bf273775885abac1fa38fe12c964e930407cc7e Reviewed-on: https://chromium-review.googlesource.com/1172917 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by:
Balazs Engedy <engedy@chromium.org> Reviewed-by:
Jun Choi <hongjunchoi@chromium.org> Cr-Commit-Position: refs/heads/master@{#583051}
-
Fernando Serboncini authored
TBR=kbr@chromium.org Bug: 753483, 873914 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_layout_tests_slimming_paint_v2;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I958694f9db571b66c40baf144025d87acf824dc2 Reviewed-on: https://chromium-review.googlesource.com/1173169 Commit-Queue: Fernando Serboncini <fserb@chromium.org> Reviewed-by:
Fernando Serboncini <fserb@chromium.org> Cr-Commit-Position: refs/heads/master@{#583050}
-
rbpotter authored
Specifically, adding new test suites webui_polymer2_browser_tests and webui_polymer2_interactive_ui_tests that run a given list of tests and explicitly excludes currently failing tests. This will allow gradually getting to a state where all tests are passing with the flag on. Bug: 862472 Change-Id: Ia19ae36a4b2b63499b970e14c742b7719e118f83 Reviewed-on: https://chromium-review.googlesource.com/1132320 Commit-Queue: Rebekah Potter <rbpotter@chromium.org> Reviewed-by:
-
Gabriel Charette authored
This was removed in r577553 but I unintentionally reintroduced it in r578809 (incorrect rebase). This regressed https://crbug.com/860801#c18 R=kylechar@chromium.org Bug: 860801 Change-Id: Ia42d24f915d271832b59c481ebe77ee1bc6fd11d Reviewed-on: https://chromium-review.googlesource.com/1175060Reviewed-by:
kylechar <kylechar@chromium.org> Commit-Queue: Gabriel Charette <gab@chromium.org> Cr-Commit-Position: refs/heads/master@{#583048}
-
Lukasz Anforowicz authored
This is a reland of unmodified r582223, after separately taking care of https://crbug.com/873780 which caused the earlier revert. Original CL description follows below: After this CL site-per-process is the default in all layers on desktop platforms, except: - Layout Tests which still run with no isolation by default (see https://crbug.com/856734#c5 for the explanation why) - //content embedders that don't want to use site-per-process: //chromecast - //content embedders that don't yet support site-per-process, but will need to migrate eventually: //headless Also note that even after this CL: - //content on Android still defaults to no isolation. This is compatible with not_site_per_process_* test steps because such steps are not run on Android bots... - //chrome layer ChromeContentBrowserClient controls usage of site-per-process in the Chrome browser and continues to be controlled by a field trial (note that Android is not covered by the field trial or by testing/variations/fieldtrial_testing_config.json). Bug: 856734 Change-Id: I0cfd7e342c44a36d22a885b46892a9e4e3f2c758 Tbr: Stephen Lanham <slan@chromium.org> Tbr: Sami Kyöstilä <skyostil@chromium.org> Tbr: Bo <boliu@chromium.org> Tbr: Nico Weber <thakis@chromium.org> Tbr: Alex Moshchuk <alexmos@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1174855Reviewed-by:
Łukasz Anforowicz <lukasza@chromium.org> Reviewed-by:
-
Sam McNally authored
The drive-internals page uses GCache/v1 as the root for the files displayed in the GCache Contents section of about:drive-internals. Use its parent instead so the GCache/v2 contents are also displayed. Bug: 829703 Change-Id: I7e47db743737a2331484e2b913600051470000b5 Reviewed-on: https://chromium-review.googlesource.com/1174135Reviewed-by:
Noel Gordon <noel@chromium.org> Commit-Queue: Sam McNally <sammc@chromium.org> Cr-Commit-Position: refs/heads/master@{#583046}
-
Peter Boström authored
Moves any values that were still handled by ChromeLayoutProvider into HarmonyLayoutProvider and adds a bunch of CHECK(false) inside ChromeLayoutProvider to make sure that it's not called. The next step will merge all HarmonyLayoutProvider code back into ChromeLayoutProvider and remove the HarmonyLayoutProvider class completely (effectively making HarmonyLayoutProvider the new ChromeLayoutProvider). Moving code into HarmonyLayoutProvider as a first step is only done because it generates an easier diff for review (less code had to move from ChromeLayoutProvider than vice versa). Bug: chromium:867557 Change-Id: I477925c09e37b328103102e0d606a9d9db605eb5 Reviewed-on: https://chromium-review.googlesource.com/1171191Reviewed-by:
Scott Violet <sky@chromium.org> Commit-Queue: Peter Boström <pbos@chromium.org> Cr-Commit-Position: refs/heads/master@{#583045}
-
Kevin McNee authored
Bug: None Change-Id: Id76ae87bf92bf00c6f32e54afe963713b0e9f8c4 Reviewed-on: https://chromium-review.googlesource.com/1175064Reviewed-by:
Ehsan Karamad <ekaramad@chromium.org> Commit-Queue: Kevin McNee <mcnee@chromium.org> Cr-Commit-Position: refs/heads/master@{#583044}
-
Zhiqiang Zhang authored
This CL migrates the CastMessageHandler for CAF. There's not much code change between CastMessageHandler and CafMessageHandler. Bug: 711860 Change-Id: Id58454c51cd6ada50b507d750a979ffe4e248241 Reviewed-on: https://chromium-review.googlesource.com/1169920 Commit-Queue: Zhiqiang Zhang <zqzhang@chromium.org> Reviewed-by:
Mounir Lamouri <mlamouri@chromium.org> Reviewed-by:
Thomas Guilbert <tguilbert@chromium.org> Cr-Commit-Position: refs/heads/master@{#583043}
-
Zhiheng Vincent Li authored
isRemoteControlMode is obtained from (Cast)WebApplication when creating CastWebView and passed to cast_content_window_android.cc -> CastContentWindowAndroid.java to reach Java side. From cast to other Android app: add a param in intent to start CastWebContentsFragment in CastWebContentsComponent.java Bug: b/110761726 b/111887184 Test: cast_shell_junit_tests cast_shell_internal_junit_tests Change-Id: I08cf42a492647d4d7c7b0c6593c6eb8852ae7179 Reviewed-on: https://chromium-review.googlesource.com/1164631 Commit-Queue: Zhiheng(Vincent) Li <vincentli@google.com> Reviewed-by:
Luke Halliwell <halliwell@chromium.org> Reviewed-by:
Simeon Anfinrud <sanfin@chromium.org> Cr-Commit-Position: refs/heads/master@{#583042}
-
Xiaoqian Dai authored
After drag starts, the window needs to be dragged vertically a small amount of distance to be considered as 'moved' and only after that, the drag indicators will show up and the window can be snapped. But after the window has been 'moved', it should stay moved even the window is dragged toward to the top of the screen. Bug: 873275 Change-Id: I4546a3a6839427c7232dcc5b6f234913b9dd516d Reviewed-on: https://chromium-review.googlesource.com/1173472 Commit-Queue: Xiaoqian Dai <xdai@chromium.org> Reviewed-by:
Xiyuan Xia <xiyuan@chromium.org> Cr-Commit-Position: refs/heads/master@{#583041}
-
Kyle Milka authored
Bug: None Change-Id: I27463c41df068ab0fb546f0d197cf77c3a47596b Reviewed-on: https://chromium-review.googlesource.com/1174708Reviewed-by:
Ilya Sherman <isherman@chromium.org> Commit-Queue: Kyle Milka <kmilka@chromium.org> Cr-Commit-Position: refs/heads/master@{#583040}
-
Clark DuVall authored
Moved the onComplete listener to before the webview request is made so the listener can be set up when the auth request is made. This is necessary because of how network service handles the webRequest API. See http://crrev.com/c/1139048 for more info. Bug: 769401 Cq-Include-Trybots: luci.chromium.try:linux_mojo Change-Id: I0537bfaac2c8ba60fc4afeffcd3c39802eda01c1 Reviewed-on: https://chromium-review.googlesource.com/1174706Reviewed-by:
Ken Rockot <rockot@chromium.org> Commit-Queue: Clark DuVall <cduvall@chromium.org> Cr-Commit-Position: refs/heads/master@{#583039}
-
Clark DuVall authored
These were using a URLRequestInterceptor, which doesn't work with the network service. Switched to using content::URLLoaderInterceptor. Bug: 769401 Cq-Include-Trybots: luci.chromium.try:linux_mojo Change-Id: I5032eaccac335a060d0d3dedd83d8d723c471d34 Reviewed-on: https://chromium-review.googlesource.com/1173012Reviewed-by:
John Abd-El-Malek <jam@chromium.org> Commit-Queue: Clark DuVall <cduvall@chromium.org> Cr-Commit-Position: refs/heads/master@{#583038}
-
Rohit Rao authored
BUG=873972 Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet Change-Id: Ic81c197c96e812e967958ff03aff6c55dc2bd119 Reviewed-on: https://chromium-review.googlesource.com/1174941Reviewed-by:
Antonio Gomes <tonikitoo@igalia.com> Reviewed-by:
Maks Orlovich <morlovich@chromium.org> Reviewed-by:
Peter Lee <pkl@chromium.org> Commit-Queue: Peter Lee <pkl@chromium.org> Cr-Commit-Position: refs/heads/master@{#583037}
-
Elad Alon authored
Help distinguish WebRTC event logs from textual logs. Bug: 775415 Change-Id: I17b14cfc25ab0c70eecd905cd28bad77304c3b3f Reviewed-on: https://chromium-review.googlesource.com/1174352Reviewed-by:
Henrik Grunell <grunell@chromium.org> Reviewed-by:
Avi Drissman <avi@chromium.org> Commit-Queue: Elad Alon <eladalon@chromium.org> Cr-Commit-Position: refs/heads/master@{#583036}
-
Mina Almasry authored
Currently playback will usually start in sync, but in some cases the AV sync will be off by about 100ms or more at the start of playback. This is especially reproducible after seeking. It is fixed in this CL. MediaPipelineBackend will only start playback after all these conditions are met: 1. Video is ready to play. This fixes issues with video starting too late. 2. Audio is ready to play. This fixes issues with audio starting too late. 3. A pause and resume operation has been executed. This is because the buffering logic in the upper layers always start us in the paused state. Having a pause and resume operations be executed at arbitrary times while the audio and video are getting ready to play is problematic when we want to accurately control when the first video and audio frames are played. So, to interop with the buffering logic, we start playback at the first resume call, which is what the buffering logic seems to want to accomplish anyway. The audio pipeline now drops audio that preceeds the starting PTS time, and preserves PTS for rate-changed audio. Bug: b/111124705 Depends-On: eureka-internal/189521, eureka-internal/189519, eureka-internal/191050 Test: cast_media_unittests, manual testing with Youtube and Youtube TV. Change-Id: Ib4cd98e010b8d29c183d321156c029551b05ef18 Reviewed-on: https://chromium-review.googlesource.com/1139397 Commit-Queue: Mina Almasry <almasrymina@chromium.org> Reviewed-by:
Kenneth MacKay <kmackay@chromium.org> Cr-Commit-Position: refs/heads/master@{#583035}
-
Mike Wasserman authored
Add a simple WindowTree::SetHitTestMask impl and unit test. Wire up the TouchHandleWindowTargeter, used in the KSV app, etc. Clarify that the targeter only insets bounds, it does not extend them. Bug: 872891 Test: KSV app text touches work as expected (modulo Issue 873743). Change-Id: I4a1b79a8826a7e176ce3dafb29e1223ddd003966 Reviewed-on: https://chromium-review.googlesource.com/1171218Reviewed-by:
-
Gayane Petrosyan authored
These are histograms that have not been viewed in the last 6 months, but still report data on the Stable channel. Set these histograms to stop being recorded for Chrome releases after 2018-08-30. We will file bugs via Monorail (crbug) reminding owners about the approaching histogram expiry – initially 30 days prior to expiry, and also with follow-up alerts. The metrics dashboards will also display a warning for anyone viewing a soon-to-expire histogram. Owners and/or users of these histograms: Please comment on this CL if you think that any affected histogram should not have an expiry date set! This should be uncommon. Otherwise, there are a few options going forward: * If the histogram is no longer needed, please send a follow-up CL to delete the recording code and to mark the histogram as <obsolete>. (You can also remove the expiry date in the same CL.) * If you want to set a different expiry date, please send a follow-up CL to do so. * If neither of the above apply, then keep an eye out for Monorail bugs as the histogram expiry date approaches. For more info on how unused histograms are identified, see https://goto.google.com/uma-unused-histograms-cleanup Bug: 850539 Change-Id: Ic01c7e6444cf45c2cc42bf58a6207bd3216b92f5 Reviewed-on: https://chromium-review.googlesource.com/1126400 Commit-Queue: Gayane Petrosyan <gayane@chromium.org> Reviewed-by:Xing Liu <xingliu@chromium.org> Cr-Commit-Position: refs/heads/master@{#583033}
-
Lei Zhang authored
It should be desktop only. Change-Id: I3e498cbd9fe5a9abfa798c4f3719bf7089aa02f5 Reviewed-on: https://chromium-review.googlesource.com/1174998Reviewed-by:
-
Kevin McNee authored
Currently, a guest view responds to control wheel zoom changes by zooming the embedder. However, the embedder itself may not respond to control wheel zoom changes. So a user could zoom an otherwise non-zoomable embedder by control wheel zooming inside a guest. We now have the guest view inform the embedder that a control wheel zoom change has occurred so that the embedder can decide how to handle it. Bug: 874189 Change-Id: Icd49a2590e502bb60b7e3d6d372de3a133e2277f Reviewed-on: https://chromium-review.googlesource.com/1175006Reviewed-by:
James MacLean <wjmaclean@chromium.org> Commit-Queue: Kevin McNee <mcnee@chromium.org> Cr-Commit-Position: refs/heads/master@{#583031}
-
Sammie Quon authored
Also fix a bug where continue button was still enabled after tabbing to and pressing backspace with the keyboard. Test: manual Bug: 855014, 869641 Change-Id: I0f3e570fc87b1a2e60de112de47558885f5d4847 Reviewed-on: https://chromium-review.googlesource.com/1173139Reviewed-by:
Steven Bennetts <stevenjb@chromium.org> Commit-Queue: Sammie Quon <sammiequon@chromium.org> Cr-Commit-Position: refs/heads/master@{#583030}
-
Henrique Grandinetti authored
3 things are done here: - add underscore to private properties of UsageTimeLimitProcessor class; - fix a couple of comments with typos; - rename 'override' property. Override is a reserved word starting on C++11; Bug: 869954 Change-Id: I9d9f5ab133b9a9c639b68b25648beb3c8fbfe119 Reviewed-on: https://chromium-review.googlesource.com/1159041Reviewed-by:
Alexander Alekseev <alemate@chromium.org> Reviewed-by:
Jacob Dufault <jdufault@chromium.org> Commit-Queue: Henrique Grandinetti <hgrandinetti@google.com> Cr-Commit-Position: refs/heads/master@{#583029}
-
Chromite Chromium Autoroll authored
https://chromium.googlesource.com/chromiumos/chromite.git/+log/6febc356717c..db93180205a6 git log 6febc356717c..db93180205a6 --date=short --no-merges --format='%ad %ae %s' 2018-08-14 manojgupta@google.com chromeos_config: Mark eve as experimental. Created with: gclient setdep -r src/third_party/chromite@db93180205a6 The AutoRoll server is located here: https://chromite-chromium-roll.skia.org 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=chrome-os-gardeners@chromium.org Change-Id: I60803dea17bcaf7a0637b197bba81ac7c6b16670 Reviewed-on: https://chromium-review.googlesource.com/1174795Reviewed-by:
Chromite Chromium Autoroll <chromite-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Commit-Queue: Chromite Chromium Autoroll <chromite-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#583028}
-
W. James MacLean authored
This CL is experimental, and aims to see if a changing surface id for the root view could be at the heart of the flakey tests reference by the associated bug. One flakey test is re-enabled to provide some initial data. The surface id idea is cherry-picked from kinuko@'s CL at https://chromium-review.googlesource.com/c/chromium/src/+/1126598 . Bug: 833380 Change-Id: I3cda4f5214a5bf19e711f95303a6b65b4ff2410c Reviewed-on: https://chromium-review.googlesource.com/1172723 Commit-Queue: James MacLean <wjmaclean@chromium.org> Reviewed-by:
Jonathan Ross <jonross@chromium.org> Reviewed-by:
-
Manu Cornet authored
This fixes an issue where the app list button position wasn't properly calculated, causing the shelf icons to sometimes "bleed" over the app list button. Bug: 805612 Bug: 869649 Change-Id: Id774e15edbde8704789ed77bb36da194060fc3e9 Reviewed-on: https://chromium-review.googlesource.com/1173753Reviewed-by:
-
Alexei Filippov authored
This speeds up bars drawing by an order of magnitude as all the work is delegated to the GPU. Vertex layout is performed once when model is loaded or when groups are expanded/collapsed. The actual drawing caused by zooming and panning the flamechart just modifies the transformation matrices. Titles and custom decorations are still drawn on the overlay 2D canvas. The WebGL mode is currently put behind an experiment. BUG=874116 Change-Id: I5984db2769d8ed5317b630bd705ab8447baa9358 Reviewed-on: https://chromium-review.googlesource.com/1174861 Commit-Queue: Alexei Filippov <alph@chromium.org> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#583025}
-
Maks Orlovich authored
Cq-Include-Trybots: luci.chromium.try:linux_mojo Change-Id: If1cebe592b61a84eee86c0daf74c9524128fe4c2 Reviewed-on: https://chromium-review.googlesource.com/1142350 Commit-Queue: Maks Orlovich <morlovich@chromium.org> Reviewed-by:
-
Manu Cornet authored
It could happen that the separator would appear after all visible items (after the overflow button when there was one). This prevents that from happening. Bug: 805612 Change-Id: I0a3105a94850a7325c3e642c409ef3603124aa39 Reviewed-on: https://chromium-review.googlesource.com/1173756Reviewed-by:
-
pdfium-chromium-autoroll authored
https://pdfium.googlesource.com/pdfium.git/+log/692aeadfe32d..f46d49b52d39 git log 692aeadfe32d..f46d49b52d39 --date=short --no-merges --format='%ad %ae %s' 2018-08-14 thestig@chromium.org Roll third_party/freetype/src/ 578bcf103..96b5e5009 (23 commits) Created with: gclient setdep -r src/third_party/pdfium@f46d49b52d39 The AutoRoll server is located here: https://pdfium-roll.skia.org 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=dsinclair@chromium.org Change-Id: Id49480cb1513f91ec83fcf23ad99e93153eca8e2 Reviewed-on: https://chromium-review.googlesource.com/1174794Reviewed-by:
pdfium-chromium-autoroll <pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Commit-Queue: pdfium-chromium-autoroll <pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#583022}
-
James Cook authored
The former is the only subclass of the latter. The other subclass was removed when we switched the --show-taps feature to using the tap_visualizer mojo UI app. Pure clean up, no functional changes. Bug: 873264 Test: ash_unittests, manual test of --ash-touch-hud then Ctrl-Alt-I Change-Id: I5e81f57655a69ee6b4f33e4ed42d27285481a83c Reviewed-on: https://chromium-review.googlesource.com/1173254Reviewed-by:
Mohsen Izadi <mohsen@chromium.org> Commit-Queue: James Cook <jamescook@chromium.org> Cr-Commit-Position: refs/heads/master@{#583021}
-
Martin Kreichgauer authored
This disables platform authenticators (i.e. Touch ID) for makeCredential requests with an unset AuthenticatorAttachment value in AuthenticatorSelectionCriteria. This is done to prevent Touch ID fingerprint prompts for requests that could be handled by external authenticators, as long as Touch ID is not integrated with UI. Filed crbug.com/873710 to track reversal of this change once UI integration is there. Bug: 678128 Change-Id: I7aaffe53dfca7ee14b5a94f9ead2027ab370c35c Reviewed-on: https://chromium-review.googlesource.com/1172912 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by:
-
skia-chromium-autoroll authored
https://skia.googlesource.com/skia.git/+log/32c7d4dfcdca..d19fed1e291d git log 32c7d4dfcdca..d19fed1e291d --date=short --no-merges --format='%ad %ae %s' 2018-08-14 fmalita@chromium.org [skottie] Eliminate some temp SkString allocations 2018-08-14 mtklein@google.com pass sprite opacity to color xform when blitting. Created with: gclient setdep -r src/third_party/skia@d19fed1e291d The AutoRoll server is located here: https://autoroll.skia.org 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. CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel TBR=kjlubick@chromium.org Change-Id: Ib608389718b76c94782e3415bcc82dc607902e82 Reviewed-on: https://chromium-review.googlesource.com/1174793Reviewed-by:
skia-chromium-autoroll <skia-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Commit-Queue: skia-chromium-autoroll <skia-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#583019}
-
Matt Menke authored
Their configuration is now done through a NetworkContextParams object, other than injecting ProtocolHandlers / URLRequestJobInterceptors, and cert verification. This does change behavior in a few ways: Previously, CookieSettings were only partially applied to isolated URLRequestContexts - settings applied through the NetworkDelegate, like blocking cookies, were applied, but settings applied through the QuotaPolicyCookieStore, like making cookies for some sites session-only, were not. This CL makes both types of settings apply to isolated partitions to avoid having separate NetworkContext APIs to configure each subset of cookie behaviors, which are normally keyed off the same set of settings. Also, isolated URLRequestContexts are more independent of the main profile URLRequestContext than they used to be. They only share a cert verifier, and most of the NetworkDelegate, in addition to global objects (HostResolver, AuthHandlerFactory, NQE, NCN, and NetLog), as opposed to sharing everything but NetworkContext, URLRequestJobFactory, CookieStore, DiskCache, and HttpNetworkSession. BUG=847555 Cq-Include-Trybots: luci.chromium.try:linux_mojo Change-Id: Id462de6d71029210a7af7a7ac3fa8f3de896d9d8 Reviewed-on: https://chromium-review.googlesource.com/1153630 Commit-Queue: Matt Menke <mmenke@chromium.org> Reviewed-by:
Dominick Ng <dominickn@chromium.org> Reviewed-by:
Lucas Gadani <lfg@chromium.org> Cr-Commit-Position: refs/heads/master@{#583018}
-
Balazs Engedy authored
Bug: None Change-Id: Ibc16a2c01d1611e44613a0c80b80afb0954183e1 Reviewed-on: https://chromium-review.googlesource.com/1174532 Commit-Queue: Balazs Engedy <engedy@chromium.org> Reviewed-by:
Martin Kreichgauer <martinkr@chromium.org> Reviewed-by:
-
