- 08 Dec, 2020 40 commits
-
-
Daniel Vogelheim authored
Fix-it week: Fix failing WPT test. Change-Id: I3bf43d39f19bc9b690bb943185e7ddb8961699da Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2574951Reviewed-by:
Yifan Luo <lyf@chromium.org> Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#834636}
-
Daniel Vogelheim authored
Fix-It week: The test passes, but will then report an error in the test harness, because the string chosen for the example test is not actually a valid script. If we simply return "0" - which is valid JS - the bug disappears. (The test doesn't care about the script anyhow, only about whether it's accepted as input ot not.) Change-Id: Ie36c27965494f71b796176d3818aefd41b3067ab Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2574953Reviewed-by:
-
Side Yilmaz authored
This CL passes the correct profile in LayerTitleCache by accessing profile with tab#isIncognito boolean. Bug: 1048632 Change-Id: I9555f637a890ea5052ac044667d953d221d0f84a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2567226Reviewed-by:
David Trainor <dtrainor@chromium.org> Commit-Queue: Side YILMAZ <sideyilmaz@chromium.org> Cr-Commit-Position: refs/heads/master@{#834634}
-
Balazs Engedy authored
This reverts commit 09825450. Reason for revert: `generate_build_files` failure on `Cast Audio Linux` builder: ERROR at //ui/gfx/linux/BUILD.gn:8:1: Assertion failed. assert(use_x11 || ozone_platform_drm || ozone_platform_wayland || ^----- See //media/gpu/chromeos/BUILD.gn:92:5: which caused the file to be included. "//ui/gfx/linux:drm", ^------------------- Original change's description: > media/platform_vf_utils: Handle null GMB factory. > > This CL handles a null GpuMemoryBufferFactory in > AllocateGpuMemoryBufferHandle() so that the caller is not obligated to > pass a valid factory. This is in preparation for follow-ups CLs to > remove the need for video encode accelerators to have access to a > GpuMemoryBufferFactory. > > When the GpuMemoryBufferFactory is null, we just use the render node > directly to allocate a native buffer object and then we wrap it into a > GpuMemoryBufferHandle. > > So, why do we still keep the option to have a non-null > GpuMemoryBufferFactory? This is because that path is still useful in the > decoding case: when a buffer is created with the GpuMemoryBufferFactory, > the corresponding NativePixmap is cached [1]; eventually, a SharedImage > needs to be created and to do so we pass the GpuMemoryBufferHandle > obtained from the factory [2]; when the SharedImage system needs to > create the GLImage for the buffer, it passes the handle to the > factory [3] which in turn uses it to look up the cached > NativePixmap [4]. This saves us from going through a gbm_bo_import() > (which also implies a thread hop to the DRM thread). > > So, in conclusion, for buffers that need to be displayed later, it's > still better to use the GMB factory owned by the GpuServiceImpl. For > encoders this is not the case. > > [1] https://source.chromium.org/chromium/chromium/src/+/master:gpu/ipc/service/gpu_memory_buffer_factory_native_pixmap.cc;l=319;drc=d81c5852498699fe3cd812e78d31c77c28e29281 > [2] https://source.chromium.org/chromium/chromium/src/+/master:media/gpu/chromeos/mailbox_video_frame_converter.cc;l=355-359;drc=d81c5852498699fe3cd812e78d31c77c28e29281 > [3] https://source.chromium.org/chromium/chromium/src/+/master:gpu/command_buffer/service/shared_image_backing_gl_texture.cc;l=355-356;drc=d81c5852498699fe3cd812e78d31c77c28e29281 > [4] https://source.chromium.org/chromium/chromium/src/+/master:gpu/ipc/service/gpu_memory_buffer_factory_native_pixmap.cc;l=164-172;drc=d81c5852498699fe3cd812e78d31c77c28e29281 > > Bug: b:173167846 > Test: video.EncodeAccel.h264_720p_nv12_dmabuf on elm > Change-Id: I7b730eb843da7503c61bffe30dce7a5ce51dec60 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2568937 > Commit-Queue: Andres Calderon Jaramillo <andrescj@chromium.org> > Reviewed-by: Miguel Casas <mcasas@chromium.org> > Reviewed-by: Hirokazu Honda <hiroh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#834608} TBR=mcasas@chromium.org,hiroh@chromium.org,andrescj@chromium.org,chromium-scoped@luci-project-accounts.iam.gserviceaccount.com Change-Id: Ibaf9e8a6e473a3b566ee9d5dd45b25a5f5283c14 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: b:173167846 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2578836Reviewed-by:
Balazs Engedy <engedy@chromium.org> Commit-Queue: Balazs Engedy <engedy@chromium.org> Cr-Commit-Position: refs/heads/master@{#834633}
-
chromium-autoroll authored
https://chromium.googlesource.com/devtools/devtools-frontend.git/+log/2d4ece529113..7843c257dbae 2020-12-08 tvanderlippe@chromium.org Upgrade third_party/marked to 1.2.5 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: None Tbr: devtools-waterfall-sheriff-onduty@grotations.appspotmail.com Change-Id: I5d9c8cb370d91797d70b3265a11e784701dc0386 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2578777Reviewed-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@{#834632}
-
Yu Su authored
Add UKM logging for Lens chip shown and action: - record Lens chip shown event in the context menu metric "ContextMenuAndroid.Shown" - record Lens chip action in the context menu metric "ContextMenuAndroid.Selected" with an action id ShopWithGoogleLensChip Add an UMA histogram for Lens Prime errors: - The histogram is used to record errors occurred in Lens Prime session processing. https://chrome-internal-review.googlesource.com/c/clank/internal/apps/+/3412247 - The error codes are integer constants defined by the Lens SDK. Change-Id: Ibfa4134ee2d29b1d010654c7762bc820eb528ad4 Bug: b/166648354 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2551256 Commit-Queue: Yu Su <yusuyoutube@google.com> Reviewed-by:
Theresa <twellington@chromium.org> Reviewed-by:
Ben Goldberger <benwgold@google.com> Reviewed-by:
Steven Holte <holte@chromium.org> Reviewed-by:
Sinan Sahin <sinansahin@google.com> Cr-Commit-Position: refs/heads/master@{#834631}
-
Nohemi Fernandez authored
Currently the SigninPromoViewMode uses implicit naming scheme cold/warm to represent the sign-in state. With the addition of a sync promo it becomes necessary to be more precise with the state of accounts on the device that will be represented in this enum. Bug: 1151289 Change-Id: I88e7e940ce8248c4b6f3d6e03c916f6ed5866df9 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2574737Reviewed-by:
Sylvain Defresne <sdefresne@chromium.org> Reviewed-by:
Jérôme Lebel <jlebel@chromium.org> Commit-Queue: Nohemi Fernandez <fernandex@chromium.org> Cr-Commit-Position: refs/heads/master@{#834630}
-
Camillo Bruni authored
Delay calling into V8 for detected the topmost script. Crossing the API and getting a stack trace can be avoided in many case. This has a measurable impact on Speedometer. Bug: 808503 Change-Id: I6ed1b8734056ecb2efd55cf83f1d7a3302690f52 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2571091Reviewed-by:
Kouhei Ueno <kouhei@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#834629}
-
Morten Stenshorne authored
TBR=ikilpatrick@chromium.org Bug: 1156312 Change-Id: I1885dfb7c9b437bc78f80b0b833388981a4a75e3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2577467Reviewed-by:
Morten Stenshorne <mstensho@chromium.org> Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#834628}
-
Jérémie Boulic authored
Update modules generation script: - Fix detection of duplicate dependencies - Update class export condition: export class if the class is used in another JS file - Fix clang-format off/on Bug: 1133186 Change-Id: Icb5b38f8d57ca69912397b489b8e49dd23e1b8b2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2575303Reviewed-by:
Luciano Pacheco <lucmult@chromium.org> Commit-Queue: Jeremie Boulic <jboulic@chromium.org> Cr-Commit-Position: refs/heads/master@{#834627}
-
David Jean authored
TBR=stkhapugin@chromium.org Bug: 1156541 Change-Id: Ic0d27facc25b67778ace7c21d3cd5c4adcaf74da Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2577681Reviewed-by:
David Jean <djean@chromium.org> Commit-Queue: David Jean <djean@chromium.org> Auto-Submit: David Jean <djean@chromium.org> Cr-Commit-Position: refs/heads/master@{#834626}
-
Victor Costan authored
make_heap is linear in the size of the input, not logarithmic. Change-Id: I88a7c78bfdae4c7dfd09efa433febc6ffdd2d9a2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2577034Reviewed-by:
Jan Wilken Dörrie <jdoerrie@chromium.org> Commit-Queue: Victor Costan <pwnall@chromium.org> Cr-Commit-Position: refs/heads/master@{#834625}
-
Keishi Hattori authored
Bug: 1080832 Change-Id: Ifb7f704416ec9e993f1c180a3a72a76b7ffb2452 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2578417Reviewed-by:
Bartek Nowierski <bartekn@chromium.org> Reviewed-by:
Kentaro Hara <haraken@chromium.org> Reviewed-by:
Takashi Sakamoto <tasak@google.com> Commit-Queue: Bartek Nowierski <bartekn@chromium.org> Cr-Commit-Position: refs/heads/master@{#834624}
-
James Vecore authored
This is a mechanical change to move the nearby-progress Polymer component from being chrome://nearby (Poylmer3) only to being shared with chrome://os-settings (Polymer2/3). This necessary for Nearby Share's launch despite Polymer2 being phased out (the conversion won't be complete in time for M-89 launch). Bug: 1156035 Change-Id: Iff63927d43215dbcab4325c5794c792fed1550df Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2575947 Commit-Queue: James Vecore <vecore@google.com> Reviewed-by:
Kyle Horimoto <khorimoto@chromium.org> Cr-Commit-Position: refs/heads/master@{#834623}
-
Luciano Pacheco authored
Bug: 1133186 Change-Id: Ifc81fa000fa91a69e8eed2450b9d8fbe4c61dd7a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2576859 Commit-Queue: Luciano Pacheco <lucmult@chromium.org> Commit-Queue: Jeremie Boulic <jboulic@chromium.org> Reviewed-by:
Jeremie Boulic <jboulic@chromium.org> Cr-Commit-Position: refs/heads/master@{#834622}
-
Anastasiia N authored
Add a 'Don't remind me again' checkbox to the welcome page. Screenshot: http://screen/7mZimAEabQv5agq.png Bug: 1144114 Change-Id: Ib0f5cb1b429d84da982fd239c0afb0ff933d010d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2549764Reviewed-by:
Rebekah Potter <rbpotter@chromium.org> Reviewed-by:
Kush Sinha <sinhak@chromium.org> Commit-Queue: Anastasiia N <anastasiian@chromium.org> Cr-Commit-Position: refs/heads/master@{#834621}
-
Jesse McKenna authored
This change makes PWA-launcher update work for BMO web apps. Currently, PWA launchers are updated by iterating over the ExtensionRegistry and filtering to bookmark extensions. Since M85, BMO is the default, meaning web apps are no longer bookmark apps and have their own registry: the AppRegistrar. With this change, PWA-launcher update iterates over apps in the AppRegistrar. Bug: 1137573 Change-Id: If30e665eb7999e4e7145fa66bbda31eb98631fb1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2514079 Commit-Queue: Jesse McKenna <jessemckenna@google.com> Reviewed-by:
Filip Gorski <fgorski@chromium.org> Reviewed-by:
Alan Cutter <alancutter@chromium.org> Cr-Commit-Position: refs/heads/master@{#834620}
-
Wolfgang Beyer authored
frontend CL: https://crrev.com/c/2519702 tests disabled in: https://crrev.com/c/2552595 Bug: chromium:1140540, chromium:1140481 Change-Id: Ifed10e8668a8634c88fc9a0b854cf804bb892bc5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2553549 Commit-Queue: Wolfgang Beyer <wolfi@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Andrey Kosyakov <caseq@chromium.org> Cr-Commit-Position: refs/heads/master@{#834619}
-
chromium-autoroll authored
Roll Chrome Mac PGO profile from chrome-mac-master-1607385573-20176c861cfdd390234dbdfc41d000ee505c292a.profdata to chrome-mac-master-1607407031-63b5db867e1f1fedbce39b6034a36fb366360e89.profdata If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/pgo-mac-chromium Please CC pgo-profile-sheriffs@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:mac-chrome Tbr: pgo-profile-sheriffs@google.com Change-Id: Ie9a8ccd0f09b3c28db28751f5db93b8c6127cb51 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2578657Reviewed-by:
-
chromium-autoroll authored
https://chromium.googlesource.com/devtools/devtools-frontend.git/+log/2b3b0f567d42..2d4ece529113 2020-12-08 yoichio@chromium.org Protocol update 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:1152290 Tbr: devtools-waterfall-sheriff-onduty@grotations.appspotmail.com Change-Id: Ia6a102077508dc7b3076f0d71cbcdf2bdfa3ed53 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2578656Reviewed-by:
-
James Vecore authored
This is a mechanical change to move the nearby-device Polymer component from being chrome://nearby (Poylmer3) only to being shared with chrome://os-settings (Polymer2/3). This necessary for Nearby Share's launch despite Polymer2 being phased out (the conversion won't be complete in time for M-89 launch). Bug: 1156035 Change-Id: Ib19d6db0b0a53a55eea5e2899880e2592cfb810f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2575944 Commit-Queue: James Vecore <vecore@google.com> Reviewed-by:
-
Wei Lee authored
We should: 1. When calling window operations from tests, we should be able to wait for the operation done 2. If calling window.maximize() while the window is already maximized, trigger the callback immediately. Same for other operations. 3. For devices under tablet mode, since no change will happen when calling restore() while the window is maximized, handle it more properly. Bug: b/172780736 Test: tast run [DUT] camera.CCAUIRecordVideo.swa Change-Id: I91f47e98c5857eb59775045849233d7541d2c603 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2574117Reviewed-by:
Inker Kuo <inker@chromium.org> Commit-Queue: Wei Lee <wtlee@chromium.org> Auto-Submit: Wei Lee <wtlee@chromium.org> Cr-Commit-Position: refs/heads/master@{#834615}
-
Luciano Pacheco authored
Bug: 1133186 Change-Id: Icf9d3a1594affa6647544910241c989d86477b6b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2576858 Auto-Submit: Luciano Pacheco <lucmult@chromium.org> Reviewed-by:
-
Raphael Kubo da Costa authored
Those tests were disabled in commit 46327ef9 ("Temporarily disable web tests that use the legacy Protocol global") but were never enabled again. Adapt to changes that have happened in devtools-frontend and Chromium since then: * Rename Protocol to ProtocolClient <https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2107558> * Update expectations and trim error messages in report-protocol-errors.js <https://chromium-review.googlesource.com/c/chromium/src/+/2254707> screen-orientation-override.js was kept in TestExpectations because it is still timing out due to other setDeviceMetricsOverride()-related changes. Bug: 1011811 Change-Id: I7f0847827dd4ff28bcb646df684039accf7b56f4 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2575117 Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> Auto-Submit: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#834613}
-
Nektarios Paisios authored
Workaround for bug in NGInlineOffsetMappingBuilder whereby it does not assign mapping units to empty LayoutText objects When using legacy layout, NGInlineOffsetMappingBuilder computes the text offset mappings fon demand and caches them in the layout object's rare data. However, due to a bug in that computation, empty LayoutText objects are not given a corresponding OffsetMappingUnit in the list of offset mappings causing a crash. This workaround ignores such objects for now, returning the best possible value, until NGInlineOffsetMappingBuilder is fixed to handle this situation. AX-Relnotes: n/a. R=dmazzoni@chromium.org, aleventhal@chromium.org Bug: 1149171 Change-Id: I7a59f924cf94d0b40ca47cbe2be402b3fe68addd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2578098 Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org> Reviewed-by:
Dominic Mazzoni <dmazzoni@chromium.org> Cr-Commit-Position: refs/heads/master@{#834612}
-
chromium-autoroll authored
Roll Chrome Linux PGO profile from chrome-linux-master-1607385573-c353d00fc8fe8bd6d284b3c59bd857ed5fa10770.profdata to chrome-linux-master-1607407031-3aa7c176f7320c5baa78db92893fe31481ff0a44.profdata If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/pgo-linux-chromium Please CC pgo-profile-sheriffs@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:linux-chrome Tbr: pgo-profile-sheriffs@google.com Change-Id: I550aad8707e50b2a9d90b72f1b29c152bf95782b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2578477Reviewed-by:
-
chromium-autoroll authored
If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/fuchsia-aemu-chromium-autoroll Please CC chrome-fuchsia-gardener@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 Tbr: chrome-fuchsia-gardener@grotations.appspotmail.com Change-Id: If7f5897b69d02f15ab9a32eb075f9804c648916a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2577015Reviewed-by:
-
James Vecore authored
This is a mostly mechanical change to move the nearby-device-icon Polymer component from being chrome://nearby (Poylmer3) only to being shared with chrome://os-settings (Polymer2/3). This necessary for Nearby Share's launch despite Polymer2 being phased out (the conversion won't be complete in time for M-89 launch). A Few other small changes were necessary: - Fixed a copy/paste issue with resource_path_rewrites - Make the nearby_share/shared folder CrOS only. There was still a lingering referenced to the closure compiler targets that were not CrOS only. - Refactored browser test to not use the mojo interfaces from a const expression (necessary for Polymer2). - Copied icons from icons to the existing shared icon set (old icons will be cleaned up in a follow up CL. Bug: 1156035 Change-Id: Ic913ca66e814097524ebf29fd7eb0c89aad82d68 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2571804 Commit-Queue: James Vecore <vecore@google.com> Reviewed-by:
-
Andres Calderon Jaramillo authored
This CL handles a null GpuMemoryBufferFactory in AllocateGpuMemoryBufferHandle() so that the caller is not obligated to pass a valid factory. This is in preparation for follow-ups CLs to remove the need for video encode accelerators to have access to a GpuMemoryBufferFactory. When the GpuMemoryBufferFactory is null, we just use the render node directly to allocate a native buffer object and then we wrap it into a GpuMemoryBufferHandle. So, why do we still keep the option to have a non-null GpuMemoryBufferFactory? This is because that path is still useful in the decoding case: when a buffer is created with the GpuMemoryBufferFactory, the corresponding NativePixmap is cached [1]; eventually, a SharedImage needs to be created and to do so we pass the GpuMemoryBufferHandle obtained from the factory [2]; when the SharedImage system needs to create the GLImage for the buffer, it passes the handle to the factory [3] which in turn uses it to look up the cached NativePixmap [4]. This saves us from going through a gbm_bo_import() (which also implies a thread hop to the DRM thread). So, in conclusion, for buffers that need to be displayed later, it's still better to use the GMB factory owned by the GpuServiceImpl. For encoders this is not the case. [1] https://source.chromium.org/chromium/chromium/src/+/master:gpu/ipc/service/gpu_memory_buffer_factory_native_pixmap.cc;l=319;drc=d81c5852498699fe3cd812e78d31c77c28e29281 [2] https://source.chromium.org/chromium/chromium/src/+/master:media/gpu/chromeos/mailbox_video_frame_converter.cc;l=355-359;drc=d81c5852498699fe3cd812e78d31c77c28e29281 [3] https://source.chromium.org/chromium/chromium/src/+/master:gpu/command_buffer/service/shared_image_backing_gl_texture.cc;l=355-356;drc=d81c5852498699fe3cd812e78d31c77c28e29281 [4] https://source.chromium.org/chromium/chromium/src/+/master:gpu/ipc/service/gpu_memory_buffer_factory_native_pixmap.cc;l=164-172;drc=d81c5852498699fe3cd812e78d31c77c28e29281 Bug: b:173167846 Test: video.EncodeAccel.h264_720p_nv12_dmabuf on elm Change-Id: I7b730eb843da7503c61bffe30dce7a5ce51dec60 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2568937 Commit-Queue: Andres Calderon Jaramillo <andrescj@chromium.org> Reviewed-by:
Miguel Casas <mcasas@chromium.org> Reviewed-by:
Hirokazu Honda <hiroh@chromium.org> Cr-Commit-Position: refs/heads/master@{#834608}
-
Jimmy Gong authored
Fixed: 1155244 Change-Id: I6d2e0789d3ba517b451f71f3cfe0aae09c27dcae Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2577859 Commit-Queue: Jimmy Gong <jimmyxgong@chromium.org> Reviewed-by:
-
Archie Pusaka authored
BlueZ's device UUIDs property could return either the service UUIDs or the advertised UUIDs (not both), depends on whether the service UUIDs are resolved. Unfortunately there is no simple way to detect which of the two sets of UUIDs are returned. This CL separates the UUIDs tracking. The advertised UUIDs can be retrieved by reading the EIR data, therefore we can treat the UUIDs property as the service UUIDs. In the end, both are merged so a call to GetUUIDs() would get both the service and advertised UUIDs. Bug: b:172359553 Change-Id: I7de6f0c47f3799265b833c4b3be3da84bdf0e458 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2560347 Commit-Queue: Archie Pusaka <apusaka@chromium.org> Reviewed-by:
Reilly Grant <reillyg@chromium.org> Reviewed-by:
Sonny Sasaka <sonnysasaka@chromium.org> Cr-Commit-Position: refs/heads/master@{#834606}
-
Kunihiko Sakamoto authored
This allows the urn: scheme in WebBundles' inner URLs, in addition to http and https. Bug: 1082020 Change-Id: I5582444e6d4f6ab29b83045a3d37a13f078071db Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2578300Reviewed-by:
Hayato Ito <hayato@chromium.org> Reviewed-by:
Kinuko Yasuda <kinuko@chromium.org> Commit-Queue: Kunihiko Sakamoto <ksakamoto@chromium.org> Cr-Commit-Position: refs/heads/master@{#834605}
-
chromium-internal-autoroll authored
https://chrome-internal.googlesource.com/chrome/src-internal.git/+log/8ae45db84a78..03c2a0ffe52f If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://skia-autoroll.corp.goog/r/src-internal-chromium-autoroll Please CC nancylingwang@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:linux-chromeos-chrome Bug: None Tbr: nancylingwang@google.com Change-Id: I0ec24e4d7dddd5f0650ffacb4bc909b6d95c607e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2578400Reviewed-by:
chromium-internal-autoroll <chromium-internal-autoroll@skia-corp.google.com.iam.gserviceaccount.com> Commit-Queue: chromium-internal-autoroll <chromium-internal-autoroll@skia-corp.google.com.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#834604}
-
CQ_INCLUDE_TRYBOTS=luci.chrome.try:chromeos-betty-pi-arc-chrome CQ_INCLUDE_TRYBOTS=luci.chrome.try:chromeos-eve-chrome CQ_INCLUDE_TRYBOTS=luci.chrome.try:chromeos-kevin-chrome TBR=chrome-os-gardeners@google.com Change-Id: I87bc100b3176828efe96261036f832025a478cb6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2578258Reviewed-by:
ChromeOS bot <3su6n15k.default@developer.gserviceaccount.com> Commit-Queue: ChromeOS bot <3su6n15k.default@developer.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#834603}
-
Wei Lee authored
Originally, we cancel intent in window unload listener when closing CCA. However, the the callback of the cancel() method is triggered, the connection between CCA and Chrome might already be tore down. This CL moves the logic to Chrome for SWA version. For platform app version, it still cancels the intent in background page. Bug: b/172337144 Test: tast run [DUT] camera.CCAUIIntent.swa Change-Id: I8362242ad4990aeda947061f756bf35ecf8bf736 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2573261 Commit-Queue: Wei Lee <wtlee@chromium.org> Reviewed-by:
Shik Chen <shik@chromium.org> Cr-Commit-Position: refs/heads/master@{#834602}
-
Joel Hockey authored
Change-Id: I834bd899ae782e33feaf6f7dee2eb219272f579b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2578578 Commit-Queue: Joel Hockey <joelhockey@chromium.org> Commit-Queue: Noel Gordon <noel@chromium.org> Auto-Submit: Joel Hockey <joelhockey@chromium.org> Reviewed-by:
Noel Gordon <noel@chromium.org> Cr-Commit-Position: refs/heads/master@{#834601}
-
chromium-autoroll authored
https://chromium.googlesource.com/angle/angle.git/+log/8b4990bbd621..e59d8716b300 2020-12-08 syoussefi@chromium.org GL: Expose OES_shader_io_blocks If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/angle-chromium-autoroll Please CC syoussefi@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: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-asan;luci.chromium.try:win_optional_gpu_tests_rel;luci.chromium.try:linux-swangle-try-x64;luci.chromium.try:win-swangle-try-x86 Bug: None Tbr: syoussefi@google.com Change-Id: I9460d9c484f0197fc66ebb48321d93f5fd1835fe Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2578440Reviewed-by:
-
Antonio Sartori authored
In the Blink Content Security Policy code, we switch from using the internal blink type blink::CSPSource to using the mojo type network::mojom::blink::CSPSource for handling CSP source expressions. This is part of a project to harmonize the CSP code in Blink and in services/network, and will make it easier to synchronize Content Security Policies between the two. Change-Id: If7769b321934ee73cf1aa0faa6d8b371360684a7 Bug: 1021462,1149272 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2412339Reviewed-by:
Mike West <mkwst@chromium.org> Reviewed-by:
Arthur Sonzogni <arthursonzogni@chromium.org> Commit-Queue: Antonio Sartori <antoniosartori@chromium.org> Cr-Commit-Position: refs/heads/master@{#834599}
-
Marijn Kruisselbrink authored
This is a reland of 2d41c395 The added test was modified to no longer assert that all unsafe files were written to disk successfully. This should make the test pass (albeit with less stringent checks) on file systems/platforms that don't allow all unsafe file names. Original change's description: > Reland "[FSA] Add IsSafePathComponent checks to GetFile/GetDirectoryHandle." > > This is a reland of 00437792 > > The main difference is to make sure iterating over a directory doesn't > return files we don't want to expose either (and not CHECK failing if > such files are found when iterating). > > Original change's description: > > [FSA] Add IsSafePathComponent checks to GetFile/GetDirectoryHandle. > > > > This isn't directly using net::IsSafePortablePathComponent since what > > is safe for the File System Access API is not the same as what is safe > > for Downloads. As such currently this duplicates a lot of the > > implementation of this method, but in a followup we should attempt to > > unify these two implementations as much as possible. > > > > Bug: 1150810, 1154757 > > Change-Id: Iba4c92ef5f1cd924aa22b9dd201762d48b4bbc3b > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2568383 > > Commit-Queue: Marijn Kruisselbrink <mek@chromium.org> > > Reviewed-by: Victor Costan <pwnall@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#833042} > > Bug: 1150810 > Bug: 1154757 > Change-Id: I3341b9824a1ac4cbd6f100355960ad55b01f0753 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2575370 > Commit-Queue: Victor Costan <pwnall@chromium.org> > Reviewed-by: Victor Costan <pwnall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#834118} Bug: 1150810 Bug: 1154757 Change-Id: Ie5cad9a7b2383c89b96e8a7be6cfe75ad2555fa6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2577614 Commit-Queue: Marijn Kruisselbrink <mek@chromium.org> Auto-Submit: Marijn Kruisselbrink <mek@chromium.org> Reviewed-by:
Victor Costan <pwnall@chromium.org> Cr-Commit-Position: refs/heads/master@{#834598}
-
Josh Nohle authored
Previously, the cancel implementation invoked the transfer-update callback before cancelling any ongoing payloads via Nearby Connections. The transfer-update callback subsequently cleaned up the payloads and disconnected before the payloads could be cancelled; so, the payloads would never be cancelled via Nearby Connections and the payload tracker would never receive a cancellation notification. This is particularly harmful to metrics. In this CL, we * cancel payloads via Nearby Connections before doing anytyhing else; * ensure that we provide enough time for the remote device to process cancellation before disconnecting; * make some memory-management improvements, such as copying the ShareTarget in DoCancel()--the notification manager owns the reference passed into Cancel(), and that could easily be invalidated during the cancellation process; * ensure that the payload tracker does not process trivial data sent during a cancellation, notably a 0 value for the number of bytes transferred. Manually verified all types of cancellation. Also, verified that existing metrics and the metrics of https:/crrev.com/c/2571443 are as expected. We still see crbug/1155412 and b/175064390, but those are known, unrelated issues. Fixed: 1156232 Change-Id: I0d480b25d3565a21138d1ae32377cc4f4fcd87c4 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2577767 Auto-Submit: Josh Nohle <nohle@chromium.org> Commit-Queue: James Vecore <vecore@google.com> Reviewed-by:James Vecore <vecore@google.com> Cr-Commit-Position: refs/heads/master@{#834597}
-
