profile
viewpoint
Raphael Kubo da Costa rakuco Intel Corporation Amsterdam, Netherlands KDE, FreeBSD, Chromium and everything in between

OSSystems/meta-browser 89

OpenEmbedded/Yocto BSP layer for Web Browsers

OSSystems/meta-chibi 2

Experimental Yocto Project layer for Chibi Scheme

rakuco/cardapio-bandex 2

A library and related scripts to parse State University of Campinas' university restaurant's menu.

OSSystems/validates_as_cnpj 1

Validação de CNPJ para ActiveRecord

OSSystems/validates_as_cpf 1

Validação de CPF para ActiveRecord

OSSystems/validates_as_email 1

Validação de e-mail para ActiveRecord

OSSystems/validates_as_inscricao_estadual 1

Validação de Inscrição Estadual para ActiveRecord

OSSystems/zephyr 1

Fork of Zephyr Project Git

eehakkin/intel-w3c-web-platform-tests 0

Test Suites for Web Platform specifications—including WHATWG, W3C and others

eehakkin/intel-whatwg-fetch 0

Fetch Standard

pull request commentOSSystems/meta-browser

chromium: update to 86.0.4240.111

Thanks for checking, @r1mikey!

msisov

comment created time in a day

Pull request review commentOSSystems/meta-browser

chromium: update to 86.0.4240.111

+From 1da727488fc60b663f9afdc2ad033d5f0edc05fe Mon Sep 17 00:00:00 2001

You're missing the Upstream-status + signed-off-by header.

msisov

comment created time in 2 days

Pull request review commentOSSystems/meta-browser

chromium: update to 86.0.4240.111

+From e5f288d4807b63381e497475de316926479ec427 Mon Sep 17 00:00:00 2001+From: Maksim Sisov <msisov@igalia.com>+Date: Mon, 26 Oct 2020 11:06:56 +0200+Subject: [PATCH] Remove dead-reloc-in-nonalloc LD flags

Can you provide more context to this patch (and the "Upstream-status" header on top)? I don't understand what problem is being solved here.

msisov

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentweb-platform-tests/wpt

Update interfaces/webhid.idl

cc @nondebug

autofoolip

comment created time in 6 days

push eventrakuco/generic-sensor-demos

push time in 13 days

push eventrakuco/generic-sensor-demos

Raphael Kubo da Costa

commit sha 3560bd296d16f40bd4fd3fb661807d9a8b026fad

more debugging

view details

push time in 13 days

push eventrakuco/generic-sensor-demos

Raphael Kubo da Costa

commit sha c401b3061a7d7a3cf1240bb4b640bba24e072af8

orientation-phone debugging

view details

push time in 13 days

push eventrakuco/generic-sensor-demos

Kenneth Rohde Christiansen

commit sha a161f52406623695ef419ac8830b38cabaa1bd92

Fixes #67 - hide tests for non existing sensors (#68)

view details

Kenneth Rohde Christiansen

commit sha 64c8821b52f6231f72f7e13563992efa6a0cd06c

Fixes #65 - color icon button right (#69)

view details

Raphael Kubo da Costa

commit sha 8599c84c9d12c130f6b15f4a44224560cc6b71ea

sensor-tester: Rebuild build/ after #69. (#70) Also part of the fix for #65.

view details

Kenneth Rohde Christiansen

commit sha 8fc1a5a435c9fe618560a83a0566bdd01236fbc9

Fix #66 - reset orientation (#71)

view details

Kenneth Rohde Christiansen

commit sha 3287c15b2b49e9a6f05f7919f7ecffdc8563d020

Apply some idle-until-urgent (#73)

view details

Kenneth Rohde Christiansen

commit sha 5c2282cb1e1bc8f014db4a0b865efcaed8d0a8d3

A few mini fixes (#74) - Remove unneeded code for fetching the JSON, like manually asking for a re-render - Avoid using SVG in the lazy image element. Instead use visibility:hidden (element is then in DOM unlike display:none and IntersectionObserver will find it)

view details

kaixinjxq

commit sha 55778ff9e886a091cd7713d13487569deabac6be

Add RelativeOrientationSensor test (#52) * Add RelativeOrientationSensor test * Add RelationOrientationSensor test about 90 degrees rotation around Z * Upgrade RelativeOrientationSensor tests to Polymer 3.0 * Address @kenchris' comments * Optimize the code about comparing the reading values

view details

kaixinjxq

commit sha 0df883c0e3b065a29752fcf307713454701fbe20

sensor-tester: Rebuild build/ after #52 (#75)

view details

Kenneth Rohde Christiansen

commit sha 2be5592791f7a0f6f05ddc9e28d5085409c7d21e

Update dependencies and fix bug visible in newer Chrome (#77)

view details

Kenneth Rohde Christiansen

commit sha 2b27b9fb15f5391e27149296da43c7eb5d667b84

Update remaining modules (#78)

view details

Kenneth Rohde Christiansen

commit sha a83dccf1387f6f708f1721f786d0b1b214e9d7f9

Add some nice app-like page transitions (#79) * Do page transition like Google Photos app

view details

kaixinjxq

commit sha 2d7cc984895b5724b10b123bf5d4325eef181c9d

Upgrade ambient-map to Polymer3.0+LitElement+MWC (#81) * Upgrade ambient-map to Polymer3.0+LitElement+MWC * Address @kenchris' comments - Delete unused CSS class - Delete infoText attribtute - Add latitude and longitude properties - Get paper-dialog element in firstUpdated() - Add autofocus to close button - Modify JSON format

view details

kaixinjxq

commit sha 40833c6ee79cfa7d0e804d02fc5af49aebe487b4

Upgrade vr-button to Polymer3.0+LitElement+MWC (#82) * Upgrade vr-button to Polymer3.0+LitElement+MWC * Address @kenchris' comments - Delete infoText - Add a blank line

view details

kaixinjxq

commit sha dd64d3ff9138608c329fa9e781ed79f24d286b7b

Fix the issue that ambient map background style doesn't change (#84)

view details

kaixinjxq

commit sha 13c0513eba7ed164716f8ee61d2f2533cab2fcf3

Add sensor screen tests in sensor-tester (#85) * Add sensor screen tests in sensor-tester - Add Gyroscope screen tests - Add AbsoluteOrientationSensor screen tests - Add RelativeOrientationSensor screen tests - Add Magnetometer screen tests - Use *_screen.* to update the illustration name of Accelerometer and LinearAccelerationSensor screen tests - Update .gitignore file * Address @kenchris' comments - Use lowercase north - Modify the description of the name

view details

kaixinjxq

commit sha 0b885a65a827c73234fb842fa73d3ef96de03112

Upgrade sensor-info to Polymer3.0+LitElement+MWC (#80) * Upgrade sensor-info to Polymer3.0+LitElement+MWC * Address @kenchris' comments - Update package.json - Use let - Delete properties() function * upgrade lit-element to 2.0.1

view details

kaixinjxq

commit sha d242078ee88b93e099925c4f1a622e14b0932ccf

Addressed some points raised in #80 (#87) * Addressed some points raised in #80 - upgrade lit-element/mwc-button/mwc-icon/app-layout to latest version - use string literals - use "()=>{}" instead of "function(){}" - use "10 ** precision" instead of "Math.pow()" - use "sensorConstructor = window.Magnetometer" to simplify the code - use "this.errorType" instead of 'this["errorType"]' * upgrade mwc-button/mwc-icon to 0.5.0

view details

Adrian Campos

commit sha 8fbed4fba4be04c625d503c8d3c006ce3d15b922

Fix typo: strenght -> strength (#91)

view details

push time in 13 days

issue commentintel/generic-sensor-demos

browsers support

It's definitely supported on Chrome -- did you try any specific demo that didn't work?

Ajasra

comment created time in 15 days

PullRequestReviewEvent

Pull request review commentOSSystems/meta-browser

chromium: update to 85.0.4183.121

 BBFILE_PATTERN_browser-layer := "^${LAYERDIR}/" BBFILE_PRIORITY_browser-layer = "7"  LAYERVERSION_browser-layer = "1"-LAYERSERIES_COMPAT_browser-layer = "dunfell gatesgarth"+LAYERSERIES_COMPAT_browser-layer = " \

Commit 20bd7d432e239a90c028 mentions a character limit, do you know if this change breaks that? Also, I think it'd be good to do this separately:

  • git revert the commit that removed zeus and explain why
  • In another commit, remove warrior support
  • Make this PR only update the Chromium version
msisov

comment created time in 16 days

PullRequestReviewEvent

pull request commentweb-platform-tests/wpt

Add interfaces/screen-wake-lock.idl

@foolip the bot's still trying to add the interface that's been present since #26024. Is there anything that needs to be done from our side?

autofoolip

comment created time in 20 days

PR closed web-platform-tests/wpt

Reviewers
Add interfaces/screen-wake-lock.idl interfaces

This PR was automatically created by a bot.

Before merging, please check that any tests that depend on the updated IDL files still work.

If additional changes are needed, please manually create another PR based on this one.

See the README for how the IDL files in this directory are used.

<hr>

Source: https://github.com/w3c/webref/blob/9cdbf49/ed/idl/screen-wake-lock.idl Build: https://travis-ci.org/w3c/webref/builds/732950411

+24 -0

1 comment

1 changed file

autofoolip

pr closed time in 21 days

pull request commentweb-platform-tests/wpt

Add interfaces/screen-wake-lock.idl

This is conflicting with #26024, let me try to close it and see if the bot will try to send an update to the existing IDL file.

autofoolip

comment created time in 21 days

push eventweb-platform-tests/wpt

Philip Jägenstedt

commit sha 90d5ebe5329b3918ba4908797e6211a3b099adaf

Rename interfaces/wake-lock.idl to screen-wake-lock.idl (#26024) screen-wake-lock.idl has been added to webref after the publication of https://www.w3.org/TR/screen-wake-lock/. Closes https://github.com/web-platform-tests/wpt/pull/25926.

view details

push time in 21 days

PR merged web-platform-tests/wpt

Reviewers
Rename interfaces/wake-lock.idl to screen-wake-lock.idl interfaces screen-wake-lock wg-das

screen-wake-lock.idl has been added to webref after the publication of https://www.w3.org/TR/screen-wake-lock/.

Closes https://github.com/web-platform-tests/wpt/pull/25926.

+1 -1

0 comment

2 changed files

foolip

pr closed time in 21 days

PR closed web-platform-tests/wpt

Reviewers
Add interfaces/screen-wake-lock.idl interfaces

This PR was automatically created by a bot.

Before merging, please check that any tests that depend on the updated IDL files still work.

If additional changes are needed, please manually create another PR based on this one.

See the README for how the IDL files in this directory are used.

<hr>

Source: https://github.com/w3c/webref/blob/9cdbf49/ed/idl/screen-wake-lock.idl Build: https://travis-ci.org/w3c/webref/builds/732950411

+24 -0

6 comments

1 changed file

autofoolip

pr closed time in 21 days

pull request commentweb-platform-tests/wpt

Add interfaces/screen-wake-lock.idl

Thanks for the clarification, @foolip! The only follow-up question I have is whether the IDL sync infrastructure will later send another PR to sync IDL changes to screen-wake-lock.idl after #26024 (the file being renamed is still missing a change to the WakeLock.request() method that was present in this PR).

autofoolip

comment created time in 21 days

PullRequestReviewEvent

pull request commentweb-platform-tests/wpt

Add interfaces/screen-wake-lock.idl

@foolip friendly ping. I've got a CL in Chromium that depends on the IDL changes in this PR, so I'd appreciate some guidance on which IDL file to use.

autofoolip

comment created time in 21 days

PR closed web-platform-tests/wpt

Add FP reporting tests for wake-lock feature-policy status:needs-reviewers wg-webappsec
+62 -0

2 comments

4 changed files

Honry

pr closed time in 22 days

pull request commentweb-platform-tests/wpt

Add FP reporting tests for wake-lock

Landed in #25947 with the appropriate credits.

Honry

comment created time in 22 days

PR closed web-platform-tests/wpt

Reviewers
Add Permissions Policy reporting tests for Screen Wake Lock. feature-policy wg-webappsec

Based on #16323 by @Honry (wanming.lin@intel.com).

+57 -0

1 comment

4 changed files

rakuco

pr closed time in 22 days

issue commentOSSystems/meta-browser

chromium-x11 85 failing to compile on machines without GBM

When compiling targets defined on "third_party/minigbm/BUILD.gn, it has correctly set -I../../third_party/minigbm/src and all goes well, when compiling targets defined on //ui/gfx/linux/BUILD.g instead, it doesn't have -I../../third_party/minigbm/src and it fails to find gbm.h

For the record, I can reproduce this with today's upstream master branch by not having gbm.h installed system-wide and building with use_system_minigbm=false and use_sysroot=false (the latter is important, otherwise the build will use gbm.h from the Debian sysroot). @msisov was this supposed to work? I don't even know what GBM really is, so I'm tempted to leave this in your hands :-)

ekapllaj

comment created time in 22 days

issue commentOSSystems/meta-browser

chromium-x11 85 failing to compile on machines without GBM

@msisov even though this is chromium-x11, is this issue something you have experience with upstream?

ekapllaj

comment created time in 23 days

push eventOSSystems/meta-browser

viatsk

commit sha 5e07a7897945dd91d75169975178005d9d9aa200

chromium: include uint64_t in sim_hash namespace Previously failing to compile sim_hash.h with error | In file included from ../../components/federated_learning/sim_hash.cc:5: | ../../components/federated_learning/sim_hash.h:20:15: error: unknown type name 'uint64_t' | void SetBit(uint64_t pos); Patch 0001-Fix-lack-of-uint64_t-in-sim_hash-namespace.patch fixes this error, but should be removed as soon as the chromium version is updated to 86.x.xxxx.xx+. Signed-off-by: Stacy Gaikovaia <Stacy.Gaikovaia@windriver.com>

view details

push time in 23 days

PR merged OSSystems/meta-browser

chromium: add patch to include uint64_t in sim_hash namespace

Previously failing to compile sim_hash.h with error | In file included from ../../components/federated_learning/sim_hash.cc:5: | ../../components/federated_learning/sim_hash.h:20:15: error: unknown type name 'uint64_t' | void SetBit(uint64_t pos);

Patch 0001-Fix-lack-of-uint64_t-in-sim_hash-namespace.patch fixes this error, but should be removed as soon as the chromium version is updated to 86.x.xxxx.xx+.

+38 -0

3 comments

2 changed files

viatsk

pr closed time in 23 days

Pull request review commentOSSystems/meta-browser

chromium: add patch to include uint64_t in sim_hash namespace

+From 6284aee59f251bfe4b52d200b530ae8a98186adb Mon Sep 17 00:00:00 2001

Thanks!

viatsk

comment created time in 23 days

PullRequestReviewEvent

pull request commentweb-platform-tests/wpt

Add interfaces/screen-wake-lock.idl

  • If this file was created because of the TR, does it mean it won't be updated with changes to the ED?

I guess it will given the change that was pushed to this PR an hour ago.

autofoolip

comment created time in 23 days

push eventrakuco/wpt

youennf

commit sha 66b725a622d42bab051099accdd16d88d0df65e0

WebKit export of https://bugs.webkit.org/show_bug.cgi?id=215806 (#25231)

view details

jugglinmike

commit sha 8adc6cbbf26a654baff822ceaa4ac6faf17d3b99

[html] Add tests for parsing COEP values Co-authored-by: Simon Pieters <zcorpan@gmail.com>

view details

Rune Lillesveen

commit sha 9ad6ebf9fff00dcd46d6c5438ebbd0f7e71c15f8

Fixed test/reference mismatch for border. Test added a border of 20px to a width of 80px and expected 100px, but border is added to both sides. Reduced border to 10px. Bug: 1121917 Change-Id: I98fd76c9eb9581f842e2d8ea90e2e8b32fba01f0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2377487 Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org> Commit-Queue: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/master@{#801714}

view details

Gérard Talbot

commit sha cfa78012a280dda8f20eb293464939311ccb88cd

Corrected and improved (more precise & challenging) 2 border-image-repeat tests (#25240) * Corrected and improved (more precise) 2 border-image-repeat tests * Fix typo Co-authored-by: fantasai <fantasai.bugs@inkedblade.net>

view details

Morten Stenshorne

commit sha 6b6a74e478f36b8039d448d8f44f86033dabefa3

Never re-use the layout result from the fieldset contents wrapper. On the layout object side, all children of a fieldset are wrapped inside an anonymous fieldset contents block. We'll detect during layout which of the legend children (if any) will become the rendered legend. Unlike all other in-flow children of a fieldset element, whose containing block is the wrapper, the containing block of the rendered legend is the fieldset layout object itself (not the wrapper child), so if we change / remove the rendered legend, the wrapper won't be marked for layout. Bug: 1119400 Change-Id: I5b898af8c7b7e3687def6a2333d43a8ba6af09b1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2374526 Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#801772}

view details

jugglinmike

commit sha 63c8be26e528d19e77819bbb6c9ad7aab5ea5abe

[html] Test sequence of navigation failure checks This test is in support of this patch to HTML: https://github.com/whatwg/html/pull/5859

view details

Masayuki Nakano

commit sha 8ffb752b7814ab228d8f89ec92804cb9e41ac9b6

Disallow recursive `Document.execCommand()` calls It's disabled in the Nightly channel and early beta half a year ago, but there are no regression reports and Chrome has already disabled it since 2014. So, let's disable this feature on the Release channel (and late Beta) too for better security and making simpler implementation in the future. Differential Revision: https://phabricator.services.mozilla.com/D87992 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1634262 gecko-commit: f725948fa93a3aedb622413e02c1f4de147dea63 gecko-integration-branch: autoland gecko-reviewers: smaug

view details

Henrik Boström

commit sha 0d794eb31a9920dd63065a1c4de2d14132b986f5

[Perfect Negotiation] Surface session descriptions at the right time. This fixes another timing related issue that blocks Perfect Negotiation. Before this CL, current/pending local/remote description attributes do blocking-invokes on the webrtc thread, fetching the most up-to-date states. This can prematurely expose the result of "in-parallel" operations that have not surfaced yet, such as: - setLocalDescription - setRemoteDescription - addIceCandidate This CL fixes that by copying the SDP states when any of these operations complete on the WebRTC thread and carry them over in the PostTask to the main thread. Here, we store these snapshots in "internal slots" (variables living on the main thread). With this CL, reading SDP attributes from RTCPeerConnection is non-blocking and spec-compliant. WPT test coverage added for the exact timing of SLD/SRD and other test expectations are updated. addIceCandidate updating the SDP is already covered by old WPTs. Bug: chromium:1110347 Change-Id: Id41ec354465525c6cedf631fe2209fe097148f60 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2323359 Commit-Queue: Henrik Boström <hbos@chromium.org> Reviewed-by: Harald Alvestrand <hta@chromium.org> Cr-Commit-Position: refs/heads/master@{#801798}

view details

Kevin Ellis

commit sha ec11bcffbb38f6b10c500f13edeaa5844339f66b

Fix test flake in animation-state-changes-positive-playback-rate.html The flake is caused by limited precision of timeline times. When comparing times with >=, the boundary time needs to factor in error tolerance. The virtual/threaded-no-composited-antialiasing variant of this test had a recent flake score of 954. Bug: 623434 Change-Id: I44b41da1326849da4b3dec30cea76be6673e0b17 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2368500 Reviewed-by: Xida Chen <xidachen@chromium.org> Commit-Queue: Kevin Ellis <kevers@chromium.org> Cr-Commit-Position: refs/heads/master@{#801013}

view details

Amr Aboelkher

commit sha dc1106492705bb07a14a066eab757981159cb7b9

[Sheriff] Revert "[Perfect Negotiation] Surface session descriptions at the right time." This reverts commit 3bc91ccc927f8eb887a84a1e59f34c88518ce2ab. Reason for revert: Failure of WebKit Linux ASAN build, and that's the suspect for root cause. See https://ci.chromium.org/p/chromium/builders/ci/WebKit%20Linux%20ASAN/17329 Original change's description: > [Perfect Negotiation] Surface session descriptions at the right time. > > This fixes another timing related issue that blocks Perfect Negotiation. > > Before this CL, current/pending local/remote description attributes do > blocking-invokes on the webrtc thread, fetching the most up-to-date > states. This can prematurely expose the result of "in-parallel" > operations that have not surfaced yet, such as: > - setLocalDescription > - setRemoteDescription > - addIceCandidate > > This CL fixes that by copying the SDP states when any of these > operations complete on the WebRTC thread and carry them over in the > PostTask to the main thread. Here, we store these snapshots in > "internal slots" (variables living on the main thread). With this CL, > reading SDP attributes from RTCPeerConnection is non-blocking and > spec-compliant. > > WPT test coverage added for the exact timing of SLD/SRD and other test > expectations are updated. addIceCandidate updating the SDP is already > covered by old WPTs. > > Bug: chromium:1110347 > Change-Id: Id41ec354465525c6cedf631fe2209fe097148f60 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2323359 > Commit-Queue: Henrik Boström <hbos@chromium.org> > Reviewed-by: Harald Alvestrand <hta@chromium.org> > Cr-Commit-Position: refs/heads/master@{#801798} TBR=hta@chromium.org,hbos@chromium.org Change-Id: I4af12fd1430773ea3d134cfc37b9c5e736f20ed0 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1110347 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2377715 Reviewed-by: Amr Aboelkher <amraboelkher@google.com> Commit-Queue: Amr Aboelkher <amraboelkher@google.com> Cr-Commit-Position: refs/heads/master@{#801822}

view details

Camille Lamy

commit sha 677c57c0e8816b0892cc3ae1c2772189b1bdcf65

COOP: add reporting to redirects This CL allows reporting browsing context group switches triggered by redirects and updates the reports sent in this case to the latest version of the spec PR (https://github.com/whatwg/html/pull/5518). Since the status of COOP was becoming hard to track, I moved it to its own class for better encapsulation. Bug: 1059303 Change-Id: Ifafb23073301bd05cd9ce83fdb0b748c28e8a51f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2352880 Commit-Queue: Camille Lamy <clamy@chromium.org> Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org> Reviewed-by: Mike West <mkwst@chromium.org> Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Cr-Commit-Position: refs/heads/master@{#799863}

view details

Lan Wei

commit sha 87182036f426e22ae4de0c3a53dea1ce8328f08f

[Webdriver] Close the window after the drag and drop pointer test Right now the Action API cannot generate the drag and drop actions by sending the mouse press, mouse move and mouse release, because the drag and drop events are generated from the OS level. Therefore, Webdriver WPT test test_drag_and_drop_with_draggable_element will fail and the dragged element is still been dragged, the rest of tests will fail because all the following mouse actions would not work correctly. I add a fixture_session function to open a new window for every test. Bug: 850071 Change-Id: Iaa00e8980567cebc70046fd244ecdc1376bf785a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2368713 Reviewed-by: John Chen <johnchen@chromium.org> Commit-Queue: Lan Wei <lanwei@chromium.org> Cr-Commit-Position: refs/heads/master@{#801898}

view details

Christopher Cameron

commit sha a33685feed3045f791d86e2fb09b0237bce59602

Remove createImageData that takes an ImageDataArray The following function exists but is not documented in any spec: [RuntimeEnabled=CanvasColorManagement, RaisesException] ImageData createImageData( ImageDataArray data, unsigned long sw, unsigned long sh, ImageDataColorSettings imageDataColorSettings); Remove it. Bug: 1119507 Change-Id: Ic3bd46c30e9ff2937a4edf817d8002ef97b57c02 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2364758 Reviewed-by: Yi Xu <yiyix@chromium.org> Reviewed-by: Fernando Serboncini <fserb@chromium.org> Commit-Queue: ccameron <ccameron@chromium.org> Cr-Commit-Position: refs/heads/master@{#801984}

view details

Gérard Talbot

commit sha a18247887493f153823ed7d9d85126bd55668bc1

Added 2 selection-overlay-* tests with their respective references (#24985)

view details

Henrik Boström

commit sha e4b1b97671ed9e404d7d4cc58237b28711501071

Revert "[Sheriff] Revert "[Perfect Negotiation] Surface session descriptions at the right time."" This reverts commit 3dbd8ec27d4b3dbf0b53d534a3a180886196361f. Reason for revert: I don't think this is the culprit and it looks like this test has been flaking for a couple of weeks, see: https://analysis.chromium.org/p/chromium/flake-portal/flakes/occurrences?key=ag9zfmZpbmRpdC1mb3ItbWVyWAsSBUZsYWtlIk1jaHJvbWl1bUBibGlua193ZWJfdGVzdHNAZXh0ZXJuYWwvd3B0L3dlYnJ0Yy9wcm90b2NvbC9jcnlwdG8tc3VpdGUuaHR0cHMuaHRtbAw More details here: https://bugs.chromium.org/p/chromium/issues/detail?id=1122106 Original change's description: > [Sheriff] Revert "[Perfect Negotiation] Surface session descriptions at the right time." > > This reverts commit 3bc91ccc927f8eb887a84a1e59f34c88518ce2ab. > > Reason for revert: Failure of WebKit Linux ASAN build, and that's the suspect for root cause. See https://ci.chromium.org/p/chromium/builders/ci/WebKit%20Linux%20ASAN/17329 > > Original change's description: > > [Perfect Negotiation] Surface session descriptions at the right time. > > > > This fixes another timing related issue that blocks Perfect Negotiation. > > > > Before this CL, current/pending local/remote description attributes do > > blocking-invokes on the webrtc thread, fetching the most up-to-date > > states. This can prematurely expose the result of "in-parallel" > > operations that have not surfaced yet, such as: > > - setLocalDescription > > - setRemoteDescription > > - addIceCandidate > > > > This CL fixes that by copying the SDP states when any of these > > operations complete on the WebRTC thread and carry them over in the > > PostTask to the main thread. Here, we store these snapshots in > > "internal slots" (variables living on the main thread). With this CL, > > reading SDP attributes from RTCPeerConnection is non-blocking and > > spec-compliant. > > > > WPT test coverage added for the exact timing of SLD/SRD and other test > > expectations are updated. addIceCandidate updating the SDP is already > > covered by old WPTs. > > > > Bug: chromium:1110347 > > Change-Id: Id41ec354465525c6cedf631fe2209fe097148f60 > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2323359 > > Commit-Queue: Henrik Boström <hbos@chromium.org> > > Reviewed-by: Harald Alvestrand <hta@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#801798} > > TBR=hta@chromium.org,hbos@chromium.org > > Change-Id: I4af12fd1430773ea3d134cfc37b9c5e736f20ed0 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: chromium:1110347 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2377715 > Reviewed-by: Amr Aboelkher <amraboelkher@google.com> > Commit-Queue: Amr Aboelkher <amraboelkher@google.com> > Cr-Commit-Position: refs/heads/master@{#801822} TBR=hta@chromium.org,hbos@chromium.org,amraboelkher@google.com Change-Id: Ia0f82e0d1b4660cf0d3641aaa446127092c6e6f7 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1110347 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2379192 Reviewed-by: Henrik Boström <hbos@chromium.org> Commit-Queue: Henrik Boström <hbos@chromium.org> Cr-Commit-Position: refs/heads/master@{#802114}

view details

Raphael Kubo da Costa

commit sha 619e1b308d51f31e1c16557980c3037f41514739

docs: Mention the python-unversioned-command package on Fedora. (#25244) Fedora does not ship a `/usr/bin/python` by default anymore, but does have a separate package that provides a `python` symlink to the `python3` binary. While here, also mention a similar package that is required in Ubuntu Focal and later, and clarify that Python 3 is no longer unsupported. Fixes #20035.

view details

Matt Woodrow

commit sha a08ccea0ab64c7139447f9863817ad13375467e0

Fire pageshow event when we finish loading a Document.open load, if we haven't already fired one for the Document. Differential Revision: https://phabricator.services.mozilla.com/D84934 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1643204 gecko-commit: 35784e7b70b0a74b09d1f4bdb65ed337b629b240 gecko-integration-branch: autoland gecko-reviewers: smaug

view details

Yutaka Hirano

commit sha 792570a8eca832f7569b34e5b467dc613fb525cf

Augment COEP violation report This implements https://github.com/whatwg/html/pull/5848. - Add "blockedURL" (we'll keep "blocked-url" for some time). - Add "disposition". - Add "destination". There are subtle bugs in WPTs (https://github.com/web-platform-tests/wpt/pull/25177). Fix them. Bug: 1119676 Change-Id: I9b83f18d9881b2742bafd88405b57645a67cac49 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2373970 Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Reviewed-by: Makoto Shimazu <shimazu@chromium.org> Reviewed-by: Domenic Denicola <domenic@chromium.org> Commit-Queue: Yutaka Hirano <yhirano@chromium.org> Cr-Commit-Position: refs/heads/master@{#802161}

view details

Byron Campen [:bwc]

commit sha 5137b6aac0cd391ddfb94a98af4c51c0c3fac409

Make sure transports are set up in have-local-offer. Differential Revision: https://phabricator.services.mozilla.com/D86223 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1657394 gecko-commit: 5470a86abcf9a7a1056c2b5d3977a2edf0752a6c gecko-integration-branch: autoland gecko-reviewers: mjf

view details

Eric Willigers

commit sha dfc3713eaa08478253630e2098e432fdf0653e96

Direct Sockets: stub implementations for openTCPSocket openUDPSocket The rename is tentative, blocked on naming decision https://github.com/WICG/raw-sockets/issues/10 Explainer: https://github.com/WICG/raw-sockets/blob/master/docs/explainer.md Intent to Prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/ARtkaw4e9T4/m/npjeMssPCAAJ Design doc: https://docs.google.com/document/d/1Xa5nFkIWxkL3hZHvDYWPhT8sZvNeFpCUKNuqIwZHxnE/edit?usp=sharing We introduce IDL methods for opening TCP and UDP sockets. We introduce a mojom service that will perform permission checks before forwarding socket opening requests to the Network Service. Not yet implemented: Permissions checks, calls to Network Service Bug: 909927 Change-Id: Ifec9860d4e0b8211af7b142b856efc29cd6f9b35 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2366395 Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Reviewed-by: Matt Falkenhagen <falken@chromium.org> Reviewed-by: Glen Robertson <glenrob@chromium.org> Commit-Queue: Eric Willigers <ericwilligers@chromium.org> Auto-Submit: Eric Willigers <ericwilligers@chromium.org> Cr-Commit-Position: refs/heads/master@{#802210}

view details

push time in 23 days

pull request commentweb-platform-tests/wpt

Add interfaces/screen-wake-lock.idl

@stephenmcgruer The IDL looks fine, but we already have wake-lock.idl here, so I have a few questions:

  • Was this one created because we published a new TR with the new short name last week?
  • How should one deal with both IDL files? Does wake-lock.idl have to be deleted manually and will tests need to be adjusted?
  • If this file was created because of the TR, does it mean it won't be updated with changes to the ED?
autofoolip

comment created time in 24 days

delete branch rakuco/wake-lock

delete branch : make-request-type-optional

delete time in 24 days

push eventw3c/screen-wake-lock

Raphael Kubo da Costa

commit sha 58a7bb0045677a59f117ee5a9af60e257d28970c

Make "type" an optional parameter for WakeLock.request(). (#291) And make it default to "screen". Existing code continues to work, while new code can also call `navigator.wakeLock.request()` to request a screen wake lock. Issues #253, #255 and #288 indicate that there is a preference for making `type` an optional parameter that just got overlooked.

view details

push time in 24 days

PR merged w3c/screen-wake-lock

Make "type" an optional parameter for WakeLock.request().

And make it default to "screen". Existing code continues to work, while new code can also call navigator.wakeLock.request() to request a screen wake lock.

Issues #253, #255 and #288 indicate that there is a preference for making type an optional parameter that just got overlooked.

The following tasks have been completed:

  • [x] Modified Web platform tests (https://github.com/web-platform-tests/wpt/pull/25946)

Implementation commitment:

  • [x] Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=1133696)
  • [x] Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=1589554)
  • WebKit - Not participating in this working group.

<!-- This comment and the below content is programatically generated. You may add a comma-separated list of anchors you'd like a direct link to below (e.g. #idl-serializers, #idl-sequence):

Don't remove this comment or modify anything below this line.
If you don't want a preview generated for this pull request,
just replace the whole of this comment's content by "no preview"
and remove what's below.

-->


<a href="https://pr-preview.s3.amazonaws.com/rakuco/wake-lock/pull/291.html" title="Last updated on Oct 5, 2020, 7:17 AM UTC (b00fff3)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/screen-wake-lock/291/f89b85a...rakuco:b00fff3.html" title="Last updated on Oct 5, 2020, 7:17 AM UTC (b00fff3)">Diff</a>

+4 -3

0 comment

2 changed files

rakuco

pr closed time in 24 days

push eventrakuco/wake-lock

Raphael Kubo da Costa

commit sha b00fff30d9361be07d7ac22490363a6fc7942a18

explainer: Formatting changes.

view details

push time in 24 days

Pull request review commentw3c/screen-wake-lock

Make "type" an optional parameter for WakeLock.request().

 if (lock.released === false) {  ### Requesting permission to use WakeLocks To use the API, one must request access via-`navigator.wakeLock.request("screen")`. This returns a promise which, if-allowed by the user, resolves with a `WakeLockSentinel`.+`navigator.wakeLock.request("screen")` (_"screen"_ is optional). This

Done!

rakuco

comment created time in 24 days

PullRequestReviewEvent

push eventrakuco/wake-lock

Fuqiao Xue

commit sha 5daed8cc8927ab3fca48b067749063cea7def049

Update the Changes section (#290)

view details

Fuqiao Xue

commit sha f78cedbaa212038ca3ef4b1f7fc8f4426fcdf3df

chore: add lang="en"

view details

Raphael Kubo da Costa

commit sha f89b85a4d9fd5f6f8494d44da35514d21f5b3c9e

explainer: Link to issues where System Wake Locks were discussed. (#292) Address feedback from w3ctag/design-reviews#543: > Also, a link out to discussion of that API might also be useful context.

view details

Raphael Kubo da Costa

commit sha 47589be3682b418b2e05dbc737ed5ee49619685d

Make "type" an optional parameter for WakeLock.request(). And make it default to "screen". Existing code continues to work, while new code can also call `navigator.wakeLock.request()` to request a screen wake lock. Issues #253, #255 and #288 indicate that there is a preference for making `type` an optional parameter that just got overlooked.

view details

Raphael Kubo da Costa

commit sha 1c19a60bee30b6400bf13f7f51825bb614f1454e

explainer: Formatting changes.

view details

push time in 24 days

Pull request review commentOSSystems/meta-browser

chromium: add patch to include uint64_t in sim_hash namespace

+From 6284aee59f251bfe4b52d200b530ae8a98186adb Mon Sep 17 00:00:00 2001

To clarify: the idea is to backport the upstream fix (https://chromium-review.googlesource.com/c/chromium/src/+/2273161). You sign-off-by above the change, but maintain the proper authorship in the commit message.

viatsk

comment created time in a month

PullRequestReviewEvent

delete branch rakuco/wake-lock

delete branch : explainer/system-wake-lock-discussions

delete time in a month

push eventw3c/screen-wake-lock

Raphael Kubo da Costa

commit sha f89b85a4d9fd5f6f8494d44da35514d21f5b3c9e

explainer: Link to issues where System Wake Locks were discussed. (#292) Address feedback from w3ctag/design-reviews#543: > Also, a link out to discussion of that API might also be useful context.

view details

push time in a month

PR merged w3c/screen-wake-lock

Reviewers
explainer: Link to issues where System Wake Locks were discussed.

Address feedback from w3ctag/design-reviews#543:

Also, a link out to discussion of that API might also be useful context.

+8 -1

0 comment

1 changed file

rakuco

pr closed time in a month

delete branch rakuco/wake-lock

delete branch : explainer/request-arg-explanation

delete time in a month

PR closed w3c/screen-wake-lock

Reviewers
explainer: Expand on why WakeLock.request() still requires an argument.

Address feedback from w3ctag/design-reviews#543:

My only feedback would be that it would be nice to see a note explaining why you need to pass "screen" to WakeLock.request() when it's the only possible value - my guess would be that there is an intent to re-use this API for the future System Wake Lock API, but it would be good to be clear on that. Also, a link out to discussion of that API might also be useful context.

Not requiring an argument would make it difficult to support requesting other locks in an intuitive way. Also include links to issues where dropping support for System Wake Locks was discussed.

+16 -1

7 comments

1 changed file

rakuco

pr closed time in a month

pull request commentw3c/screen-wake-lock

explainer: Expand on why WakeLock.request() still requires an argument.

I've moved the non-controversial part of this PR to #292.

rakuco

comment created time in a month

PR opened w3c/screen-wake-lock

Reviewers
explainer: Link to issues where System Wake Locks were discussed.

Address feedback from w3ctag/design-reviews#543:

Also, a link out to discussion of that API might also be useful context.

+8 -1

0 comment

1 changed file

pr created time in a month

create barnchrakuco/wake-lock

branch : explainer/system-wake-lock-discussions

created branch time in a month

pull request commentw3c/screen-wake-lock

explainer: Expand on why WakeLock.request() still requires an argument.

#291 makes type optional since most people seem to favor this approach.

rakuco

comment created time in a month

issue commentw3c/screen-wake-lock

New shortname

Thanks, @anssiko and @xfq! I can confirm that our CI is finally happy and green again.

marcoscaceres

comment created time in a month

PR opened w3c/screen-wake-lock

Reviewers
Make "type" an optional parameter for WakeLock.request().

And make it default to "screen". Existing code continues to work, while new code can also call navigator.wakeLock.request() to request a screen wake lock.

Issues #253, #255 and #288 indicate that there is a preference for making type an optional parameter that just got overlooked.

The following tasks have been completed:

  • [ ] Modified Web platform tests (link to pull request)

Implementation commitment:

  • [ ] Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=)
  • [x] Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=1589554)
  • WebKit - Not participating in this working group.
+4 -3

0 comment

2 changed files

pr created time in a month

create barnchrakuco/wake-lock

branch : make-request-type-optional

created branch time in a month

push eventw3c/screen-wake-lock

Fuqiao Xue

commit sha 5daed8cc8927ab3fca48b067749063cea7def049

Update the Changes section (#290)

view details

push time in a month

PR merged w3c/screen-wake-lock

Update the Changes section

Mention WakeLockSentinel.released.

<!-- This comment and the below content is programatically generated. You may add a comma-separated list of anchors you'd like a direct link to below (e.g. #idl-serializers, #idl-sequence):

Don't remove this comment or modify anything below this line.
If you don't want a preview generated for this pull request,
just replace the whole of this comment's content by "no preview"
and remove what's below.

-->


<a href="https://pr-preview.s3.amazonaws.com/w3c/screen-wake-lock/pull/290.html" title="Last updated on Sep 28, 2020, 3:33 AM UTC (9217be9)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/screen-wake-lock/290/0b715f7...9217be9.html" title="Last updated on Sep 28, 2020, 3:33 AM UTC (9217be9)">Diff</a>

+2 -0

1 comment

1 changed file

xfq

pr closed time in a month

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

pull request commentw3c/screen-wake-lock

explainer: Expand on why WakeLock.request() still requires an argument.

The way I see it is that defaults would be fine if we had something like request(type, options) and options was optional. If we were to add more values to WakeLockType such as "system" and others, having navigator.wakeLock.request() behave like navigator.wakeLock.request("screen") feels like something we'd do just to maintain backwards compatibility -- i.e. would there be any other reason to make the default "screen" at that point?

rakuco

comment created time in a month

issue commentw3c/screen-wake-lock

User prompts to show an active screen-lock should have an associated domain

By "this" do you mean the original suggestion of making the spec also recommend showing a domain name? If so, that's what Reilly considered out of scope, so it'd be good if you could elaborate.

jumde

comment created time in a month

issue commentw3ctag/design-reviews

Screen Wake Lock API

My only feedback would be that it would be nice to see a note explaining why you need to pass "screen" to WakeLock.request() when it's the only possible value - my guess would be that there is an intent to re-use this API for the future System Wake Lock API, but it would be good to be clear on that. Also, a link out to discussion of that API might also be useful context.

Thanks, I've sent w3c/screen-wake-lock#288 to tackle this one.

xfq

comment created time in a month

PR opened w3c/screen-wake-lock

Reviewers
explainer: Expand on why WakeLock.request() still requires an argument.

Address feedback from w3ctag/design-reviews#543:

My only feedback would be that it would be nice to see a note explaining why you need to pass "screen" to WakeLock.request() when it's the only possible value - my guess would be that there is an intent to re-use this API for the future System Wake Lock API, but it would be good to be clear on that. Also, a link out to discussion of that API might also be useful context.

Not requiring an argument would make it difficult to support requesting other locks in an intuitive way. Also include links to issues where dropping support for System Wake Locks was discussed.

+16 -1

0 comment

1 changed file

pr created time in a month

create barnchrakuco/wake-lock

branch : explainer/request-arg-explanation

created branch time in a month

delete branch rakuco/wake-lock

delete branch : wip

delete time in a month

create barnchrakuco/wake-lock

branch : wip

created branch time in a month

delete branch rakuco/wake-lock

delete branch : editorial/reword-security-section

delete time in a month

push eventw3c/screen-wake-lock

Raphael Kubo da Costa

commit sha 0b715f773a843caf2d6408ad7799f4396d5399cb

editorial: Reword the Security and Privacy Considerations section. (#287) Incorporate feedback from #286, where @marcosc proposed a few changes to the part of the paragraph that had been copied from the spec: > I think say "and potentially dangerous" is going a bit overboard, tbh. > Browsers are just tapping into publicly available OS APIs to provide this > functionality (not arbitrary hacks that could cause a screen or device to > catch on fire) - and those are hardly dangerous.

view details

push time in a month

PR merged w3c/screen-wake-lock

editorial: Reword the Security and Privacy Considerations section.

Incorporate feedback from #286, where @marcosc proposed a few changes to the part of the paragraph that had been copied from the spec:

I think say "and potentially dangerous" is going a bit overboard, tbh. Browsers are just tapping into publicly available OS APIs to provide this functionality (not arbitrary hacks that could cause a screen or device to catch on fire) - and those are hardly dangerous.

<!-- This comment and the below content is programatically generated. You may add a comma-separated list of anchors you'd like a direct link to below (e.g. #idl-serializers, #idl-sequence):

Don't remove this comment or modify anything below this line.
If you don't want a preview generated for this pull request,
just replace the whole of this comment's content by "no preview"
and remove what's below.

-->


<a href="https://pr-preview.s3.amazonaws.com/rakuco/wake-lock/pull/287.html" title="Last updated on Sep 23, 2020, 9:39 AM UTC (cec0576)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/screen-wake-lock/287/c3ebf77...rakuco:cec0576.html" title="Last updated on Sep 23, 2020, 9:39 AM UTC (cec0576)">Diff</a>

+10 -11

1 comment

1 changed file

rakuco

pr closed time in a month

pull request commentw3c/screen-wake-lock

editorial: Reword the Security and Privacy Considerations section.

Thanks, I've incorporate your suggestion. AFAICS has a similar battery-saving option that users can activate too.

rakuco

comment created time in a month

Pull request review commentw3c/screen-wake-lock

editorial: Reword the Security and Privacy Considerations section.

 <h2>         Security and privacy considerations       </h2>       <p>-        Application of a wake lock causes various device components such as-        display or CPU to operate at higher power levels than they otherwise-        would. This can lead to undesirable and potentially dangerous effects-        such as excessive heating and faster than normal battery charge-        depletion. The latter is particularly relevant to mobile devices which-        may not have a stationary power source readily available. Complete-        battery depletion at an unexpected time can lead to inability of the-        user to make or receive calls and use network services, including the-        emergency call service. Implementations should consider preventing wake-        lock application if they determine that the remaining battery capacity-        is low.+        Wake locks can cause various device components such as display or CPU+        to operate at higher power levels than they otherwise would. This can+        lead to undesirable effects such as faster than normal battery charge+        depletion. This is particularly relevant to mobile devices, which may+        not have a stationary power source readily available. Complete battery+        depletion at an unexpected time can lead to inability of the user to+        make or receive calls and use network services, including the emergency+        call service. Implementations should consider preventing wake lock+        application if they determine that the remaining battery capacity is+        low.

Done!

rakuco

comment created time in a month

PullRequestReviewEvent

push eventrakuco/wake-lock

Marcos Cáceres

commit sha 5bd9a2e2b93df2a13ca31bdfab6cea2f582b78d6

Chore: ScreenWakeLock interface is not a thing

view details

Raphael Kubo da Costa

commit sha c3ebf771380d4df2b6e80f0d296bea43585dee57

Add an Explainer document to the repository. (#286) This is a short summary of what is already in the spec. The document is required as part of the TAG review process, which itself is part of #270. Fixes #284.

view details

Raphael Kubo da Costa

commit sha 1d73afe035cc3764e231358c0a8c327272d15b49

editorial: Reword the Security and Privacy Considerations section. Incorporate feedback from #286, where @marcosc proposed a few changes to the part of the paragraph that had been copied from the spec: > I think say "and potentially dangerous" is going a bit overboard, tbh. > Browsers are just tapping into publicly available OS APIs to provide this > functionality (not arbitrary hacks that could cause a screen or device to > catch on fire) - and those are hardly dangerous.

view details

Raphael Kubo da Costa

commit sha cec0576709b778ebc2b162bb2be38ee2e5a2ae81

Incorporate Marcos' suggestion.

view details

push time in a month

issue commentw3c/screen-wake-lock

Do not use allow="screen-wake-lock" for iframes

Is there anything we need to act upon here given Reilly's comment?

jumde

comment created time in a month

issue commentw3c/screen-wake-lock

User prompts to show an active screen-lock should have an associated domain

Is there anything we need to act upon here given Reilly's comment?

jumde

comment created time in a month

issue commentw3ctag/design-reviews

Screen Wake Lock API

Hi, everyone. FYI, the PR above was merged earlier today and we now have an explainer in the repository.

xfq

comment created time in a month

delete branch web-platform-tests/wpt

delete branch : chromium-export-cl-2193672

delete time in a month

PR closed web-platform-tests/wpt

sensors: Try to fix flakiness in iframe-related Generic Sensor tests. chromium-export do not merge yet generic-sensor wg-das

The second test, for focus traversal within same-origin frames, was occasionally failing, especially in the Mac bots.

The flakiness seems to come from the way the "is_sensor_suspended" command was implemented in iframe_sensor_handler.html. The sensor in the iframe was created with the default frequency of 5Hz and, consequently, a period of 200ms. "is_sensor_suspended" tried to detect whether the sensor was suspended by either receiving a new "reading" event (in which case the sensor was not suspended), or by reaching a timeout function with a period of 250ms (200ms from the sensor + a small delay).

In some cases, it looks like the 250ms were not enough and we reached the timeout function prior to the sensor emitting a new "reading" event. Try to fix this by using a longer timeout of twice the sensor's period to be more certain that if we reach that code at least one event should have been emitted before.

While here, make the code easier to follow by documenting what we are doing and relying on fewer magic numbers, and increase the sensor frequency so that the test does not take unnecessarily long to run.

Bug: 1073865 Change-Id: I630ad6034f0839c17f11f111ead24a88affc9dd2 Reviewed-on: https://chromium-review.googlesource.com/2193672 WPT-Export-Revision: c6de5bb666abf21c56e386d67de05a95eeb63589

+25 -13

1 comment

1 changed file

chromium-wpt-export-bot

pr closed time in a month

pull request commentweb-platform-tests/wpt

sensors: Try to fix flakiness in iframe-related Generic Sensor tests.

This CL was superseded by another one. I'll close this one manually now that I've abandoned the CL in Gerrit too.

chromium-wpt-export-bot

comment created time in a month

pull request commentweb-platform-tests/wpt

sensors: Cleanup iframe-related tests.

Whoa, that was fast :-) Thanks!

chromium-wpt-export-bot

comment created time in a month

delete branch rakuco/wpt

delete branch : sensors/wip

delete time in a month

pull request commentweb-platform-tests/wpt

sensors: Cleanup iframe-related tests.

@stephenmcgruer can you force-merge this one? This is https://crbug.com/1126926 again (there's a fix in the works that should land soon).

chromium-wpt-export-bot

comment created time in a month

delete branch rakuco/wake-lock

delete branch : add-explainer

delete time in a month

push eventw3c/screen-wake-lock

Raphael Kubo da Costa

commit sha c3ebf771380d4df2b6e80f0d296bea43585dee57

Add an Explainer document to the repository. (#286) This is a short summary of what is already in the spec. The document is required as part of the TAG review process, which itself is part of #270. Fixes #284.

view details

push time in a month

PR merged w3c/screen-wake-lock

Reviewers
Add an Explainer document to the repository.

This is a short summary of what is already in the spec. The document is required as part of the TAG review process, which itself is part of #270.

Fixes #284.

+111 -0

5 comments

1 changed file

rakuco

pr closed time in a month

issue closedw3c/screen-wake-lock

Add explainer to the spec repo

Even though this spec is fairly old, we need an explainer for the TAG review (#270, w3ctag/design-reviews#543).

closed time in a month

rakuco

pull request commentw3c/screen-wake-lock

Add an Explainer document to the repository.

Thanks for the review, everyone. It looks like this is finally ready for merging!

rakuco

comment created time in a month

Pull request review commentw3c/screen-wake-lock

Add an Explainer document to the repository.

+# Screen Wake Lock API++## Introduction+The **Screen Wake Lock API** allows web applications to prevent a device's+screen from dimming and locking.++See also:+* [The current specification](https://w3c.github.io/screen-wake-lock/)+* [web.dev article](https://web.dev/wakelock/) on the Screen Wake Lock API++## Why?+To avoid draining the battery, most devices quickly go to sleep when left idle.+While this is fine most of the time, some applications need to keep the screen+awake to complete their work. For example:++* A recipe website that keeps the screen on while you are cooking.+* A web page that presents a bar code, which has to be physically scanned by+  another person.+* A web page that provides monitoring or dashboard-style functionality where the+  screen must be on at all times.+* A web-based presentation app that keeps the screen on during a presentation.++Without this API, web developers have had to rely on libraries such as+[NoSleep.js](https://github.com/richtr/NoSleep.js), which essentially added a+[small+video](https://github.com/richtr/NoSleep.js/blob/eaf52afd1dfbb80145b4a39f3ec29307b80ab154/src/index.js#L37-L57)+to a page to keep the display on.++> Recent NoSleep.js releases have added support for the Screen Wake Lock API.++The purpose of this specification is to allow sites to be explicit about when+they want to acquire a wake lock so that browsers can provide better automated+and manual controls to prevent intentional and incidental issues.++## Non-goals+A previous iteration of this spec included both Screen and System wake locks,+which prevented the CPU from entering a deep power state. The latter has been+moved to a separate spec, and is out of scope for this explainer.++## API+Users can request a screen wake lock, and if the request succeeds it can be+either manually released later or released automatically by the platform due to+OS-specific policies that might be in place. The code looks like this:++```js+const lock = await navigator.wakeLock.request("screen");++lock.addEventListener("release", doSomething);++// Later, check and release the lock if necessary.+if (lock.released === false) {+    await lock.release();

Fixed, thanks.

rakuco

comment created time in a month

PullRequestReviewEvent

push eventrakuco/wake-lock

Raphael Kubo da Costa

commit sha ead8b7e5b08b9bdde9e9b9d72177ee49cfc1745e

Stop checking if "acquire the wake lock" succeeds. (#285) Not to be confused with the "acquire a wake lock" algorithm. The latter used to call the former and check if it succeeded, which indicated that a lock had been successfully obtained from the operating system. This could potentially leak user information, as an "acquire the wake lock" failure could indicate that the user's system was in low power mode or had a low battery level. Now failures to acquire an operating system lock are indistiguishable from successful acquisitions; in both cases, WakeLock.request() will ultimately resolve the promise it returns with a WakeLockSentinel. This spec change also matches the current Blink implementation, which never checked if the platform wake lock acquisition succeeded. This implementation has been shipping to users with no adverse feedback. Fixes #247.

view details

Marcos Cáceres

commit sha 5bd9a2e2b93df2a13ca31bdfab6cea2f582b78d6

Chore: ScreenWakeLock interface is not a thing

view details

Raphael Kubo da Costa

commit sha de5acc0856cd0402860985412c4d7e06e2e4756c

Add an Explainer document to the repository. This is a short summary of what is already in the spec. The document is required as part of the TAG review process, which itself is part of #270. Fixes #284.

view details

Raphael Kubo da Costa

commit sha 0e4e813c82e5f7de62481ee93906614b494038bc

Incorporate feedback from the previous iteration. * Why - Stop mentioning "apps", reword the kiosk entry to make the use case more explicit. * Non-goals - Briefly describe what the system wake lock API did. * API - Do not say the API surface is not big. - Rework the example code. - Drop "Wake Lock" subsection, just mention how a lock is requested. - Stop referring to WakeLockSentinel.release() as if it were a static method. * Security considerations - Also do not refer to WakeLockSentinel.release() as a static method. - Be more clear about how acquired locks are advisory-only. - Reword the item about battery consumption and battery depletion.

view details

Raphael Kubo da Costa

commit sha 6fa97f3e1509912f650f08f6ea53a356c2cae0f2

Fix indentation in code sample

view details

push time in a month

push eventrakuco/chromium

Yuki Shiino

commit sha af437ae71229b00421812b9c332708864af1163e

Revert "clang tot bots: Force-enable memoryssa-based dse" This reverts commit a359d11d88e37322b3d36393a4f33d3061da63c1. Reason for revert: Suspicious to be causing test failures on several bots. Examples are: https://ci.chromium.org/p/chromium/builders/ci/Cast%20Audio%20Linux https://ci.chromium.org/p/chromium/builders/ci/Mac10.10%20Tests Original change's description: > clang tot bots: Force-enable memoryssa-based dse > > Now that the flag is off-by-default again upstream, let's force it on > on the tot bots to see if things work with it on. > > TBR=akhuang > > Bug: 1127713 > Change-Id: Ib9267b5123472b1c28280d858da7229b140a3b7e > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2415222 > Reviewed-by: Nico Weber <thakis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#807727} TBR=thakis@chromium.org,akhuang@google.com Change-Id: I794de306768b4415f5404cacab6a69862d4f81e1 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 1127713 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2413686 Reviewed-by: Yuki Shiino <yukishiino@chromium.org> Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Cr-Commit-Position: refs/heads/master@{#807745}

view details

chrome-release-bot

commit sha 70a60d856acd808015a86dff0a687473fdaf3c31

Updating trunk VERSION from 4266.0 to 4267.0 # This is an automated release commit. # Do not revert without consulting chrome-pmo@google.com. NOAUTOREVERT=true TBR=kariah@chromium.org Change-Id: I807eb80d13a70a14c6e1aedfe08efd5e057e1c0e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2415668 Reviewed-by: Chrome Release Bot (LUCI) <chrome-official-brancher@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#807746}

view details

Brandon Wylie

commit sha 80a4ae6f0d790793d0eed69fc5603be8e8a2d23b

Inject ObservableSupplier<TabModelSelector> into ToolbarManager Bug: 1113364 Change-Id: Ie32f243366da8081e9b7f1b8bfdf01fb64b38780 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2402288 Commit-Queue: Brandon Wylie <wylieb@chromium.org> Reviewed-by: Ted Choc <tedchoc@chromium.org> Reviewed-by: Patrick Noland <pnoland@chromium.org> Cr-Commit-Position: refs/heads/master@{#807747}

view details

Trevor Perrier

commit sha a16a0300212734b10904c76c4b7b0c867be1d448

[Android] add SplitCompat.installActivity for language splits This CL runs |SplitCompat.installActivity| in |ChromeActivity| for bundle builds that have an app override language set. Currently the Android language decouple only works for languages already in the list of system languages. These language splits are stored in /data/app while language splits downloaded by the app are stored in /data/data/. |SplitCompat.installActivity| should let Chrome activities use the language splits in /data/data/. Bug: 1128698 Change-Id: I61fe63cdadbbc9f26d8beca2ba34f0631f65d0bb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2412824 Reviewed-by: Fred Mello <fredmello@chromium.org> Reviewed-by: Andrew Grieve <agrieve@chromium.org> Commit-Queue: Trevor Perrier <perrier@chromium.org> Cr-Commit-Position: refs/heads/master@{#807748}

view details

Alexander Surkov

commit sha 7f943b2ba86025edd4a6ef692829e58d18551cce

ax_dump_tree tool: support pre-defined list of application selectors Support calls like ax_dump_tree --chromium to dump Chromium acctree. Prototype the feature on mac. Bug: 1124366 Change-Id: I5b02161d6542cd4be9963045d149fca078cfff04 AX-Relnotes: n/a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2410027 Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Commit-Queue: Alexander Surkov <asurkov@igalia.com> Cr-Commit-Position: refs/heads/master@{#807749}

view details

Kenichi Ishibashi

commit sha 140a418de388b5bb0fbc38f14218da4be111be89

service worker: Allow lazy initialization for all storage operations ServiceWorkerStorage had assertions that some methods like UpdateToActiveState() should always be called after other methods like FindRegistrationXXX(). While these were valid assertions, these would not be satisfied any longer when ServiceWorkerStorage is moved to the Storage Service and it starts supporting crash recovery. Any public storage methods can be called without preliminary method calls after the Storage Service recovered. This CL replaces these assertions with lazy initializations. Bug: 1055677 Change-Id: Ic6e69ea9c4b6e20839445a6788a575503e3fe0df Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2409483 Commit-Queue: Kenichi Ishibashi <bashi@chromium.org> Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org> Cr-Commit-Position: refs/heads/master@{#807750}

view details

Andrew Grieve

commit sha 747b540db9d07d920cd71cd582a9bcf3582d63c4

SuperSize: Measure section_sizes from stripped .so When analyzing .so files that are not from .apk files, unstripped .so files must be used to get symbol information, but it's not useful to report unstripped section_sizes. Rather than add a --stripped-elf-file parameter, always run "strip" before measuring section sizes (since the command is really fast). Bug: None Change-Id: I840fe02a9d3795cb8b1ba3f46c909f20f9997062 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2411651 Reviewed-by: Samuel Huang <huangs@chromium.org> Commit-Queue: Andrew Grieve <agrieve@chromium.org> Cr-Commit-Position: refs/heads/master@{#807751}

view details

Takuto Ikuta

commit sha 2c73de6657566890660210e01755237d76bdf4d7

Revert "infra/config: All builders use a task service account for Goma access." This reverts commit 281923e590e59a9dcc71039145f2820c8d338682. Reason for revert: https://crbug.com/1129271 Original change's description: > infra/config: All builders use a task service account for Goma access. > > Made all builders to use the task service account to access Goma. > I removed options from lib and made use_luci_auth=true mandatory. > > Bug: crbug.com/1105814 > Change-Id: I8c0dff203a96e34db0b5ec1ac79b70289e2ae9e3 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2411561 > Reviewed-by: Takuto Ikuta <tikuta@chromium.org> > Commit-Queue: Yoshisato Yanagisawa <yyanagisawa@chromium.org> > Cr-Commit-Position: refs/heads/master@{#806951} TBR=ukai@google.com,yyanagisawa@chromium.org,tikuta@chromium.org,yekuang@google.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: crbug.com/1105814, 1129271 Change-Id: Ic626ee4d6e86bbc9d0e15bbe6f8be89e414bcdd2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2415749 Reviewed-by: Takuto Ikuta <tikuta@chromium.org> Commit-Queue: Takuto Ikuta <tikuta@chromium.org> Cr-Commit-Position: refs/heads/master@{#807752}

view details

Joel Hockey

commit sha 5a94b5d03f8fa59a82a3137841f0467de1c34b8e

Update Parallels USB Notification strings Matching mocks at go/parallels-design TBR=jamescook@chromium.org Bug: 1129266 Change-Id: I859353032b5695738f3f026fbaf3890f29d8a669 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2413678 Commit-Queue: Joel Hockey <joelhockey@chromium.org> Reviewed-by: Nicholas Verne <nverne@chromium.org> Auto-Submit: Joel Hockey <joelhockey@chromium.org> Cr-Commit-Position: refs/heads/master@{#807753}

view details

Giovanni Ortuño Urquidi

commit sha 24dba768319208d4c5c753a9712ace3671c0cca5

docs: Add FAQ for chrome-untrusted:// Explains what chrome-untrusted:// is and why was it introduced. Change-Id: Ib7795aff9a10c111becebb12794610eac0c9d944 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2359857 Commit-Queue: Giovanni Ortuño Urquidi <ortuno@chromium.org> Reviewed-by: Nasko Oskov <nasko@chromium.org> Cr-Commit-Position: refs/heads/master@{#807754}

view details

Xiaohan Wang

commit sha 009c084df4c2a2c6843683aa33ddfccb64e3f7e4

content: Add comment for WebContents::FromRenderFrameHost() Make it clear that it's unsafe to use this on invalid RFH pointers. Courtesy of dcheng@ for pointing this out in a code review. Change-Id: Ide6d6a3ca7274d1179109ca05463416a4c5696c2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2415428 Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Commit-Queue: Xiaohan Wang <xhwang@chromium.org> Cr-Commit-Position: refs/heads/master@{#807755}

view details

Lukasz Anforowicz

commit sha 18bbe3906592b8cbee2a304ff6a8aab11532954d

Emitting union fields into a blocklist. Unions may bypass the conversion between raw pointers and the CheckedPtr representation (that stores extra information in the top bits). This may lead to runtime crashes (e.g. when storing a pointer into a union as a raw-pointer, but extracting/dereferencing it as a CheckedPtr; OTOH we note that such coding pattern might in general result in an undefined behavior - https://en.cppreference.com/w/cpp/language/union says "[i]t's undefined behavior to read from the member of the union that wasn't most recently written"). Additionally, presence of a CheckedPtr might mean that a union destructor will be deleted (if CheckedPtr has a non-trivial destructor). This may introduce build errors after the rewritten code is used with BackupRefPtr variant of CheckedPtr. Because of the problems above, after this CL the rewriter will emit union fields as blocklist candidates. Bug: 1069567 Change-Id: I7295a3025bf14d7337430f5ee4dc5d0f5b151fd2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2228126 Auto-Submit: Łukasz Anforowicz <lukasza@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Bartek Nowierski <bartekn@chromium.org> Commit-Queue: Daniel Cheng <dcheng@chromium.org> Cr-Commit-Position: refs/heads/master@{#807756}

view details

Austin Tankiang

commit sha cd57447975c538651efa6c9a30e05302ff17fd02

Show Available Offline toggle in Files App action bar This adds a toggle to the action bar to allow the user to toggle the offline availability of files. Also change the corresponding command to get entries from selection as it is only used on the file list and never in the directory tree. The entire dialog-header should have font size 14px, so move that too. Bug: 1115025 Change-Id: I734c2939002728c492a9e042fb8302ce7b907e94 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2409687 Reviewed-by: Luciano Pacheco <lucmult@chromium.org> Commit-Queue: Austin Tankiang <austinct@chromium.org> Cr-Commit-Position: refs/heads/master@{#807757}

view details

Josh Nohle

commit sha 8fd85c2410c1f08e780f78d7c5f11b888cf44bc4

[Nearby] Fix DCHECK on contacts download failure Reset the contact downloader if the download fails. Adjusted unit test to pass only if the contact downloader is reset. Change-Id: Id684f77127280a6a6585618d5c75236b9ad92c9b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2414780 Commit-Queue: Josh Nohle <nohle@chromium.org> Commit-Queue: James Vecore <vecore@google.com> Auto-Submit: Josh Nohle <nohle@chromium.org> Reviewed-by: James Vecore <vecore@google.com> Cr-Commit-Position: refs/heads/master@{#807758}

view details

Peter Boström

commit sha e5835ffb9e9f0d67e433f9d11d72f80f3246efa2

Add dialog Checkbox support to DialogModel Refactors SessionCrashedBubbleView to use DialogModel. Adds a DialogModelLabel which supports links for text and refactors body text to share that code. These are used for DialogModelCheckbox as well. Bug: 1106422 Change-Id: I573d685d87674be72e3cd8122ec481be72cd089d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2407334 Commit-Queue: Peter Boström <pbos@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org> Cr-Commit-Position: refs/heads/master@{#807759}

view details

Reilly Grant

commit sha bec989db340fbd03c364070a737852cf1a70e9b8

location: Fix crash when dismissing content settings bubble If the content settings bubble for the geolocation permission is showing the "turned off" message because system-level geolocation permission is denied a NOTREACHED() was reachable because the radio buttons normally shown in this bubble are hidden. This change tracks whether the UI is in this state and disables the call to CommitChanges() that normally happens when the dialog is closed. Bug: 1128118 Change-Id: I0039b0c061dd95a330b936c39b9bde714fb31071 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2411450 Reviewed-by: Martin Šrámek <msramek@chromium.org> Commit-Queue: Reilly Grant <reillyg@chromium.org> Cr-Commit-Position: refs/heads/master@{#807760}

view details

Reilly Grant

commit sha 276d5294277a540bb0862369fa3b8a4040d9e99e

Fix ContentSettingBubbleModelTest.Geolocation with Core Location API This change fixes the ContentSettingBubbleModelTest.Geolocation unit test when the macOS Core Location API is enabled, as this adds a new state the UI can be in when system-level location permission has been denied. Bug: 1051591 Change-Id: I59325fa180e9e2a4f8ea5d0295f34287fd4f3cd5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2413208 Commit-Queue: Reilly Grant <reillyg@chromium.org> Auto-Submit: Reilly Grant <reillyg@chromium.org> Reviewed-by: Martin Šrámek <msramek@chromium.org> Cr-Commit-Position: refs/heads/master@{#807761}

view details

Clark DuVall

commit sha 2c43385a51e189b4d36d1827e2d146bc38403f40

Reland "Add build flag for building //chrome in a DFM" This is a reland of eea2a6fbd8fb51a7c1ab57cc6c1c878789e21e79 Original change's description: > Add build flag for building //chrome in a DFM > > This change adds much of the support needed for building //chrome in a > DFM. Some TODOs have been scattered around for follow up changes. A gn > flag enable_chrome_module has been added to toggle the DFM. > > The main pieces here are (when the gn flag is enabled): > 1. All //chrome Java code will be moved into a "chrome" DFM. > > 2. All DFM Java code will also be moved into the chrome DFM. > > 3. All //chrome-specific definitions in the <application> manifest are > moved to the "chrome" DFM manifest. This was done by moving all of > the definitions in the main AndroidManifest.xml into a jinja macro > which can either be called in the main AndroidManifest.xml or in > the DFM AndroidManifest.xml. > > 4. Resources needed in the base AndroidManfiest.xml are moved to a > separate target so they can be included only in the base module. > > 5. Changes were added to lint.py to allow linting the chrome DFM > manifest along with the base manifest to avoid unused resource > errors. > > Still TODO in follow ups: > - Address TODOs added in this change. > - Make a similar change in //clank. > - Deal with org.chromium.chrome.browser.ChromeBackupAgent which must > be referenced in application tag of the base manifest, but will be > defined in the chrome DFM. > - Change the application class to allow loading with isolated splits. > - Collect loadable modules from DFMs and put in base. > - Probably more... > > Bug: 1126301 > Change-Id: I3fac243101eb2fb1e4af21ee99c2349fb074677b > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2412553 > Reviewed-by: Matthew Jones <mdjones@chromium.org> > Reviewed-by: Andrew Grieve <agrieve@chromium.org> > Commit-Queue: Clark DuVall <cduvall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#807704} TBR=agrieve@chromium.org,mdjones@chromium.org Bug: 1126301 Change-Id: Ia1af90628c17c3d538c2fea4d48584bcc09ae725 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2415489 Reviewed-by: Clark DuVall <cduvall@chromium.org> Reviewed-by: Andrew Grieve <agrieve@chromium.org> Commit-Queue: Clark DuVall <cduvall@chromium.org> Cr-Commit-Position: refs/heads/master@{#807762}

view details

chromium-autoroll

commit sha f42d0095c4d786f075f2446aab5fefb866c53930

Roll Dawn from c23676954838 to 19b910d7964b (1 revision) https://dawn.googlesource.com/dawn.git/+log/c23676954838..19b910d7964b 2020-09-16 cwallez@chromium.org Make dawn components support CMake's BUILD_SHARED_LIBS 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 cwallez@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: cwallez@google.com Change-Id: I21db8799c13d31375002abac0c9abcd05475aa6b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2414639 Reviewed-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@{#807763}

view details

Leo Zhang

commit sha 48d76d3dd6b25f6087957976ab977a4de4f6e5a1

Detect the text input host for better input experience. Provide some basic info of the host of the focused text field to system IME via private extension API. With these information, IME will identify some known faulty clients then demote its input.ime APIs (even disable advanced features) to make the typing on these client works basically. Context for the CL: Due to some faulty implementation of their text operations in some clients' text field (e.g. Terminal for Linux, Text app, Android app...) in ChromeOS, they don't work not properly with predefined ChromeOS IME APIs (e.g. chrome.input.ime.deleteSurroundingText, setComposingRange...). Therefore, typing on these client are always difficult with unexpected results. Detailed example can be found in the bugs attached. Tested=Some popular cases in local VM and Kevin device in skylib. Bug: b/162183648,b/163645900 Change-Id: Ib43e9ccba7e9620b7189153d956ef685f80fb29d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2405046 Commit-Queue: Leo Zhang <googleo@chromium.org> Reviewed-by: Devlin <rdevlin.cronin@chromium.org> Reviewed-by: Yuichiro Hanada <yhanada@chromium.org> Reviewed-by: Mitsuru Oshima <oshima@chromium.org> Cr-Commit-Position: refs/heads/master@{#807764}

view details

push time in a month

delete branch rakuco/wake-lock

delete branch : explainer-wip

delete time in a month

pull request commentw3c/screen-wake-lock

Add an Explainer document to the repository.

I've pushed a second commit incorporating some of Marcos' feedback. I've also reworded the kiosk item in "Why?", and added more context to what the System Wake Lock API did.

  • Why
    • Stop mentioning "apps", reword the kiosk entry to make the use case more explicit.
  • Non-goals
    • Briefly describe what the system wake lock API did.
  • API
    • Do not say the API surface is not big.
    • Rework the example code.
    • Drop "Wake Lock" subsection, just mention how a lock is requested.
    • Stop referring to WakeLockSentinel.release() as if it were a static method.
  • Security considerations
    • Also do not refer to WakeLockSentinel.release() as a static method.
    • Be more clear about how acquired locks are advisory-only.
    • Reword the item about battery consumption and battery depletion.
rakuco

comment created time in a month

Pull request review commentw3c/screen-wake-lock

Add an Explainer document to the repository.

+# Screen Wake Lock API++## Introduction+The **Screen Wake Lock API** allows web applications to prevent a device's+screen from dimming and locking.++See also:+* [The current specification](https://w3c.github.io/screen-wake-lock/)+* [web.dev article](https://web.dev/wakelock/) on the Screen Wake Lock API++## Why?+To avoid draining the battery, most devices quickly go to sleep when left idle.+While this is fine most of the time, some applications need to keep the screen+awake to complete their work. For example:++* A recipe app that keeps the screen on while you bake a cake or cook dinner.+* A boarding pass or ticket app that keeps the screen on until the barcode has+  been scanned.+* A kiosk-style app that keeps the screen on continuously.+* A web-based presentation app that keeps the screen on during a presentation.++Without this API, web developers have had to rely on libraries such as+[NoSleep.js](https://github.com/richtr/NoSleep.js), which essentially added a+[small+video](https://github.com/richtr/NoSleep.js/blob/eaf52afd1dfbb80145b4a39f3ec29307b80ab154/src/index.js#L37-L57)+to a page to keep the display on.++> Recent NoSleep.js releases have added support for the Screen Wake Lock API.++The purpose of this specification is to allow sites to be explicit about when+they want to acquire a wake lock so that browsers can provide better automated+and manual controls to prevent intentional and incidental issues.++## Non-goals+A previous iteration of this spec included both Screen and System wake locks.+The latter has been moved to a separate spec, and is out of scope for this+explainer.++## API+The API surface is not big: users can request a screen wake lock; if the+request succeeds it can be either manually released later or released+automatically by the platform due to OS-specific policies that might be in+place. The code looks like this:++```js+const lock = await navigator.wakeLock.request("screen");++lock.addEventListener("release", () => {+  console.log(`Has the lock been released? ${lock.released}`);+});+await lock.release();+```++### WakeLock+The `WakeLock` object is part of `Navigator`. It has a single method,+`request(type)`. The `type` argument is of the `WakeLockType` enum type, which+right now has a single value, _"screen"_.++`WakeLock.request()` performs permission checks, verifies that the document+issuing the request is visible and, if all checks succeed, asynchronously+requests a lock from the underlying platform to prevent the screen from turning+off.++A successful `WakeLock.request()` invication returns a promise that will+ultimately resolve with a `WakeLockSentinel` object.++### WakeLockSentinel+A `WakeLockSentinel` object provides a handle to the lock that has been+acquired.++`WakeLockSentinel` has two read-only attributes for introspection: `released`+indicates whether the lock has already been released, `type` returns the lock's+type (it is always _"screen"_ at the moment).++The `WakeLockSentinel.release()` method is used to release the platform wake+lock. It asynchronously emits a _"release"_ event that users can listen for in+order to know that the lock is no longer being held.++The lock might also be released automatically by the platform without+`WakeLockSentinel.release()` being called (for example, when the page is no+longer visible). The _"release_" event is still emitted the same way.++## Security considerations+* To avoid possible user fingerprinting issues, `WakeLock.request()` does not+  indicate to API users whether the actual call to obtain a lock from the+  operating system has succeeded or not. In other words, successful+  `WakeLock.request()` calls must be treated by users as **advisory-only**.++* Screen Wake Locks can only be acquired and held if the document is visible.+  If `WakeLock.request()` is called while the document is hidden, the request+  will be denied with a `NotAllowedError`. If the page is hidden after a lock+  has been acquired, it will be released automatically.++* Application of a wake lock causes various device components such as display+  or CPU to operate at higher power levels than they otherwise would. This can+  lead to undesirable and potentially dangerous effects such as excessive+  heating and faster than normal battery charge depletion. The latter is+  particularly relevant to mobile devices which may not have a stationary power

Heh this was copied verbatim from the Security and privacy considerations section in the spec. I've sent #287 to reword it there too.

rakuco

comment created time in a month

PullRequestReviewEvent

PR opened w3c/screen-wake-lock

editorial: Reword the Security and Privacy Considerations section.

Incorporate feedback from #286, where @marcosc proposed a few changes to the part of the paragraph that had been copied from the spec:

I think say "and potentially dangerous" is going a bit overboard, tbh. Browsers are just tapping into publicly available OS APIs to provide this functionality (not arbitrary hacks that could cause a screen or device to catch on fire) - and those are hardly dangerous.

+10 -11

0 comment

1 changed file

pr created time in a month

Pull request review commentw3c/screen-wake-lock

Add an Explainer document to the repository.

+# Screen Wake Lock API++## Introduction+The **Screen Wake Lock API** allows web applications to prevent a device's+screen from dimming and locking.++See also:+* [The current specification](https://w3c.github.io/screen-wake-lock/)+* [web.dev article](https://web.dev/wakelock/) on the Screen Wake Lock API++## Why?+To avoid draining the battery, most devices quickly go to sleep when left idle.+While this is fine most of the time, some applications need to keep the screen+awake to complete their work. For example:++* A recipe app that keeps the screen on while you bake a cake or cook dinner.+* A boarding pass or ticket app that keeps the screen on until the barcode has+  been scanned.+* A kiosk-style app that keeps the screen on continuously.+* A web-based presentation app that keeps the screen on during a presentation.++Without this API, web developers have had to rely on libraries such as+[NoSleep.js](https://github.com/richtr/NoSleep.js), which essentially added a+[small+video](https://github.com/richtr/NoSleep.js/blob/eaf52afd1dfbb80145b4a39f3ec29307b80ab154/src/index.js#L37-L57)+to a page to keep the display on.++> Recent NoSleep.js releases have added support for the Screen Wake Lock API.++The purpose of this specification is to allow sites to be explicit about when+they want to acquire a wake lock so that browsers can provide better automated+and manual controls to prevent intentional and incidental issues.++## Non-goals+A previous iteration of this spec included both Screen and System wake locks.+The latter has been moved to a separate spec, and is out of scope for this+explainer.++## API+The API surface is not big: users can request a screen wake lock; if the+request succeeds it can be either manually released later or released+automatically by the platform due to OS-specific policies that might be in+place. The code looks like this:++```js+const lock = await navigator.wakeLock.request("screen");++lock.addEventListener("release", () => {+  console.log(`Has the lock been released? ${lock.released}`);+});+await lock.release();+```++### WakeLock+The `WakeLock` object is part of `Navigator`. It has a single method,+`request(type)`. The `type` argument is of the `WakeLockType` enum type, which+right now has a single value, _"screen"_.++`WakeLock.request()` performs permission checks, verifies that the document+issuing the request is visible and, if all checks succeed, asynchronously+requests a lock from the underlying platform to prevent the screen from turning+off.++A successful `WakeLock.request()` invication returns a promise that will+ultimately resolve with a `WakeLockSentinel` object.++### WakeLockSentinel+A `WakeLockSentinel` object provides a handle to the lock that has been+acquired.++`WakeLockSentinel` has two read-only attributes for introspection: `released`+indicates whether the lock has already been released, `type` returns the lock's+type (it is always _"screen"_ at the moment).++The `WakeLockSentinel.release()` method is used to release the platform wake+lock. It asynchronously emits a _"release"_ event that users can listen for in+order to know that the lock is no longer being held.++The lock might also be released automatically by the platform without+`WakeLockSentinel.release()` being called (for example, when the page is no+longer visible). The _"release_" event is still emitted the same way.++## Security considerations+* To avoid possible user fingerprinting issues, `WakeLock.request()` does not+  indicate to API users whether the actual call to obtain a lock from the+  operating system has succeeded or not. In other words, successful+  `WakeLock.request()` calls must be treated by users as **advisory-only**.

Done.

rakuco

comment created time in a month

PullRequestReviewEvent
more