[blink-dev] Re: Intent to Prototype and Ship: Compute Pressure WebDriver endpoints

Done! Mike Taylor writes: > Could you please request reviews for the various review gate bits in > your chromestatus entry? > > > (privacy, security, enterprise... etc) > > > On 6/19/24 3:54 AM, Mandy, Arnaud wrote: >> Contact emails >> raphael.kubo.da.co...@intel.com >>

[blink-dev] Re: Intent to Prototype and Ship: Compute Pressure WebDriver endpoints

Complementing what Alex has said, seeking review from the WebDriver WG is not strictly necessary, and since these endpoints are modelled after the Generic Sensor and Device Posture ones it felt like there was no need to involve the WG before starting this Intent thread. As for BiDi support, Alex

[blink-dev] Re: Intent to Ship: Compute Pressure

Op 17-05-2024 om 16:59 schreef Philip Jägenstedt: What will be the behavior on Android, will the API appear to work but never invoke the observer callback? If so, would it make sense to disable the feature on Android instead? I'd just like to check if there's a general guideline for cases

[blink-dev] Re: Intent to Ship: Compute Pressure

Philip Jägenstedt writes: > Taking a closer look, I think it's really because the tests depend on > MojoJS, and if we exclude tentative tests > > only > surface level tests remain. > > Compute Pressure tests

[blink-dev] Re: Intent to Ship: Compute Pressure

Philip Jägenstedt writes: > Taking a look at https://wpt.fyi/results/compute-pressure I see that most > of the tests are tentative. Should they still be, or why doesn't the spec > cover so much of the behavior? As someone who reviewed most of the test: I think "tentative" should be removed from

[blink-dev] Intent to Ship: Implement requestPermission() for DeviceOrientationEvent and DeviceMotionEvent

Contact emails raphael.kubo.da.co...@intel.com,reil...@chromium.org Explainer None Specification https://w3c.github.io/deviceorientation Summary Allows developers to ask for permission to use the Device Orientation and Device Motion APIs. Access to these

Re: [blink-dev] Intent to Prototype and Ship: Generic Sensor WebDriver endpoints

Thanks, Mathias. Mathias Bynens writes: > Question 1: Are they supportive of the Generic Sensor API? Officially, no. It has been quite a while since we last asked them though. See the discussion with Mozilla here: - https://github.com/mozilla/standards-positions/issues/35 and their

Re: [blink-dev] Re: PSA: WebDriver changes now go through the API owners intent process

Op 08-06-2023 om 05:41 schreef Mathias Bynens: In ChromeDriver, we don’t have feature flags per se. Instead the mechanism we have available is vendor-prefixed command mappings

[blink-dev] Re: PSA: WebDriver changes now go through the API owners intent process

Op 31-05-2023 om 20:44 schreef Chris Harrelson: TL;DR: going forward, new WebDriver Classic and WebDriver BiDi APIs in Chromium need to go through the Intent process, including in particular Intent to Prototype and Intent to Ship. See here

Re: [blink-dev] Intent to Prototype: Implement requestPermission() for DeviceOrientationEvent and DeviceMotionEvent

to window.ondevice{motion,orientation} in the future? Joe Medley | Technical Writer, Chrome DevRel |jmed...@google.com | 816-678-7195 /If an API's not documented it doesn't exist./ On Tue, Jun 21, 2022 at 1:57 PM Raphael Kubo da Costa wrote: Correct. The larger plan is to: - Require

Re: [blink-dev] Intent to Prototype: Implement requestPermission() for DeviceOrientationEvent and DeviceMotionEvent

this means you're going to deprecate default access to window.ondevice{motion,orientation} at some point? Joe Medley | Technical Writer, Chrome DevRel |jmed...@google.com | 816-678-7195 /If an API's not documented it doesn't exist./ On Mon, Jun 20, 2022 at 6:15 AM Raphael Kubo da Cos

[blink-dev] Intent to Prototype: Implement requestPermission() for DeviceOrientationEvent and DeviceMotionEvent

Contact emails raphael.kubo.da.co...@intel.com,eng...@chromium.org,reil...@chromium.org Explainer None Specification https://w3c.github.io/deviceorientation Summary Allows developers to ask for permission to start using the Device Orientation and Device

Re: [blink-dev] Intent to Deprecate and Remove: Battery Status API in Insecure Origins

controlled by an on-by-default flag (due to the low risk). Mike - are you OK with the second point? On Thu, Apr 28, 2022 at 4:18 PM Raphael Kubo da Costa wrote: Back when I sent the original Intent to Deprecate and Remove email, I checked the samples from the previous quarter

Re: [blink-dev] Intent to Deprecate and Remove: Battery Status API in Insecure Origins

to have such access trigger a warning. On Thu, Apr 28, 2022 at 12:04 PM Raphael Kubo da Costa wrote: I tend to agree with Mike here; none of the users of navigator.getBattery() in insecure contexts I checked in the past (via chromestatus.com <http://chromestatus.com>) would

Re: [blink-dev] Intent to Deprecate and Remove: Battery Status API in Insecure Origins

a feature flag disabled by default, and then work with someone at Google to enable it on the server side for a release, before enabling it in code. That way it'd be easy to revert this in case this unexpectedly breaks things. On Mon, Apr 25, 2022 at 5:00 PM Raphael Kubo da Costa

Re: [blink-dev] Intent to Deprecate and Remove: Battery Status API in Insecure Origins

got on this thread should be enough. Please make sure to monitor any issues related to this, and revert if needed. (while keeping the feature flag around to enable urgent re-activation of this if breakage turns out to be untenable) On Thu, Apr 21, 2022 at 3:00 PM Raphael Kubo da Costa wrote

Re: [blink-dev] Intent to Deprecate and Remove: Battery Status API in Insecure Origins

taking over https://chromium-review.googlesource.com/c/chromium/src/+/2206655 for this deprecation, or is there a new line of work underway? On Thu, Apr 21, 2022 at 9:00 AM Raphael Kubo da Costa wrote: Hi everyone, M103 is here, so I'd like to double-check if I can go ahead and stop

Re: [blink-dev] Intent to Deprecate and Remove: Battery Status API in Insecure Origins

but most of it comes from embedded https YouTube videos, trackers and RUM (real user monitoring) code in https pages. Do I start another thread and get new LGTMs for the actual removal? On 13-01-2022 16:09, Raphael Kubo Da Costa wrote: *Contact emails *raphael.kubo.da.co...@intel.com

[blink-dev] How to check if a document is fully active in Blink?

Hi Blinkers, https://html.spec.whatwg.org/multipage/browsers.html#fully-active specifies what a fully active document is, and several specs check whether a document is fully active in their algorithms. WebKit has Document::isFullyActive(), which essentially implements HTML's definition:

[blink-dev] Re: Intent to Ship: Remove Battery Status API on Insecure Origins

Thanks everyone for the LGTMs. Due to an oversight I ended up landing the CL that adds a deprecation warning before M99 branched, so compared to what I originally wrote the deprecation has started in M99 instead of M100. The

[blink-dev] Intent to Deprecate and Remove: Battery Status API in Insecure Origins

*Contact emails *raphael.kubo.da.co...@intel.com, reil...@chromium.org *Explainer* None *Specification *https://w3c.github.io/battery *Summary *Deprecate and remove the Battery Status API on insecure origins, such as HTTP pages or HTTPS iframes embedded in HTTP pages. *Blink component