- 06 Nov, 2019 40 commits
-
-
Peter E Conn authored
This CL renames: - Verifier to CurrentPageVerifier. - VerifierDelegate to Verifier. - TwaVerifierDelegate to TwaVerifier. - corresponding test classes. Bug: 1017114 Change-Id: I8c9e9688ba1eca415bc3c4b4951e2839db458c89 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1899987Reviewed-by:
Peter Kotwicz <pkotwicz@chromium.org> Commit-Queue: Peter Conn <peconn@chromium.org> Cr-Commit-Position: refs/heads/master@{#713158}
-
Andres Calderon Jaramillo authored
This CL prevents out-of-order sync token releases from causing a client's scheduling state to go back in time. Prior to this change, if a client submitted a release for a sync token with a release count that was earlier than the last release count, we would update the last release count to the earlier one. This would mean that a sync token could get "unreleased." Test: added unit tests to enforce the new behavior. Bug: 1013502 Change-Id: If8404101789a277dacfd2337971fd60136f07d24 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1898714 Commit-Queue: Andres Calderon Jaramillo <andrescj@chromium.org> Reviewed-by:
Sunny Sachanandani <sunnyps@chromium.org> Cr-Commit-Position: refs/heads/master@{#713157}
-
Felipe Cerqueira authored
BEFORE: http://screenshot/pUOjJiTuqw7.png AFTER: http://screenshot/bgRxAxYz5M6.png Bug: 1021994 Change-Id: I3abf24d71335e4fa38d1cb12b201122af4391df8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1900276Reviewed-by:
Achuith Bhandarkar <achuith@chromium.org> Commit-Queue: Felipe Cerqueira <cerqueira@google.com> Cr-Commit-Position: refs/heads/master@{#713156}
-
Abhijeet Kandalkar authored
This CL use IsA<HTMLBDIElement>(element) in place of IsHTMLBDIElement(element) Bug: 891908 Change-Id: I46e044864bfbc347655e74134fd7e0d02d005646 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1899636Reviewed-by:
Jeremy Roman <jbroman@chromium.org> Commit-Queue: Abhijeet Kandalkar <abhijeet@igalia.com> Cr-Commit-Position: refs/heads/master@{#713155}
-
Eric Stevenson authored
This CL was partially created by //base/android/jni_generator/jni_refactorer.py. The docs still need to be updated properly to explicitly declare the old approach as deprecated. Bug: 929661 Change-Id: I4593c4b30886f25ea4629567e1dfa31b95ce298f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1901645 Commit-Queue: Andrew Grieve <agrieve@chromium.org> Auto-Submit: Eric Stevenson <estevenson@chromium.org> Reviewed-by:
Andrew Grieve <agrieve@chromium.org> Cr-Commit-Position: refs/heads/master@{#713154}
-
Mugdha Lakhani authored
Bug: 1016428 Change-Id: I8e0881ff2d924be0c1a62b87750714f12e935a99 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1897829 Auto-Submit: Mugdha Lakhani <nator@chromium.org> Commit-Queue: Mark Pearson <mpearson@chromium.org> Reviewed-by:
Mark Pearson <mpearson@chromium.org> Cr-Commit-Position: refs/heads/master@{#713153}
-
Antonio Gomes authored
This CL fixes the clusterfuzz issues reported (see "Fixed" below) by using WTF::Bind and WrapPersistent in RTCPeerConnectionHandler::AddICECandidate. This is a regression from crrev.com/c/1899786, where code used to have a WebRTCVoidRequest wrapping RTCVoidRequest instances (garbage collected). Now that RTCVoidRequest is used directly, we need to properly wrap-persist its instances with WTF::WrapPersistent when passing it to callbacks. Reason: With Oilpan and WTF::Bind, raw pointers of garbage collected objects are not allowed. Fixed:1021919 R=haraken@chromium.org Change-Id: If9128d73f288bf0e39495effd8e33779a81cc0a2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1901726 Commit-Queue: Antonio Gomes <tonikitoo@igalia.com> Commit-Queue: Jeremy Roman <jbroman@chromium.org> Auto-Submit: Antonio Gomes <tonikitoo@igalia.com> Reviewed-by:
-
Etienne Pierre-doray authored
This CL updates FrameInterferenceRecorder to compute agent interference metric (using cluster_id to identify agents) and records it as TimeRunningOtherAgentsWhileTaskReady. FrameInterferenceRecorder should be renamed AgentInterferenceRecorder as a follow-up. Bug: 1019856 Change-Id: I0ad429f3f77f7612d77b010de10f88383727cc81 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1888091 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by:
Alexander Timin <altimin@chromium.org> Reviewed-by:
François Doray <fdoray@chromium.org> Cr-Commit-Position: refs/heads/master@{#713151}
-
Sinan Sahin authored
Bug: 1018268 Change-Id: Ib5a8e881fc958715984d40188e3f3bb054b40427 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1894412 Commit-Queue: Sinan Sahin <sinansahin@google.com> Reviewed-by:
Theresa <twellington@chromium.org> Cr-Commit-Position: refs/heads/master@{#713150}
-
Gabriel Charette authored
Instead use base::DeleteSoon which enforces usage of TaskTraits. This CL is a no-op as-is. It was recently discovered however that some callers did BrowserThread::DeleteSoon() with pending tasks running on different task queues (different traits -- e.g. TaskTraits to make this more obvious. Please review whether calls in this CL can be migrated as-is or need additional traits to match potentially pending tasks. Split from https://chromium-review.googlesource.com/c/chromium/src/+/1894109 for cursory review. This CL was uploaded by git cl split. R=vakh@chromium.org TaskPriority: :BEST_EFFORT) which can result in out-of-order deletion... BrowserThread: :DeleteSoon() is being migrated to base::DeleteSoon() w/ Bug: 1019767 Change-Id: I9adb0b38d8b12adb9a7571c40928e5ac0de078db Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1894885 Auto-Submit: Gabriel Charette <gab@chromium.org> Reviewed-by:
Varun Khaneja <vakh@chromium.org> Commit-Queue: Gabriel Charette <gab@chromium.org> Cr-Commit-Position: refs/heads/master@{#713149}
-
chromium-autoroll authored
https://swiftshader.googlesource.com/SwiftShader.git/+log/88264e3e188d..27a3d31d7a9d git log 88264e3e188d..27a3d31d7a9d --date=short --no-merges --format='%ad %ae %s' 2019-11-06 jonahr@google.com Fix issues presenting MetalSurfaces Created with: gclient setdep -r src/third_party/swiftshader@27a3d31d7a9d If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/swiftshader-chromium-autoroll Please CC swiftshader-team+autoroll@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/+/master/autoroll/README.md CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_chromium_msan_rel_ng;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=swiftshader-team+autoroll@google.com Bug: chromium:1015454 Change-Id: Ie90efeabc21b48b0756529528d37868608fc0666 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1901542Reviewed-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@{#713148}
-
Rakina Zata Amni authored
When a page is restored from the back forward cache, there is currently no way to know its navigationStart time since we aren't updating performance.timing.navigationStart (which is undesirable), even though users of bfcache might want to know the navigationStart time to measure latency. To solve this, we are modifying the pageshow event’s timeStamp to correspond to the navigation start of the history navigation. Note as event.timeStamp is defined as time elapsed since the beginning of the document lifetime [1], this is effectively the difference between the initial navigationStart and the navigation start of the last navigation. [1] https://developer.mozilla.org/en-US/docs/Web/API/Event/timeStamp Note that we are only updating this for pageshow events for pages that were persisted (restored from the back forward cache). For more background, see doc at https://docs.google.com/document/d/1XlZhphHW-bNcUPD98T-rfTa-TASI-3xUtxZzThZLJCA/edit?usp=sharing Change-Id: I81e399492eaa377ac56c4325e3134b1ff50ae451 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1888627 Commit-Queue: Alex Moshchuk <alexmos@chromium.org> Auto-Submit: Rakina Zata Amni <rakina@chromium.org> Reviewed-by:
Alex Moshchuk <alexmos@chromium.org> Reviewed-by:
Fergal Daly <fergal@chromium.org> Reviewed-by:
Nicolás Peña Moreno <npm@chromium.org> Reviewed-by:
Kentaro Hara <haraken@chromium.org> Reviewed-by:
Daniel Cheng <dcheng@chromium.org> Cr-Commit-Position: refs/heads/master@{#713147}
-
Ted Meyer authored
Bug: 954850 Change-Id: I6020a3a9cc04b696cbaa4554acd08ec83753bac7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1900687Reviewed-by:
Dale Curtis <dalecurtis@chromium.org> Commit-Queue: Dale Curtis <dalecurtis@chromium.org> Cr-Commit-Position: refs/heads/master@{#713146}
-
Gabriel Charette authored
Instead use base::DeleteSoon which enforces usage of TaskTraits. This CL is a no-op as-is. It was recently discovered however that some callers did BrowserThread::DeleteSoon() with pending tasks running on different task queues (different traits -- e.g. TaskTraits to make this more obvious. Please review whether calls in this CL can be migrated as-is or need additional traits to match potentially pending tasks. Split from https://chromium-review.googlesource.com/c/chromium/src/+/1894109 for cursory review. This CL was uploaded by git cl split. R=jzw@chromium.org TaskPriority: :BEST_EFFORT) which can result in out-of-order deletion... BrowserThread: :DeleteSoon() is being migrated to base::DeleteSoon() w/ Bug: 1019767 Change-Id: Ib72a7df0175f5cd438052510e6ddf1eeefbefa59 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1895644 Auto-Submit: Gabriel Charette <gab@chromium.org> Reviewed-by:
John Wu <jzw@chromium.org> Commit-Queue: John Wu <jzw@chromium.org> Cr-Commit-Position: refs/heads/master@{#713145}
-
Michael Lippautz authored
Weak processing happens after marking. This phase happens after marking and markbits should not be changed any longer. While the markbit for the backing store is local, it prevents a refactoring that avoids passing around the Visitor for weak callbacks. See the patch for reasoning of liveness and moving consistency. Change-Id: I1c593b288e0ffc4f9c3cbf16a211eac29360abfd Bug: 982754 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1901037 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#713144}
-
Chen-Yu Tsai authored
GpuMojoMediaClient::gpu_memory_buffer_factory_ is guarded by BUILDFLAG(USE_CHROMEOS_MEDIA_ACCELERATION), however it is only used in the ChromeOS specific code path. This results in the following error if standard Chrome is built with use_vaapi=true or use_v4l2_codec=true on Linux: In file included from ../../media/mojo/services/gpu_mojo_media_client.cc:5: ../../media/mojo/services/gpu_mojo_media_client.h:77:38: error: private field 'gpu_memory_buffer_factory_' is not used [-Werror,-Wunused-private-field] gpu::GpuMemoryBufferFactory* const gpu_memory_buffer_factory_; Add "defined(OS_CHROMEOS)" to the #ifs that guard the field declaration and assignment in the constructor to match the code path that uses it. Test: compile and run media_unittests with use_vaapi=true on Linux Test: compile and run media_unittests simplechrome (chromeos-amd64-generic-rel) Change-Id: Ic621272e06d4e5457572f1eadbd9f549638446a4 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1898280Reviewed-by:Jeffrey Kardatzke <jkardatzke@google.com> Reviewed-by:
Miguel Casas <mcasas@chromium.org> Commit-Queue: Dale Curtis <dalecurtis@chromium.org> Cr-Commit-Position: refs/heads/master@{#713143}
-
Long Cheng authored
Skip initialize DTC for AppListSyncableService if device is set to tablet form factor. factor devices. devices between user sessions. Bug: 1013732 Test: ApplistSyncableService is disabled on tablet form Test: Applist position persist on tablet form factor Change-Id: I5ed15c8d0c3381d4d6ebea5397b8a00779b653cc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1901627 Commit-Queue: Long Cheng <lgcheng@google.com> Reviewed-by:
Mikel Astiz <mastiz@chromium.org> Cr-Commit-Position: refs/heads/master@{#713142}
-
Xianzhu Wang authored
ScrollingCoordinator::UpdateCompositedScrollOffset() assumes that the scroll layer exists. We should not call the function when we haven't created the scroll layer. The check was not needed before crrev.com/c/1895081 because we created the layers earilier (during CompositeUpdate). After the CL we created the layers during PrePaint, but VisualViewport::DidSetScaleOrLocation() can be called earlier. Bug: 1020181 Change-Id: Ie9a341928ed13e02b4edbefdfbc513f1ecb22be0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1899598 Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by:
David Bokan <bokan@chromium.org> Cr-Commit-Position: refs/heads/master@{#713141}
-
Bill Budge authored
- Removes context_ field on WasmStreamingClient, which held a weak reference to the Context. This isn't used, and isn't thread-safe. - Removes unused isolate parameter too. Bug: chromium:1018029 Change-Id: Iab4cbab2a710716860ab8931a7561239970051d0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1901592 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#713140}
-
Will Harris authored
BUG=1005715 Change-Id: Ib03f9752e5fc09e096f16dd6500343fc07c56ed1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1901352 Auto-Submit: Will Harris <wfh@chromium.org> Reviewed-by:
James Forshaw <forshaw@chromium.org> Commit-Queue: Will Harris <wfh@chromium.org> Cr-Commit-Position: refs/heads/master@{#713139}
-
Wez authored
Change-Id: Id5ab1b61d754998c8452c5bfab58dd88f6e9ab46 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1900906 Commit-Queue: Sergey Ulanov <sergeyu@chromium.org> Reviewed-by:
Sergey Ulanov <sergeyu@chromium.org> Auto-Submit: Wez <wez@chromium.org> Cr-Commit-Position: refs/heads/master@{#713138}
-
Robbie McElrath authored
This moves classes in //aw/apk from com.android.webview.chromium to org.chromium.android_webview.app to match the rest of the chromium webview implementation. Test: Manually verified that licenses still show in Settings > Test: System > About > Legal information > System WebView licenses Bug: 934152 Change-Id: Idebcaf4ea9cd604d644f8cab1d957cf918a669e1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1881320Reviewed-by:
Richard Coles <torne@chromium.org> Reviewed-by:
Nate Fischer <ntfschr@chromium.org> Commit-Queue: Robbie McElrath <rmcelrath@chromium.org> Cr-Commit-Position: refs/heads/master@{#713137}
-
Henrique Nakashima authored
Move SharedPreferencesManager into it. Bug: 1017800 Change-Id: Ifbf334d2479b374f38f78a79b8e84d0d0ca08394 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1895076 Commit-Queue: Henrique Nakashima <hnakashima@chromium.org> Reviewed-by:
Natalie Chouinard <chouinard@chromium.org> Cr-Commit-Position: refs/heads/master@{#713136}
-
v8-ci-autoroll-builder authored
Summary of changes available at: https://chromium.googlesource.com/v8/v8/+log/a423bb8b..5703cc70 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,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I47dab774363e23262e51bf78db63d1f500b31479 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1900278Reviewed-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@{#713135}
-
Xianzhu Wang authored
I'm not familiar with it. Change-Id: I142d0f659cbc8fc1da66a98c40c4c9b4226ea470 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1900554Reviewed-by:
John Budorick <jbudorick@chromium.org> Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/heads/master@{#713134}
-
Albert J. Wong authored
Per analysis in https://docs.google.com/document/d/13KlGXF262SjyzHKTKSEu2LsQwqouDKurR1-HV9gxN9I/edit?ts=5db9f5dd#heading=h.4d6g0bxv5tz5 it should be possible to double sharding with a modreate increase in bot capacity. The capacity increase was made in: https://chrome-internal-review.googlesource.com/c/infradata/config/+/2098798 Bug: 1021179 Change-Id: I012ec294d5ba84a80c7480836937e46ec1518a27 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1900390Reviewed-by:
Erik Chen <erikchen@chromium.org> Reviewed-by:
Aaron Gable <agable@chromium.org> Commit-Queue: Albert J. Wong <ajwong@chromium.org> Cr-Commit-Position: refs/heads/master@{#713133}
-
Michael Ershov authored
Bug: 1000589 Change-Id: I288a7b144a2412cefb69110493c7ea20b23960e5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1865326 Commit-Queue: Michael Ershov <miersh@google.com> Reviewed-by:
Maksim Ivanov <emaxx@chromium.org> Reviewed-by:
Alex Ilin <alexilin@chromium.org> Reviewed-by:
Denis Kuznetsov [CET] <antrim@chromium.org> Cr-Commit-Position: refs/heads/master@{#713132}
-
Xiaohan Wang authored
When the "Protected content" permission decision is different from the default value, "Protected content" will show up in the PageInfo. See screenshots at: https://photos.app.goo.gl/Rmd5S75gTUNU7vZVA Similar change on ChromeOS will be done in a separate CL. Bug: 593210 Test: Manually tested. See screenshots linked above. Change-Id: I87e7cda9b4e46b70e0410ec213b49590c8f5cd74 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1898611Reviewed-by:
Balazs Engedy <engedy@chromium.org> Reviewed-by:
Yaron Friedman <yfriedman@chromium.org> Commit-Queue: Xiaohan Wang <xhwang@chromium.org> Cr-Commit-Position: refs/heads/master@{#713131}
-
Joshua Pawlicki authored
TBR=tbarzic@chromium.org Bug: 1022021 Change-Id: Icc814fe9a8de25d42e2597ce1e323e1b1438f00d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1901594Reviewed-by:
Joshua Pawlicki <waffles@chromium.org> Commit-Queue: Joshua Pawlicki <waffles@chromium.org> Cr-Commit-Position: refs/heads/master@{#713130}
-
Dominique Fauteux-Chapleau authored
Changes the DM Token Retrieve/Store from returning only a string to returning the token string and a status. The statuses are: Valid: The DM token is non-empty and its string value can be used. Invalidated: The DM token has been explicitly invalidated. Should be treated as if the device was not enrolled. Empty: The DM token is empty. Enrollment might occur if the enrollment token is non-empty. Bug: 1020294 Change-Id: I1418615edc82e65f15325da2fca008c8cdab5ca0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1879340Reviewed-by:Owen Min <zmin@chromium.org> Reviewed-by:
Tien Mai <tienmai@chromium.org> Commit-Queue: Dominique Fauteux-Chapleau <domfc@chromium.org> Cr-Commit-Position: refs/heads/master@{#713129}
-
Albert Chaulk authored
Occasionally the renderer will provide an invalid surface ID, so in that case we use the previous valid ID. This also checks that the embed token is the same between both versions and updates it if necessary This can happen when a webcontents loads a new page, the old surface is deprecated but the new one isn't ready yet Bug: b/143651420 Test: on device Change-Id: I943d242f3acba3e2daf3fe69b5e3d469087df781 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1900094 Commit-Queue: Albert Chaulk <achaulk@chromium.org> Reviewed-by:
Daniel Nicoara <dnicoara@chromium.org> Reviewed-by:
Mitsuru Oshima <oshima@chromium.org> Cr-Commit-Position: refs/heads/master@{#713128}
-
chromium-autoroll authored
https://chromium.googlesource.com/chromium/tools/depot_tools.git/+log/d39c0496a168..41be80f6159c git log d39c0496a168..41be80f6159c --date=short --no-merges --format='%ad %ae %s' 2019-11-06 recipe-mega-autoroller@chops-service-accounts.iam.gserviceaccount.com Roll recipe dependencies (trivial). Created with: gclient setdep -r src/third_party/depot_tools@41be80f6159c 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 agable@chromium.org 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/+/master/autoroll/README.md TBR=agable@chromium.org Bug: None Change-Id: I0b63cabc0504d082cdc168c08f22be8b76cb8f89 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1901536Reviewed-by:
-
Peter Wen authored
Ran: rm -rf third_party/android_deps/libs/[!O]* tools/android/roll/android_deps/fetch_all.py --update-all According to: https://chromium.googlesource.com/chromium/src/+/HEAD/tools/android/roll/android_deps/README.md Bug: None Change-Id: I7db268ee7871ec77f3ba5c123abbc0eff107c835 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1901907 Commit-Queue: Peter Wen <wnwen@chromium.org> Commit-Queue: Andrew Grieve <agrieve@chromium.org> Auto-Submit: Peter Wen <wnwen@chromium.org> Reviewed-by:
-
Avery Musbach authored
Bug: None Change-Id: Ie13e6aaf370f9428566f8cb3ed7e926776c4d21a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1897006Reviewed-by:
-
Steven Bennetts authored
This adds support to DataPack to load gzipped .pak.gz files into memory, instead of using mmap to map memory to an uncompressed pak file. The advantage is that .pak files compress by as much as 70% on disk. The disadvantage is that mmapped memory (which is initially resident) can be trivially swapped out when not in use (since it is already backed by a file), whereas allocated memory uses regular swap storage. For Chrome OS this is likely to be a worthwhile tradeoff. Testing shows that fairly minimal use of the Chrome OS UI swaps in most of the file after it is swapped out. See the issue for details. Note: This CL does not implelent compression of .pak files, that will be handled in a follow-up CL. This also removes the unused |test_file_exists| parameter from ResourceBundle::GetLocaleFilePath (it was always set to true). Bug: 1017864 Change-Id: I16eaaf8d294199d8310ec06fedc79dabfb0d27a0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1882759 Commit-Queue: Steven Bennetts <stevenjb@chromium.org> Reviewed-by:
Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#713124}
-
Jazz Xu authored
Bug: 1021681 Change-Id: I2f0b5096a083a9257f075fa46856d6a10951a520 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1900326Reviewed-by:
Mounir Lamouri <mlamouri@chromium.org> Commit-Queue: Jazz Xu <jazzhsu@chromium.org> Cr-Commit-Position: refs/heads/master@{#713123}
-
Takumi Fujimoto authored
Use it on the IO thread to be consistent with the DIAL MRP. Change-Id: I51cd4e1bd5129347014e6ddb7d464539a9f682c7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1900649Reviewed-by:
Ken Rockot <rockot@google.com> Commit-Queue: Takumi Fujimoto <takumif@chromium.org> Cr-Commit-Position: refs/heads/master@{#713122}
-
Mohamed Heikal authored
Final android-binary-size trybot message is now simpler and links to doc containing all the needed information about the checks that run and how to get the trybot to pass for your CL. Change-Id: Id4dfd7af7510b89837f74ed5bdd94d737d37ae5d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1900304 Commit-Queue: Mohamed Heikal <mheikal@chromium.org> Reviewed-by:
-
Tom Anderson authored
See [1] and [2] for why this is necessary. There are some containerized setups where the X11 socket is shared between host and guest, but /dev/shm is not, meaning usage of the MIT-SHM extension won't work. Rather than libxext providing an environment variable of its own so that all apps could use a uniform interface, toolkits have been adding their own ways of disabling the extension for this use case. QT has QT_X11_NO_MITSHM, the JRE has J2D_USE_MITSHM, and GTK uses a command line flag --no-xshm. This CL adds checks for all of those. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=991633#c11 [2] https://bugs.chromium.org/p/chromium/issues/detail?id=991633#c13 BUG=991633 R=rjkroege TBR=kbr Change-Id: I44792069098eef4617726e831f63e4d9a857530d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1900264Reviewed-by:
Thomas Anderson <thomasanderson@chromium.org> Reviewed-by:
Robert Kroeger <rjkroege@chromium.org> Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> Cr-Commit-Position: refs/heads/master@{#713120}
-
Ahmed Fakhry authored
The callbacks should be called with a single bool argument. Using the automatically generated Create() functions made them be called with an array of bools instead, which is not what we expect. BUG=1016994 TEST=Run the Tast test and expect it to be able to unmarshall a bool from the callback. Change-Id: I1d89de8ffcd5d78e24a9114a68f1cebb0ad6db4a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1900689Reviewed-by:Steven Bennetts <stevenjb@chromium.org> Commit-Queue: Ahmed Fakhry <afakhry@chromium.org> Cr-Commit-Position: refs/heads/master@{#713119}
-
