- 08 Oct, 2020 40 commits
-
-
David Bertoni authored
This CL implements a simple test for chrome.management.get. Bug: 1093066 Change-Id: I536b6eee36bd623d9bc772d1b5a357be69542181 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2441930 Commit-Queue: David Bertoni <dbertoni@chromium.org> Reviewed-by:
Kelvin Jiang <kelvinjiang@chromium.org> Cr-Commit-Position: refs/heads/master@{#815234}
-
Joey Arhar authored
You can tell that the origin trial is enabled and CSS.supports() isn't working as expected because of the document.body.onbeforematch check in the first assert. Bug: 1134237 Change-Id: I992e05dcf3cb0a3d07fcc1aedb1efb67630b9b1a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2447051Reviewed-by:
Jason Chase <chasej@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Auto-Submit: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/master@{#815233}
-
Ievgen Rysai authored
Aside from patching the guard returning nil for anything except static text this change also fixes a few issues that get in a way: - incorrect coordinate space handling (-[BrowserAccessibilityCocoa rectInScreen:] expects its input to be in root frame coordinate space) - redundant (and seemingly wrong) code in `GetInnerTextRangeBoundsRectInSubtree()` that causes incorrect results for text fields. Bug: 1131376 AX-Relnotes: VoiceOver and Zoom now correctly highlight the text in a text field. Change-Id: Ie14be2b0d36c420735397496da78cb1f53e7c26a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2424090 Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org> Reviewed-by:
Abigail Klein <abigailbklein@google.com> Reviewed-by:
Dominic Mazzoni <dmazzoni@chromium.org> Reviewed-by:
Nektarios Paisios <nektar@chromium.org> Cr-Commit-Position: refs/heads/master@{#815232}
-
Justin Cohen authored
Bug: 1127434 Change-Id: I63c5db473c2987eebc3605206eff64aeb4db3490 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2461976 Commit-Queue: Justin Cohen <justincohen@chromium.org> Commit-Queue: Gauthier Ambard <gambard@chromium.org> Auto-Submit: Justin Cohen <justincohen@chromium.org> Reviewed-by:
Gauthier Ambard <gambard@chromium.org> Cr-Commit-Position: refs/heads/master@{#815231}
-
Shakti Sahu authored
Bug: 1117157 Change-Id: Ia7108a2e62dd2b97b4ddd9d806f7dcdc6b1097d5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2447251 Commit-Queue: Shakti Sahu <shaktisahu@chromium.org> Reviewed-by:
Calder Kitagawa <ckitagawa@chromium.org> Cr-Commit-Position: refs/heads/master@{#815230}
-
chromium-autoroll authored
https://chromium.googlesource.com/chromium/tools/depot_tools.git/+log/c267a5583028..acad80a97dc5 2020-10-08 ddoman@chromium.org [resultdb] move cipd pin of rdb If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/depot-tools-chromium-autoroll Please CC ajp@google.com,apolito@google.com,ehmaldonado@google.com,sokcevic@google.com on the revert to ensure that a human is aware of the problem. To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md Bug: chromium:1135892 Tbr: ajp@google.com,apolito@google.com,ehmaldonado@google.com,sokcevic@google.com Change-Id: I18e4ca3de56f465bbbbea32530d4cd65f8442af6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2461962Reviewed-by:
chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com> Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#815229}
-
Owen Min authored
This reverts commit 4d2dee85. Reason for revert: Create the reland to debug Original change's description: > Revert "Resolve the issue by moving PolicyMapAndroid instances in the test so that they can live until the end of tests." > > This reverts commit 6b3c4bdb. > > Reason for revert: Broke PolicyServiceAndroidTest.PolicyUpdateEvent on Android ASAN > https://ci.chromium.org/p/chromium/builders/ci/android-asan/8133 > > Original change's description: > > Add onPolicyUpdate notification in Java. > > > > Support PolicyService::onPolicyUpdate event in Java. Same as other > > functions, only Chrome policies are supported. > > > > Other changes: > > 1) Implement PolicyMap.equals() > > 2) Use ObserverList instead of Set to manage PolicyService's observers. > > > > Bug: 1127469 > > Change-Id: I40c6958e87c746aa40afec306ee632bba52183f6 > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2446639 > > Commit-Queue: Owen Min <zmin@chromium.org> > > Reviewed-by: Sky Malice <skym@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#814310} > > TBR=zmin@chromium.org,skym@chromium.org > > Change-Id: Ibde93e22e01f4d3eb8d9eb2a8d4d9c42166ed191 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: 1127469 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2454653 > Reviewed-by: Vasilii Sukhanov <vasilii@chromium.org> > Commit-Queue: Vasilii Sukhanov <vasilii@chromium.org> > Cr-Commit-Position: refs/heads/master@{#814628} TBR=vasilii@chromium.org,zmin@chromium.org,skym@chromium.org # Not skipping CQ checks because this is a reland. Bug: 1127469 Change-Id: I778a68262809758d9dd5e43bc3ad5accbc1d823c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2458767Reviewed-by:
Owen Min <zmin@chromium.org> Reviewed-by:
Sky Malice <skym@chromium.org> Commit-Queue: Owen Min <zmin@chromium.org> Cr-Commit-Position: refs/heads/master@{#815228}
-
Sylvain Defresne authored
Since https://crrev.com/c/2289856, TabModel stopped observing WebState and _webStateObserver is no longer used. Remove the ivar. Bug: none Change-Id: I1b3b73b69d3bcde06e598ce70a3074f095350869 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2461117 Auto-Submit: Sylvain Defresne <sdefresne@chromium.org> Commit-Queue: David Jean <djean@chromium.org> Reviewed-by:
David Jean <djean@chromium.org> Cr-Commit-Position: refs/heads/master@{#815227}
-
Robbie Gibson authored
When the thumb strip is in hidden or peeked state, the tab switcher button will transition the thumb strip to revealed state. This CL also adds a public method to ViewRevealingVerticalPanHandler to set the state externally. Finally, the CL does not support tapping on the tab switcher button when the thumb strip is in revealed state. This is because the design has the BVC covered in a shim in this state. This hasn't been implemented yet, but the tab switcher button should be inaccessible. Change-Id: Ic44ddd8dc676fbdeb787bc75c422f332a9405574 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2455648 Commit-Queue: Robbie Gibson <rkgibson@google.com> Reviewed-by:
-
Darin Fisher authored
Replicates logic from browser/media/webrtc/desktop_media_list_ash.cc Bug: 1094460 Change-Id: I249b401ff0b6b0fdace0502c27d81b2d2b3ae1d5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2457467Reviewed-by:
James Cook <jamescook@chromium.org> Commit-Queue: Darin Fisher <darin@chromium.org> Cr-Commit-Position: refs/heads/master@{#815225}
-
Shakti Sahu authored
This CL adds : 1 - Summary card IPH, that is shown after all other tutorial IPHs have been tapped by the user. Summary card is treated as a synthetic tutorial available only on NTP. It isn't addded to the actual list of tutorials which shows up elsewhere, e.g. tutorial list page. Tapping on summary card opens up the tutorial list page. 2 - Added remaining IPHs : chrome intro IPH, voice search IPH and their corresponding tutorials/proto at the backend. 3 - Renamed IPH features to be NTP specific since we will have the same tutorial shown on other surfaces as well. The click/dismiss events are kept generic so that they can be shared across NTP and non-NTP IPHs. Bug: 1117186, 1130255 Change-Id: I101b3a69cfa41bfcdbc45264c9f800fa3a0d2f26 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2438778 Commit-Queue: Shakti Sahu <shaktisahu@chromium.org> Reviewed-by:
Tommy Nyquist <nyquist@chromium.org> Reviewed-by:
David Trainor <dtrainor@chromium.org> Reviewed-by:
Brian White <bcwhite@chromium.org> Cr-Commit-Position: refs/heads/master@{#815224}
-
Rahul Singh authored
non-default orientation Problem: When Windows tablet devices are locked in a non-default orientation, the video capture stream is incorrectly rotated. Cause: We always return a camera rotation of 0 when auto-rotation is turned off. For devices locked in non-default orientations this leads to incorrect camera rotation. Fix: This change removes the IsAutoRotationEnabled() check inside GetCameraRotation(). It also adds a new base::Optional<int> member camera_rotation_ in video_capture_device_mf_win.cc and video_capture_device_win.cc. When a frame is received, if camera_rotation_ doesn't have a value OR auto rotation is enabled, we call GetCameraRotation() and cache the non-negative returned value in camera_rotation_. This enables us to calculate and save the correct camera rotation when the first frame is received. Further, if auto rotation is turned off during the capture session, we'll be able to use the cached value to keep the camera correctly rotated. Testing: I added a test in video_capture_device_mf_win_unittest.cc to verify that GetCameraRotation() is called and |camera_rotation_| is populated when MFVideoCallback::OnSample() is invoked. I also tested this change with both a naturally landscape and a naturally portrait Windows tablet device locked in all possible orientations. In each case the camera was correctly rotated. Bug: 1134801 Change-Id: Ib1b6f1a4bb388b1390e5a257686c3b8a417a2a9c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2447036Reviewed-by:
Guido Urdaneta <guidou@chromium.org> Commit-Queue: Rahul Singh <rahsin@microsoft.com> Cr-Commit-Position: refs/heads/master@{#815223}
-
Herb Derby authored
Change-Id: Idb2dcad48973cabe7ea8ac34ed57dc2fca176f9b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2462037Reviewed-by:
Michael Ludwig <michaelludwig@google.com> Commit-Queue: Herb Derby <herb@google.com> Cr-Commit-Position: refs/heads/master@{#815222}
-
George Burgess IV authored
Unless it's guaranteed that `std::forward` always turns into an rvalue ref, using `std::move(x)`, where `x`'s type is a universal reference, is generally unsafe. `std::forward` is preferred for these cases. Bug: 1134310 Change-Id: Ic4d2f59b00c371db343bb1b698cb787d70871b66 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2443513Reviewed-by:
Ryo Hashimoto <hashimoto@chromium.org> Commit-Queue: George Burgess <gbiv@chromium.org> Cr-Commit-Position: refs/heads/master@{#815221}
-
Morten Stenshorne authored
Bug: 294205 Change-Id: I66e357a12e290fa4717db6cb27ef746791d4a167 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2460889Reviewed-by:
Rune Lillesveen <futhark@chromium.org> Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#815220}
-
Morten Stenshorne authored
When compiling with -Wshadow some of their values conflicted with those of FindOptionFlag in core/editing/finder/find_options.h Bug: 294205 Change-Id: I33f3e451f163841ebfce823bdefa3902e7ea0c7b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2460821Reviewed-by:
Kevin Ellis <kevers@chromium.org> Reviewed-by:
-
Morten Stenshorne authored
Bug: 294205 Change-Id: If049d3c91d14c023d1363e27a33f0881c7e1646a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2460892Reviewed-by:
-
Darin Fisher authored
This type is binary compatible with skia.mojom.Bitmap and only serves to specify a difference in the generated bindings. Instead of copying the pixels out of shared memory into a heap allocated buffer retained by the SkBitmap, the bindings will allow the SkBitmap to simply retain the given shared memory buffer. This avoids a potentially large copy. This change leverages SkBitmap's support for having its pixel backing managed externally via SkPixelRef. The BigBuffer received over IPC is stored in a new SkPixelRef subclass. The outcome of this is that if the BigBuffer was using shared memory then the SkBitmap will be able to reference that memory directly, thus avoiding a copy of the pixels. Finally, the Lacros code for screen capture is updated to use this new type to eliminate a large buffer copy. Bug: 1094460 Change-Id: I9249ad40ced16c8cbe42bbbe5d11d9820cc75d7f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2450838Reviewed-by:
Daniel Cheng <dcheng@chromium.org> Reviewed-by:
Ken Rockot <rockot@google.com> Reviewed-by:
Erik Chen <erikchen@chromium.org> Reviewed-by:
Greg Kerr <kerrnel@chromium.org> Commit-Queue: Darin Fisher <darin@chromium.org> Cr-Commit-Position: refs/heads/master@{#815217}
-
Jamie Walch authored
Bug: 1122155 Change-Id: I6653288c9d4d175d8f2e077c67470464f4194829 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2458807 Commit-Queue: Jamie Walch <jamiewalch@chromium.org> Reviewed-by:
Joe Downing <joedow@google.com> Cr-Commit-Position: refs/heads/master@{#815216}
-
Sébastien Séguin-Gagnon authored
Max value was not set to the right value. Also changed to enum class, which would cause the previous situation to not compile. Change-Id: I0476ae21eaac5c3ef52de5bb70af073548333564 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2459691Reviewed-by:
David Bokan <bokan@chromium.org> Commit-Queue: sebsg <sebsg@chromium.org> Cr-Commit-Position: refs/heads/master@{#815215}
-
v8-ci-autoroll-builder authored
Summary of changes available at: https://chromium.googlesource.com/v8/v8/+log/dba8d09f..c8e70787 Please follow these instructions for assigning/CC'ing issues: https://v8.dev/docs/triage-issues Please close rolling in case of a roll revert: https://v8-roll.appspot.com/ This only works with a Google account. CQ_INCLUDE_TRYBOTS=luci.chromium.try:linux-blink-rel CQ_INCLUDE_TRYBOTS=luci.chromium.try:linux_optional_gpu_tests_rel CQ_INCLUDE_TRYBOTS=luci.chromium.try:mac_optional_gpu_tests_rel CQ_INCLUDE_TRYBOTS=luci.chromium.try:win_optional_gpu_tests_rel CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_optional_gpu_tests_rel TBR=hablich@chromium.org,vahl@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I0ba15a1aec65223381a9da2eb8681adb104f34af Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2461567Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#815214}
-
Brian Ho authored
An earlier CL [1] attempted to fix a screen flickering issue with HDR content by expanding the damage rect to the entire frame if the color usage changes (e.g. SDR -> HDR). This fix, however, doesn't work when there is no damage on the frame (besides the color space change) because the expanded damage rect is eventually overwritten via an intersection with the 0-sized damage [2]. When the frame reports no damage, the draw is skipped entirely even though we should really be invalidating everything as per the original CL. This can be reproduced by playing an HDR video on YouTube in a background tab and then mousing over the tab. Chrome will process the HDR video frame in preparation to display the tab preview and the CompositorFrame is marked as "HDR" [4]. After the user mouses off the tab, Chrome will eventually stop processing the HDR video and will send a transitional "empty frame" [5] with an sRGB color space which triggers the problematic 0-damage DrawAndSwap mentioned above. At this point, the user will likely see the screen flicker black because the frame wasn't properly drawn. This CL updates SurfaceAggregator::Aggregate to stop overwriting the full-frame damage if the color space changes. [1] https://chromium-review.googlesource.com/c/chromium/src/+/2369441 [2] https://source.chromium.org/chromium/chromium/src/+/master:components/viz/service/display/surface_aggregator.cc;l=1758;drc=72b4db84824e257c412ac88a4941d12619a44dd2 [3] https://source.chromium.org/chromium/chromium/src/+/master:components/viz/service/display/display.cc;l=726;drc=cf4c5571a11fd0ce94bccbd867c65b75b28350ac [4] https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/platform/graphics/video_frame_submitter.cc;l=614;drc=72b4db84824e257c412ac88a4941d12619a44dd2 [5] https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/platform/graphics/video_frame_submitter.cc;l=388;drc=72b4db84824e257c412ac88a4941d12619a44dd2 Bug: 1132962 Change-Id: I03214c857d804b0a969e05db2853a0a5e9dadbf5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2453802 Commit-Queue: Brian Ho <hob@chromium.org> Reviewed-by:
Daniele Castagna <dcastagna@chromium.org> Cr-Commit-Position: refs/heads/master@{#815213}
-
Oriol Brufau authored
Before r814053, VisiblePosition::Create had a fast path for positions with downstream affinity, always returning the backward canonical position with downstream affinity. But since r814053, that case chooses between the backward canonical position with downstream affinity and the forward canonical position. The code calls InSameLine() in order to decide, but this is slow. So it caused a perf regression in modify-selection.html This patch adds back a fast path for downstream affinity in case the backward and forward canonical positions are equal, which is usual. This fixes the perf regression in modify-selection.html Bug: 1135577 Change-Id: Icb07c25efe8d21c04eb3659292c880af258cf97e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2453291Reviewed-by:
Xiaocheng Hu <xiaochengh@chromium.org> Commit-Queue: Oriol Brufau <obrufau@igalia.com> Cr-Commit-Position: refs/heads/master@{#815212}
-
Corentin Wallez authored
Bug: dawn:445 Change-Id: I60e9a8b240470eeffd62a0da7328a581972800a2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2443150 Commit-Queue: Corentin Wallez <cwallez@chromium.org> Commit-Queue: Austin Eng <enga@chromium.org> Auto-Submit: Corentin Wallez <cwallez@chromium.org> Reviewed-by:
Austin Eng <enga@chromium.org> Cr-Commit-Position: refs/heads/master@{#815211}
-
Fredrik Söderqvist authored
These instances of StylePath/BasicShape/ShadowList are supposed to be immutable, so add const qualifications and drop some then unnecessary const_cast<>s. Change-Id: I1a6ca8ec9c45dac757a45882129f91f745745023 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2460894Reviewed-by:
Robert Flack <flackr@chromium.org> Commit-Queue: Fredrik Söderquist <fs@opera.com> Cr-Commit-Position: refs/heads/master@{#815210}
-
Corentin Wallez authored
These tests were written prior to the group agreeing on the exact rules, disable them until they are updated so Dawn's validation can be updated to match the upstream WebGPU spec. Bug: dawn:542 Change-Id: I3c66d46c669a5c9ab61b057d0f049b4a63c073ee Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2461275 Auto-Submit: Corentin Wallez <cwallez@chromium.org> Commit-Queue: Austin Eng <enga@chromium.org> Reviewed-by:
-
Yifan Luo authored
Bug: 1116418 Change-Id: Id58d7f0478abb73619d5077d9024800bd7b83c15 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2461331Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Commit-Queue: Yifan Luo <lyf@chromium.org> Cr-Commit-Position: refs/heads/master@{#815208}
-
chromium-autoroll authored
https://chromium.googlesource.com/chromiumos/chromite.git/+log/c90bac4197a4..8ce5f5261ab7 2020-10-08 saklein@chromium.org controller/test: Refactor SplitCPV to parse. 2020-10-08 saklein@chromium.org image: Refactor SplitCPV to parse. 2020-10-08 saklein@chromium.org controller/dependency: Refactor SplitCPV usages. 2020-10-08 saklein@chromium.org android: refactor SplitCPV to parse. 2020-10-07 tcwang@google.com afdo: Rename CWP profiles 2020-10-07 saklein@chromium.org controller_util: Add PackageInfo serialization. 2020-10-07 saklein@chromium.org cbuildbot_run: Refactor SplitCPV to parse. If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/chromite-chromium-autoroll Please CC chrome-os-gardeners@google.com on the revert to ensure that a human is aware of the problem. To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md Cq-Include-Trybots: luci.chrome.try:chromeos-betty-pi-arc-chrome;luci.chromium.try:chromeos-kevin-rel Tbr: chrome-os-gardeners@google.com Change-Id: Iecf720ba9601adddaf012dd1ec90d0b6bef7fbe8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2461430Reviewed-by:
-
Jeffrey Young authored
This is a reland of 581c91ec Original change's description: > ambient: start when two images loaded > > Construct ambient widget when two images are in memory to prevent burn > in. > > BUG=b:167332126 > > Cq-Include-Trybots: luci.chrome.try:linux-chromeos-chrome > Change-Id: I520ada00429125d35bda9ef66089ca9a9c8d4440 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2440306 > Commit-Queue: Jeffrey Young <cowmoo@chromium.org> > Reviewed-by: Tao Wu <wutao@chromium.org> > Reviewed-by: Xiaohui Chen <xiaohuic@chromium.org> > Cr-Commit-Position: refs/heads/master@{#814711} Bug: b:167332126 Change-Id: I7fe0cca3ecb15262666eee1067f57bc21b150468 Cq-Include-Trybots: luci.chrome.try:linux-chromeos-chrome Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2459399Reviewed-by:
Xiaohui Chen <xiaohuic@chromium.org> Commit-Queue: Jeffrey Young <cowmoo@chromium.org> Cr-Commit-Position: refs/heads/master@{#815206}
-
chromium-autoroll authored
https://dawn.googlesource.com/dawn.git/+log/6b4a4a85dfd7..33a0deb815ce 2020-10-08 dawn-autoroll@skia-public.iam.gserviceaccount.com Roll Tint from 28ae1471bf2c to 66377ce9be54 (1 revision) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/dawn-chromium-autoroll Please CC kainino@google.com on the revert to ensure that a human is aware of the problem. To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md Cq-Include-Trybots: luci.chromium.try:dawn-linux-x64-deps-rel;luci.chromium.try:dawn-mac-x64-deps-rel;luci.chromium.try:dawn-win10-x64-deps-rel;luci.chromium.try:dawn-win10-x86-deps-rel Bug: None Tbr: kainino@google.com Change-Id: I322727c8bb68d7e571c639892cf1270b2f23c95d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2461957Reviewed-by:
-
Justin Cohen authored
GetNavigationItemImplAtIndex() appears to return a nil |cached_item| sometimes, perhaps due to a mismatch in WKWebView's backForwardList. Returning early when this happens in RestoreItemsState() may break some restore state features, but should not put the user in a broken state. Bug: 1134096 Change-Id: I47a2f1316375860b223fa988e7aca9e4557057d0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2454291Reviewed-by:
Ali Juma <ajuma@chromium.org> Reviewed-by:
-
Dave Tapuska authored
PointerLock allow/disallow use to be emulated from the renderer side. There was a unique thing that web_tests treated exiting pointer lock as asynchronous where it really is synchronous. ie. The callback DidLosePointerLock was called via a PostTask but under the normal browser flow it is not. This required some adjustments to the tests to bring them in line with the browser implementation. This change is necessary since the WebWidget overrides for pointer lock are going away with RenderWidget removal. BUG=1097816 Change-Id: Icc58ca6de405308bffb50945b5b828691ff9f2a2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2453913Reviewed-by:
Avi Drissman <avi@chromium.org> Reviewed-by:
danakj <danakj@chromium.org> Commit-Queue: Dave Tapuska <dtapuska@chromium.org> Cr-Commit-Position: refs/heads/master@{#815203}
-
Peter Kotwicz authored
This CL fixes the data deps in //chrome/android/monochrome:monochrome_apk_checker BUG=1115604 TBR=agrieve (CL is subset of https://crrev.com/c/2460714) Change-Id: Iaf838095b13b08872ad52c99480bc0f0b34c8a95 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2460756Reviewed-by:Peter Kotwicz <pkotwicz@chromium.org> Commit-Queue: Peter Kotwicz <pkotwicz@chromium.org> Cr-Commit-Position: refs/heads/master@{#815202}
-
Joe Mason authored
These classes will soon return memory usage of workers as well as frames. This matches the name of the mojo interface in third_party/blink/public/mojom/performance_manager/v8_detailed_memory_reporter.mojom. Also renames v8_per_frame_memory_decorator* to v8_detailed_memory*. A followup will split these classes into separate header files since v8_detailed_memory.h is large enough to be unwieldy, and move V8DetailedMemoryDecorator into a private file since it doesn't need to be part of the public interface. Bug: 1080672 Change-Id: I1c17e8bb1d6ee7d77638116495ba6ed8b5e4a4bb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2453894 Commit-Queue: Joe Mason <joenotcharles@chromium.org> Reviewed-by:
François Doray <fdoray@chromium.org> Reviewed-by:
John Delaney <johnidel@chromium.org> Cr-Commit-Position: refs/heads/master@{#815201}
-
Joel Hockey authored
It seems that web_contents may be destroyed during RunArcExternalProtocolDialog (See TODO comment in the code). See crashes in crbug.com/1136237 So rather than bind web_contents directly into OnArcHandled(), we use render_process_host_id and routing_id to look it up at the end as was happening in ShowFallbackEternalProtocolDialog() prior to crrev.com/c/2423067. Bug: 1136237 Change-Id: If0bc1287f9eedbf2b915cd97e049a19f379254ec Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2460067 Commit-Queue: Xiyuan Xia <xiyuan@chromium.org> Reviewed-by:
Xiyuan Xia <xiyuan@chromium.org> Auto-Submit: Joel Hockey <joelhockey@chromium.org> Cr-Commit-Position: refs/heads/master@{#815200}
-
Omar Morsi authored
This CL extracts platform keys service function execution waiters and the scoped softoken key attributes mapping implementation into a separate test util file so as it can be used by key permissions manager later. Bug: 1127284 Change-Id: Iff156918660e6eb2340a27c3f4e3ddd2ab6c6e9b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2456787Reviewed-by:
Pavol Marko <pmarko@chromium.org> Commit-Queue: Omar Morsi <omorsi@google.com> Cr-Commit-Position: refs/heads/master@{#815199}
-
Peng Huang authored
For some devices, the hardwarerotation doesn't work with SurfaceControl, so disable it for now. Bug: 1136033 Change-Id: Id1ed7971d50ec815fd315fb728315f05e6be9637 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2461550 Auto-Submit: Peng Huang <penghuang@chromium.org> Commit-Queue: Jonathan Backer <backer@chromium.org> Reviewed-by:
Jonathan Backer <backer@chromium.org> Cr-Commit-Position: refs/heads/master@{#815198}
-
chromium-autoroll authored
https://chromium.googlesource.com/devtools/devtools-frontend.git/+log/8a7ceda7a71f..11ac723021d5 2020-10-08 jacktfranklin@chromium.org Make MutationHelpers node type generic 2020-10-08 bmeurer@chromium.org Fix consistent typing of ScopeChainEntry vs. Scope. 2020-10-08 szuend@chromium.org [ts] Type-check network/RequestHTMLView.js with TypeScript 2020-10-08 szuend@chromium.org [ts] Remove unnecessary @ts-nocheck from RequestPreviewView.js If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/devtools-frontend-chromium Please CC devtools-waterfall-sheriff-onduty@grotations.appspotmail.com on the revert to ensure that a human is aware of the problem. To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md Bug: chromium:1011811,chromium:1042636 Tbr: devtools-waterfall-sheriff-onduty@grotations.appspotmail.com Change-Id: I66a73c1ce5fb4576e226dfe20994ad813c8967f5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2461404Reviewed-by:
-
Elly Fong-Jones authored
Bug: 1075649 Change-Id: I340b9a7c0b1dc00122c4cf893b64ac83b425e358 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2459050Reviewed-by:
-
Adam Langley authored
Previously all caBLE (v1 and v2) adverts were a single, 16-byte UUID. It was encrypted with AES and the receiver checked that certain bits were zero to confirm a correct decryption. caBLEv1 has 64 zero bits and v2 ended up with 18. Since the caBLEv2 advert was so tight, this change adds another 4-byte UUID to save some space for later. That 4-byte UUID contains an HMAC authenticator over the encrypted 16-byte UUID, both adding 14 bits of rejection power and freeing up the previous 18 bits for future use. Thus, in caBLEv2, "EIDs" are now the plaintext 16 bytes and "adverts" are the encryption of EIDs which expands them to 20 bytes. Since BLE stacks might add other UUIDs, all combinations of 16- and 4-byte UUIDs are considered as adverts on the receive side. Additionally, 4-byte UUIDs might actually end up as 2-byte UUIDs if they have 16 bits that matches the magic suffix. Thus 2-byte UUIDs are treated as if they were 4-byte ones. BUG=1002262 Change-Id: I6d46136d1a6e09edd1680b459621731c8358327d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2453920 Commit-Queue: Adam Langley <agl@chromium.org> Reviewed-by:
Martin Kreichgauer <martinkr@google.com> Cr-Commit-Position: refs/heads/master@{#815195}
-
