Re: [blink-dev] Re: Intent to Prototype and Ship: Control character handling in cookies

[Andrew Williams]

Hi Daniel,

Thanks for following up on this. UMA metrics to count the prevalence of
\x00, \x0d, and \x0a characters in cookie strings will roll out with the
M96 release.  We'll post back here once those metrics are available.

Regarding deprecation warnings, we've mapped out how to generate DevTools
Issues that would warn developers when cookies containing these characters
are detected, but we haven't implemented anything yet.  Also, we haven't
implemented the sending of deprecation reports yet. Both are still on our
radar, though.

-Andrew

On Thu, Nov 4, 2021 at 2:37 PM Daniel Bratell  wrote:

> The last thing happening in this thread was that we decided to wait for
> data. What is the current status of those usecounters, have they reached
> the user base now?
>
> /Daniel
> On 2021-09-20 07:59, Yoav Weiss wrote:
>
>
>
> On Fri, Sep 17, 2021 at 6:36 PM Steven Bingler 
> wrote:
>
>> Hi Ian and Yoav,
>>
>> I believe the general guidance now for warning users of some change is to
>> use DevTools Issues rather than console warnings. Would using Issues,
>> instead of console warnings, be acceptable to you? (This would be in
>> addition to the reports.)
>>
>
> I don't believe the API OWNERS have a stand on console warnings vs. issues
> for deprecations. Whatever is the general guidance that will make this
> visible for developers seems good to me, assuming that issues are prominent
> in the UI and manage to grab the median developer's attention.
>
>
>> Also, for posterity, it is possible to emit a console warning starting
>> from EmitCookieWarningsAndMetrics() with a little work. We used to do just
>> that for SameSite warnings before we transitioned them to DevTools Issue [
>> 1
>> ]
>> [2
>> ]
>> (many refactors ago). It looks like most of the necessary functions still
>> exist, so it shouldn't be too hard to recreate that functionality if
>> needed.
>>
>
>> Thanks,
>> Steven
>>
>> On Friday, September 17, 2021 at 8:45:10 AM UTC-7 Andrew Williams wrote:
>>
>>> Thanks for the feedback Mike, Yoav, and Ian.  I will explore the
>>> feasibility of using CountDeprecation (or something similar) from the
>>> cookie-related code and will report back once I have an update on this.
>>>
>>> -Andrew
>>>
>>> On Fri, Sep 10, 2021 at 10:11 AM Ian Clelland 
>>> wrote:
>>>
 That looks right -- that code path won't get you anywhere near adding a
 console message, as far as I can tell, but you would be able to queue a
 report that way. Ideally, we'd have something like deprecation.cc for
 browser-side that would handle the UMA as well as formatting the report
 body consistently. As a first pass, until we have more that one
 browser-generated deprecation report, just generating and queuing it would
 work.

 On Fri, Sep 10, 2021 at 6:42 AM Yoav Weiss 
 wrote:

> I may very well be wrong, but it seems like
> CookieUtils::EmitCookieWarningsAndMetrics
> 
>  has
> the right plumbing to reach RenderFrameHost, and from it, get a
> ReportingSource
> 
>  that
> can enable us to send
> 
> deprecation reports (even if through a different mechanism than
> CountDeprecation).
>
> Ian - thoughts on the above?
>
> On Thu, Sep 9, 2021 at 9:21 PM Mike West  wrote:
>
>> I don't think `countDeprecation` is going to work here, insofar as
>> that's a Blink-layer concept, and the network stack isn't going to have 
>> an
>> understanding of page views or use counters or etc. If we've wired things
>> up such that deprecation reports can be triggered from the network stack,
>> lovely, but I'm not sure that's the case.
>>
>> Another approach that might be reasonable to approach might be to
>> roll this out on a percentage-basis, starting with a substantial portion 
>> of
>> beta, then rolling to stable iff we're confident in that experience?
>>
>> This feels like both the right directional and philosophical thing to
>> do with cookies. I'd like to see it ship, and a staged rollout might well
>> be a reasonable 

Re: [blink-dev] Questions about WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS

[Kentaro Hara]

+1 to migrate to the gfx types without the macro. Thanks for confirming the
performance numbers!



On Fri, Nov 5, 2021 at 10:23 AM Xianzhu Wang 
wrote:

> On Thu, Nov 4, 2021 at 11:38 AM Xianzhu Wang 
> wrote:
>
>> Actually we have only two remaining usages of such macros in blink
>> geometry types:
>> 1. float_size.h
>> 
>> :
>>   // Allows this class to be stored in a HeapVector.
>>   WTF_ALLOW_CLEAR_UNUSED_SLOTS_WITH_MEM_FUNCTIONS(blink::FloatSize)
>>   This seems unnecessary because FloatSize is not a garbage collected
>> type, and we don't have any usage of Vector in blink.
>> 2. int_rect.h
>> 
>> :
>>   WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS(blink::IntRect)
>>   We have a lot of Vector usages. Will try perf tests.
>>
>
> Perf tests didn't show an obvious difference with
> WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS(blink::IntRect) removed.
> The results actually show progressions of total rendering CPU usage, but
> they are likely to be just noise. See the pinpoint results in
> https://chromium-review.googlesource.com/c/chromium/src/+/3262556 for
> details.
>
> So I'm going forward to migrate blink geometry types to gfx types without
> worrying about WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS on
> geometry types.
>
> About std::is_trivial, actually we don't allow particular trivial types to
>> use such macros. For example, in
>> WTF_ALLOW_MOVE_AND_INIT_WITH_MEM_FUNCTIONS, we have:
>>static_assert(!std::is_trivially_default_constructible::value
>> || \
>> !std::is_trivially_move_assignable::value, \
>> "macro not needed"); \
>>
>> Also most of our classes (including all geometry classes) are not
>> trivially default constructible because they do need initialization. We
>> could check if a default constructed object is all zero to see if it can be
>> initialized by memset, but I'm not sure if this is possible at compile time.
>>
>> It seems that we can check std::is_trivially_copyable and/or
>> std::is_trivially_move_assignable for kCan*WithMemcpy
>> and kCanCompareWithMemcmp.
>>
>
> Actually we are already doing this
> 
> :)
>
>
>>
>> On Thu, Nov 4, 2021 at 10:39 AM Xianzhu Wang 
>> wrote:
>>
>>> One data point: the CL
>>> 
>>> that replaces blink::IntPoint (declared with the macro) with gfx::Point was
>>> landed 2 days ago, and I haven't received any performance bug yet. Perhaps
>>> we don't use Vector in performance critical code.
>>>
>>> Will try std::is_trivial before converting other types.
>>>
>>> On Thu, Nov 4, 2021 at 10:19 AM Daniel Bratell 
>>> wrote:
>>>
 (see inline)
 On 2021-11-03 12:15, Kentaro Hara wrote:

 The VectorTraits::kCan{Copy,Move,Fill,Compare}... fields are used
> for all Vectors though, no? This particular macro doesn't appear to
> explicitly define/override any Oilpan-related fields AFAICS.


 You're right -- thanks for pointing it out :)

 a) The macros work as a performance optimization for all Vectors. I
 have no data about the performance numbers though.

 The traits have a big effect on micro-benchmarks but it's always hard
 to map that to user observable performance.

 Furthermore, is it possible to replace the macros with use of standard
 C++ traits such as std::is_trivial
 ? It would
 require auditing current types, and possibly modifying them, but that is
 something that has to be done anyway before a complete type merge between
 Blink and

 /Daniel


 b) Some of the macros are mandatory to make HeapVector work
 correctly (e.g., see static_assert here
 
 ).

 b) does not apply to the geometry types in question. Regarding a),
 maybe can we just measure performance using benchmarks and see if dropping
 the macros causes performance regressions? (I hope not.)


 On Wed, Nov 3, 2021 at 7:19 PM Fredrik Söderquist  wrote:

> On Wed, Nov 3, 2021 at 12:29 AM Kentaro Hara 
> wrote:
>
>> The macro matters only for objects stored in HeapVector (i.e.
>> Oilpan). So you don't need to export the macro outside Blink :)

Re: [blink-dev] Questions about WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS

[Xianzhu Wang]

On Thu, Nov 4, 2021 at 11:38 AM Xianzhu Wang 
wrote:

> Actually we have only two remaining usages of such macros in blink
> geometry types:
> 1. float_size.h
> 
> :
>   // Allows this class to be stored in a HeapVector.
>   WTF_ALLOW_CLEAR_UNUSED_SLOTS_WITH_MEM_FUNCTIONS(blink::FloatSize)
>   This seems unnecessary because FloatSize is not a garbage collected
> type, and we don't have any usage of Vector in blink.
> 2. int_rect.h
> 
> :
>   WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS(blink::IntRect)
>   We have a lot of Vector usages. Will try perf tests.
>

Perf tests didn't show an obvious difference with
WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS(blink::IntRect) removed.
The results actually show progressions of total rendering CPU usage, but
they are likely to be just noise. See the pinpoint results in
https://chromium-review.googlesource.com/c/chromium/src/+/3262556 for
details.

So I'm going forward to migrate blink geometry types to gfx types without
worrying about WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS on
geometry types.

About std::is_trivial, actually we don't allow particular trivial types to
> use such macros. For example, in
> WTF_ALLOW_MOVE_AND_INIT_WITH_MEM_FUNCTIONS, we have:
>static_assert(!std::is_trivially_default_constructible::value
> || \
> !std::is_trivially_move_assignable::value, \
> "macro not needed"); \
>
> Also most of our classes (including all geometry classes) are not
> trivially default constructible because they do need initialization. We
> could check if a default constructed object is all zero to see if it can be
> initialized by memset, but I'm not sure if this is possible at compile time.
>
> It seems that we can check std::is_trivially_copyable and/or
> std::is_trivially_move_assignable for kCan*WithMemcpy
> and kCanCompareWithMemcmp.
>

Actually we are already doing this

:)


>
> On Thu, Nov 4, 2021 at 10:39 AM Xianzhu Wang 
> wrote:
>
>> One data point: the CL
>>  that
>> replaces blink::IntPoint (declared with the macro) with gfx::Point was
>> landed 2 days ago, and I haven't received any performance bug yet. Perhaps
>> we don't use Vector in performance critical code.
>>
>> Will try std::is_trivial before converting other types.
>>
>> On Thu, Nov 4, 2021 at 10:19 AM Daniel Bratell 
>> wrote:
>>
>>> (see inline)
>>> On 2021-11-03 12:15, Kentaro Hara wrote:
>>>
>>> The VectorTraits::kCan{Copy,Move,Fill,Compare}... fields are used for
 all Vectors though, no? This particular macro doesn't appear to
 explicitly define/override any Oilpan-related fields AFAICS.
>>>
>>>
>>> You're right -- thanks for pointing it out :)
>>>
>>> a) The macros work as a performance optimization for all Vectors. I
>>> have no data about the performance numbers though.
>>>
>>> The traits have a big effect on micro-benchmarks but it's always hard to
>>> map that to user observable performance.
>>>
>>> Furthermore, is it possible to replace the macros with use of standard
>>> C++ traits such as std::is_trivial
>>> ? It would
>>> require auditing current types, and possibly modifying them, but that is
>>> something that has to be done anyway before a complete type merge between
>>> Blink and
>>>
>>> /Daniel
>>>
>>>
>>> b) Some of the macros are mandatory to make HeapVector work correctly
>>> (e.g., see static_assert here
>>> 
>>> ).
>>>
>>> b) does not apply to the geometry types in question. Regarding a), maybe
>>> can we just measure performance using benchmarks and see if dropping the
>>> macros causes performance regressions? (I hope not.)
>>>
>>>
>>> On Wed, Nov 3, 2021 at 7:19 PM Fredrik Söderquist  wrote:
>>>
 On Wed, Nov 3, 2021 at 12:29 AM Kentaro Hara 
 wrote:

> The macro matters only for objects stored in HeapVector (i.e.
> Oilpan). So you don't need to export the macro outside Blink :)
>

 The VectorTraits::kCan{Copy,Move,Fill,Compare}... fields are used
 for all Vectors though, no? This particular macro doesn't appear to
 explicitly define/override any Oilpan-related fields AFAICS.


 /fs


>
>
> 2021年11月3日(水) 

Re: [blink-dev] Request for Deprecation Trial: Remove alert(), confirm(), and prompt for cross origin iframes

[Carlos IL]

Thanks everyone for the feedback so far. After talking to developers and
considering the options, we have decided to postpone the launch of this
deprecation while we investigate adding a feature policy, which may take
some time. We will provide several months of advance notice in the future
when we decide to re-enable it, and the enterprise policy and origin trial
opt-outs will be available at that point.

In the meantime, if you want to test Chrome with the behavior enabled, you
can do so by running with the
‘enable_features=SuppressDifferentOriginSubframeJSDialogs’
command line flag.

On Tue, Oct 12, 2021 at 2:44 AM Lewis Chan  wrote:

> Does it mean that if I signup for the Origin Trials, I have until July
> 2022 to resolve this?
>
> On Tuesday, 28 September 2021 at 06:35:07 UTC+8 carl...@chromium.org
> wrote:
>
>> This change remains disabled, and will be re-enabled at the earliest in
>> January 2022. When this is re-enabled, the enterprise policy and origin
>> trial opt outs will remain available for at least 6 months.
>>
>> -Carlos
>>
>> On Thu, Sep 23, 2021 at 9:44 PM Emmanuel Law  wrote:
>>
>>> What is the latest status of this? Ideally we would like more
>>> information on when this deprecation will take place so that we can
>>> strategize on a longer term solution vs a short term solution depending on
>>> the date.
>>>
>>> On Friday, August 20, 2021 at 12:16:59 PM UTC-7 carl...@chromium.org
>>> wrote:
>>>
 Re: Stilll seeing the breakage, this was indeed disabled via Chrome
 Variations, so if something is interfering with variations (like an
 enterprise policy), that could be the reason you still see this. This was
 also disabled in code starting in 92.0.4515.146.

 Re: A message in DevTools, we are planning to add a note in DevTools
 about this API being deprecated.

 Re: Testing while this is disabled by default, you can do so by running
 chrome with
 the --enable-features="SuppressDifferentOriginSubframeJSDialogs" command
 line flag

 -Carlos

 On Fri, Aug 20, 2021 at 12:11 AM Pritpal Singh <
 psi...@watermarkinsights.com> wrote:

> How can we re-enable this deprecation on latest version of chrome, we
> need it to test the alternatives. Please guide.
>
> On Friday, August 20, 2021 at 12:05:24 PM UTC+5:30 Yang Guo wrote:
>
>> Is there plans for a soft deprecation through DevTools?
>>
>> Instead of removing right away,  you could raise issues in DevTools
>> when these APIs are used to warn developers of upcoming deprecation.
>>
>> On Thursday, August 19, 2021 at 8:36:16 PM UTC+2
>> wande...@chromium.org wrote:
>>
>>> Is the tested chrome browser managed using enterprise policies?
>>> It's possible an enterprise policy could be interfering with the finch 
>>> fill
>>> switch.
>>>
>>> On Thu, Aug 19, 2021 at 2:31 PM Daniel Bratell 
>>> wrote:
>>>
 I'm not in that engineering team but as far as I understand, the
 change was done through the Finch system, which is settings your Chrome
 client will regularly download from Google server. That might not 
 happen
 immediately which could possibly explain what you see. But maybe the 
 team
 can follow up with more information.

 /Daniel
 On 2021-08-19 16:33, Pierce McGeough wrote:

 What is the current state of play with this?

 I thought *92.0.4515.157* was the most version of Chrome where the
 issue was reverted. I downloaded *92.0.4515.107 *with it looking
 like it was the most recent version to still have the blocker in place.
 I also have 91.0.4472.144 on another machine.

 I tested no attribute, "sandbox", "sandbox='allow-scripts'" and
 "sandbox='allow-scripts allow-modals''. I tested against running a 
 script,
 alert, confirm, print and prompt. All versions gave the same results.

 On Thursday, August 5, 2021 at 11:02:46 AM UTC+1 Daniel Bratell
 wrote:

> Technically those are two different domains, even though they are
> likely controlled by the same party. There are ways to "join" 
> different
> domains (like setting the document.domain
> 
> property), or identify which second level domains have only one
> controller  and
> which has more, but they are unreliable and are being phased out
> .
>
> You are right that this is a common setup in enterprises and that
> has to be considered when discussing how possibly malicious 
> cross-origin
> alerts and prompts can be prevented.
>
> /Daniel
> 

Re: [blink-dev] Intent to Ship: New Canvas 2D API

['Thomas Steiner' via blink-dev]

On Thu, Nov 4, 2021 at 10:12 PM Fernando Serboncini 
wrote:

> We are launching with a console warning. Will check on the PR if it makes
> sense to add a note about it on the spec.
>

Perfect, thank you very much!

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrLkF4-1WQrsNUYaEDMWJCfGsnk9JJNR6ENfsrmwt1uLgDQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: New Canvas 2D API

[Fernando Serboncini]

We are launching with a console warning. Will check on the PR if it makes
sense to add a note about it on the spec.

On Thu, Nov 4, 2021 at 3:08 PM Thomas Steiner  wrote:

> On Thu 4. Nov 2021 at 20:01 'Aaron Krajeski' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> During a WHATWG spec meeting this morning we agreed to not throw for
>> malformed canvas filters. There are still a few editorial changes to go
>> through on that PR, but other than that everything is settled for this
>> launch.
>
>
> What about the console warnings? Or is this not a spec-level decision, but
> an implementation detail?
>
> On Friday, October 29, 2021 at 1:53:20 PM UTC-4 dom...@chromium.org wrote:
>>
>>> The usual definition of "breaking change" that we use when shipping
>>> features is not "if web developers always do valid things, then the change
>>> we are making avoids breakages". We can't rely on web developers to write
>>> valid code all the time... see e.g. stats about what percent of the web is
>>> valid HTML.
>>>
>>> For example, while people might not write "asdf", they might write
>>> "colourMatrix" (spot the typo), or similar.
>>>
>>> On Fri, Oct 29, 2021 at 1:50 PM Fernando Serboncini 
>>> wrote:
>>>
 yes, of course if you pass "asdf" one would throw and the other
 wouldn't. There will be a potential behavior difference.

 My point is nobody would write "asdf" as a filter, because "asdf" is
 not a spec'ed or implemented filter anywhere. There are no possible
 mismatches at this point. If CanvasFilter exists, the set of filters is
 well defined everywhere.

 On Fri, Oct 29, 2021 at 1:45 PM Domenic Denicola 
 wrote:

> I don't think that's true. If someone passes "asdf" to the
> CanvasFilter constructor, changing from not-throwing to throwing would be 
> a
> breaking change. We'd need to add use counters, etc. to find out if anyone
> is passing such invalid values.
>
> Whereas, if we start off with throwing, we can always remove the
> throwing behavior later, with no use counters required.
>
> On Fri, Oct 29, 2021 at 1:43 PM Fernando Serboncini <
> fs...@chromium.org> wrote:
>
>> Since the current implementation is not throwing, we could reasonably
>> launch as-is and the add throwing if it is agreed to do so after.
>> The added risk is the exact same risk that we are arguing to begin
>> with (i.e., code that uses not-implemented filters without try/catch 
>> would
>> break). But since there are no "not-implemented filters" yet, it may not 
>> be
>> a problem.
>>
>> On Fri, Oct 29, 2021 at 1:34 PM Domenic Denicola 
>> wrote:
>>
>>> Yep. Reasonable people can disagree on the tradeoffs here. The
>>> question is whether this is something we want to deadlock over with 
>>> other
>>> implementers.
>>>
>>> On Fri, Oct 29, 2021 at 12:28 PM Mike Taylor 
>>> wrote:
>>>
 On 10/29/21 1:23 AM, Yoav Weiss wrote:

 Hey Domenic! :)

 On Thu, Oct 28, 2021 at 11:00 PM Domenic Denicola <
 dom...@chromium.org> wrote:

>
> FWIW the two HTML editors on the thread (myself and Anne, with our
> HTML editor hats on), as well as Mozilla (via Anne with his Mozilla 
> hat
> on), prefer the throwing behavior. I think in most cases to overcome 
> that
> position we would need some really strong reasons why the Chromium 
> project
> believes the non-throwing behavior is better. It's not clear to me how
> strong Chromium's position is on this issue, and whether it's worth
> delaying the feature over. (Or indeed, delaying all the features, 
> since the
> plan seems to be to bundle them together?)
>

 My concerns with the throwing behavior are similar to the ones we
 have discussed
 
 in the context of MediaSession actions.
 If we go with the throwing behavior, every future addition of
 filters would have a significant interop risk, in case adopting 
 developers
 won't use try/catch properly. If they do that and they are not testing 
 in
 not-yet-supporting browsers, their apps are likely to break entirely in
 those browsers.
 If we go with a silent failure + feature detection approach,
 developers using the feature without properly detecting it may not 
 have the
 desired visual effects they are going for, but won't have unrelated 
 parts
 of their app break.

 From my perspective (with my API owner hat on), less risk is
 better, and the second approach seems less risky to me.

 I agree with Yoav here (sorry, I don't own any hats). Not throwing
 will 

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: forced-color-adjust: preserve-parent-color

[Chris Harrelson]

On Fri, Oct 29, 2021 at 1:13 PM Fernando Serboncini 
wrote:

>
> Great. It makes sense.
>
> thank you :)
>
> On Fri, Oct 29, 2021 at 4:11 PM Sara Tang  wrote:
>
>> Hi Fernando,
>>
>> This I2S does #3.
>>
>> Thanks!
>> Sara
>> --
>> *From:* Fernando Serboncini 
>> *Sent:* Friday, October 29, 2021 8:21 AM
>> *To:* Sara Tang 
>> *Cc:* blink-dev@chromium.org ; Alison Maher <
>> alison.ma...@microsoft.com>; Daniel Libby 
>> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Ship:
>> forced-color-adjust: preserve-parent-color
>>
>> Could you clarify if this I2S:
>> 1. just adds the 'preserve-parent-color' value to forced-color-adjust and
>> doesn't apply it anywhere by default.
>> 2. adds it and changes the default value of forced-color-adjust to be
>> "preserve-parent-color" on all SVG elements
>> 3. adds it and changes the default value of forced-color-adjust to be "
>> preserve-parent-color" only on the SVG root element (that then gets
>> propagated down)
>>
>> it seems that #3 was decided
>> 
>> on the CSSWG
>> ,
>> but your summary and crbug's CL looks more like #1, while your
>> motivation seems like #2.
>>
>>
>> On Thu, Oct 28, 2021 at 5:45 PM 'Sara Tang' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>> Contact emails sart...@microsoft.com, alison.ma...@microsoft.com
>>
>> Explainer
>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md
>> 
>>
>> Specification
>> https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop
>> 
>>
>> Summary
>>
>> Adds the ‘preserve-parent-color' value to the ‘forced-color-adjust' CSS
>> property. When Forced Colors Mode is enabled, the ‘color’ property is
>> inherited, and we’ve set ‘forced-color-adjust: preserve-parent-color', the
>> ‘color’ property will compute to the used value of its parent. Otherwise,
>> ‘forced-color-adjust: preserve-parent-color' value behaves the same as
>> ‘forced-color-adjust: none’.
>>
>> Contact emails sart...@microsoft.com, alison.ma...@microsoft.com
>>
>> Explainer
>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md
>> 
>>
>> Specification
>> https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop
>> 
>>
>> Summary
>>
>> Adds the ‘preserve-parent-color' value to the ‘forced-color-adjust' CSS
>> property. 

Re: [blink-dev] Intent to Ship: CORS non-wildcard request-header

['Chris Harrelson' via blink-dev]

Would it be feasible to get a random list of 10-20 sites that hit the use
counter and see if they are broken badly by this feature?

On Thu, Nov 4, 2021 at 4:54 AM Yutaka Hirano  wrote:

> (friendly ping)
>
> On Mon, Nov 1, 2021 at 1:57 PM Yutaka Hirano  wrote:
>
>> Thank you for the feedback.
>>
>> Do you have concrete steps for the investigation in your mind?
>>
>> On Fri, Oct 29, 2021 at 4:30 AM Mike West  wrote:
>>
>>> I think it's reasonable for us to dig into the data a little bit to
>>> determine whether the 0.04% number quoted above will result in user-facing
>>> breakage. Yutaka, is that something you'd be willing to dig into?
>>>
>>> The direction seems philosophically correct to me, so I'd like to see it
>>> ship, but I'd also like to make sure we're not making the web worse for
>>> users by doing so.
>>>
>>> -mike
>>>
>>>
>>> On Thu, Oct 21, 2021 at 12:04 PM Yutaka Hirano 
>>> wrote:
>>>


 On Thu, Oct 21, 2021 at 6:25 PM Yoav Weiss 
 wrote:

>
>
> On Thu, Oct 21, 2021 at 9:55 AM Yutaka Hirano 
> wrote:
>
>> (The implementation CL
>> 
>> is under review. This intent is written as if it's landed.)
>>
>> Contact emailsyhir...@chromium.org
>>
>> Specification
>> https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name
>>
>> Summary
>>
>> A CORS non-wildcard request header[1] is an HTTP request header which
>> is not covered by the wildcard symbol ("*") in the
>> access-control-allow-headers header. "authorization" is the only member 
>> of
>> CORS non-wildcard request-header. Currently we treat the header as a 
>> usual
>> header, which is problematic for security reasons. Implement it, and 
>> change
>> the current behavior. 1:
>> https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name
>>
>>
>> Blink componentBlink>SecurityFeature>CORS
>> 
>>
>> TAG reviewNot needed because this implements an existing feature.
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Interoperability risk is low because Mozilla and Apple showed an
>> intent to implement this behavior. There is some compatibility risk, as 
>> the
>> use counter[2] shows 0.04% websites would be affected. To mitigate the
>> risk, we've shown a deprecation message for a few milestones.
>>
>
> Can you similarly send deprecation reports as well? How long have the
> deprecation messages been in place? Did we see any decline in the numbers?
>
> We've shown the deprecation message since Chrome 94
 
  whose
 beta promotion was on Aug 26 and stable release was on Sep 21.
 We use CountDeprecation which sends deprecation reports automatically
 IIUC.

 I don't see any decline.


> Have we looked into which URLs are triggering this? (and if it's a few
> medium-sized properties or many tiny ones)
>

 I haven't looked at the data.

> Did we try outreach?
>
 No.

>
> We have an enterprise policy so that administrators can keep the
>> existing behavior. We're planning to remove the policy on Chrome 103. 2:
>> https://www.chromestatus.com/metrics/feature/popularity#AuthorizationCovered
>> ByWildcard
>>
>>
>> Gecko: Positive Firefox showed a positive signal in a private thread.
>>
>> WebKit: Positive Apple showed a positive signal in a private thread.
>>
>> Web developers: No signals
>>
>>
>> Debuggability
>>
>> We'll show a CORS error to the devtools console.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>> Flag nameCorsNonWildcardRequestHeadersSupport
>>
>> Requires code in //chrome?False (or, True only for the enterprise
>> policy.)
>>
>> Tracking bughttps://crbug.com/1176753
>>
>> Estimated milestones
>>
>> 97
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5742041264816128
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%40mail.gmail.com
>> 

Re: [blink-dev] Intent to Ship: HDR CSS Media Queries

[Chris Harrelson]

Hi, there were some discussions of the spec, and other questions, so far in
the thread. Will, could you summarize the current status? Thanks.

On Thu, Oct 28, 2021 at 12:04 PM David Baron  wrote:

>
>
> On Thu, Oct 28, 2021 at 2:38 PM Yoav Weiss  wrote:
>
>>
>>
>> On Friday, October 22, 2021 at 10:19:44 PM UTC+2 Fernando Serboncini
>> wrote:
>>
>>> [coming from the other thread... :) ]
>>>
>>> +1 to what David said. It doesn't seem that returning dynamic-range:
>>> high right now would be useful.
>>>
>>> The spec could use some clarification:
>>> - clarify if those criterias need to be supported on different
>>> conditions: CSS, images, canvas, ...
>>> - clarify if the criterias need to be supported for both with/without
>>> alpha (afaik there may be implementation differences there, but I may be
>>> wrong here).
>>> - I wonder if the definitions of high contrast/peak brightness should
>>> match the industry definitions for HDR displays? I'm not an expert, but I
>>> know those exist.
>>> I think it's potentially okay to ignore those definitions, but I'd ask
>>> for a rationale here.
>>>
>>> I think it's a great thing to summarize hdr into a single media query,
>>> but the risk here would be to release a semantic that guarantees very
>>> little, and therefore is not useful in the long run.
>>>
>>>
>>> On Fri, Oct 22, 2021 at 10:04 AM David Baron 
>>> wrote:
>>>
 This sounds like exactly the sort of case where an implementation
 should report (dynamic-range: standard) and (video-dynamic-range: high).
 It would be great to see the spec clarified to make it clearer what UA
 support is expected for each, though.

 -David

 On Thu, Oct 21, 2021 at 7:03 PM Will Cassella 
 wrote:

> Copying over from the other thread (trying to continue the discussion
> here):
>
> The spec  requires
>> that "The combination of the User Agent and the output device fulfill all
>> of the following criteria" when describing what it means to be high
>> dynamic-range.  Since Chromium doesn't support wide-gamut colors in CSS,
>> HTML, or Canvas
>
>
>> David - I'm likely missing something here, but I thought (based on this
>> thread
>> )
>> that we do have wide-gamut support in CSS, HTML and Canvas.
>> Are you saying we don't support this due to lack of color level 4
>> support? Or something else?
>>
>
> That intent makes it sound like we have wide-gamut support for canvas
> (though others would be able to speak more authoritatively about it) but I
> don't think we do in HTML or CSS.  (I also should have included images in
> my list, though I think if we have support with canvas then we probably do
> for images as well.).)
>
>
>> I also didn't interpret the spec as saying anything about gamut (but
>> rather about color depth ),
>> although it may be possible that wide gamuts and high color depth correlate
>> 1:1. Can you clarify if that's what you meant?
>>
>
> I should have been more precise about meeting the spec's requirements
> rather than just using the term "wide-gamut".  You're correct that it's not
> 1:1, though I think that in practice an implementation is unlikely to meet
> the spec's requirements on color depth and contrast ratio without
> supporting colors beyond sRGB's gamut.
>
> (I also suspect we may not meet the color depth requirement in the spec,
> perhaps not for canvas or images as well.)
>
> -David
>
>
>>
>>
>>> , I think it's probably incorrect to report that (dynamic-range: high) is
>> true based only on the device, which is what it looks to me like the 
>> current
>> code
>> 
>>  does.
>> Admittedly, the spec could probably use some clarification as to what it
>> means for the User Agent to fulfill the criteria for both the
>> dynamic-range and video-dynamic-range queries, but my understanding
>> of what the spec is trying to say is that Chrome probably shouldn't say
>> that (dynamic-range: high) is true until it supports wide-gamut
>> colors in at least some and maybe all of those contexts.
>
>
> I think you're right that the spec needs some clarification, since
> we're trying to incrementally enable adoption of HDR on the web the intent
> isn't to signal that HDR is supported by all APIs. We do already
> support HDR in some scenarios, such as the  element, so having 
> these
> queries exist to let developers detect display capabilities is already
> useful.
>
> On Wed, Oct 20, 2021 at 11:27 PM Yoav Weiss 
> wrote:
>
>>
>>
>> On Thu, Oct 21, 2021 at 7:01 AM Will Cassella 
>> 

Re: [blink-dev] Intent to Ship: auto keyword for contain-intrinsic-size

[Manuel Rego Casasnovas]

LGTM1 but please add WPT tests.

On 29/10/2021 21:19, 'Christian Biesinger' via blink-dev wrote:
> Is this feature fully tested by web-platform-tests?
> 
> No

I guess this is a mistake and you're actually adding WPT tests as part
of this.

Cheers,
  Rego

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eecd661f-669b-0def-2a71-f13cd3404051%40igalia.com.

Re: [blink-dev] Intent to Extend Origin Trial: Subresource loading with Web Bundles

[Daniel Bratell]

LGTM to extend the experiment until 101

/Daniel

On 2021-10-29 10:06, Hayato Ito wrote:

Hi Mike,

Thanks for the comment. We appreciate that. Let me add some 
clarifications and additional info.


On Fri, Oct 29, 2021 at 3:38 AM Mike West  wrote:

On Thu, Oct 28, 2021 at 6:49 AM Daisuke Enomoto
 wrote:


Contact emails

hay...@chromium.org, denom...@chromium.org


Explainer


https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md




Specification


Design docs


https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/content/browser/web_package/subresource_loading_origin_trial.md




Summary

Provides a new approach to load a large number of resources
efficiently using a format that allows multiple resources to
be bundled, e.g. Web Bundles.


Blink component

Blink>Loader>WebPackaging




TAG review

https://github.com/w3ctag/design-reviews/issues/616


(We’ll reopen this once we can have a consensus in the
discussion here )


TAG review status

Pending


Risks


Interoperability and Compatibility

No interoperability and compatibility risk has been identified
for the prototype phase. This is purely a feature addition for
the performance optimization for now.


It is expected that a browser which doesn’t support this
feature should load subresources from the network, as usual.

Gecko: No signal

WebKit: No signal

Web developers: No signals


This might be a good time to ask, as per
https://bit.ly/blink-signals. :)


That makes sense. Let us do that soon. We'll update this thread when done.


Ergonomics


Activation

Developers need to package their subresoruces beforehand in
order to take advantage of this feature. We'll work with JS
bundler ecosystems to provide a plugin to package subresources
as Web Bundles.


Security

No security risk has been identified for the prototype phase.


Goals for experimentation



This Intent to Extend includes a few major changes based on
the feedback collected during the original OT, which are 1)

Re: [blink-dev] Intent to Ship: CSS Color Adjust: 'only' keyword for color-scheme

[Chris Harrelson]

LGTM3

On Thu, Nov 4, 2021 at 12:19 PM Manuel Rego Casasnovas 
wrote:

> LGTM2, it's nice we're catching up with WebKit.
>
> I still miss the whole picture in the spec with all the properties and
> different values: https://drafts.csswg.org/css-color-adjust/
> Maybe a good explainer for the whole thing would be welcomed.
>
> Cheers,
>   Rego
>
> On 04/11/2021 19:49, Daniel Bratell wrote:
> > LGTM1
> >
> > /Daniel
> >
> > On 2021-10-29 21:09, Emilio Cobos Álvarez wrote:
> >>
> >>
> >> On 10/28/21 13:14, Rune Lillesveen wrote:
> >>> On Thu, Oct 28, 2021 at 12:11 PM Manuel Rego Casasnovas
> >>> mailto:r...@igalia.com>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Some comments inline.
> >>>
> >>> On 27/10/2021 16:09, Rune Lillesveen wrote:
> >>>  > Summary
> >>>  >
> >>>  > The 'only' keyword has been re-added to the specification for
> >>>  > color-scheme as a way of per-element opt-out of color-scheme
> >>> override
> >>>  > like forced darkening.
> >>>
> >>> I guess this is the CSSWG discussion about re-adding it:
> >>> https://github.com/w3c/csswg-drafts/issues/5089
> >>> 
> >>>
> >>>
> >>> Correct.
> >>>
> >>>  > Previously, both declarations below would force the div
> >>> element into
> >>>  > color-scheme dark and apply forced darkening. With this
> >>> change, the
> >>>  > second declaration would opt-out of forced darkening and keep
> the
> >>> used
> >>>  > color-scheme 'light'.
> >>>  >
> >>>  > div { color-scheme: light } div { color-scheme: only light }
> will
> >>> keep
> >>>  > the color-scheme for the element light and opt-out of forced
> >>> darkening.
> >>>
> >>> Let me clarify this comment, this is happening when we're in forced
> >>> darkening, am I right?
> >>> First I read it too quickly and "color-scheme: light" forcing the
> >>> DIV
> >>> into color-scheme dark was weird.
> >>>
> >>> Correct, when we're in forced darkening, or color-scheme override
> >>> which is the term used by the specification.
> >>>
> >>>  > This feature is already enabled as part of an original trial
> >>> in M96:
> >>>  > https://chromestatus.com/features/5672533924773888
> >>> 
> >>>  >  >>> >
> >>>
> >>> Do we have any results to comment from the origin trial? Or it was
> >>> mostly for auto dark mode and this was just a small bit of it?
> >>>
> >>>
> >>> That was mostly for auto dark mode, but Peter can confirm.
> >>>
> >>>  > Gecko: In development
> >>>  > (https://bugzilla.mozilla.org/show_bug.cgi?id=1576289
> >>> 
> >>>  >  >>> >) Development
> of
> >>>  > the color-scheme property in progress. At least blocker issues
> >>> are being
> >>>  > fixed.
> >>>
> >>> Not sure if this is in development, as there seems to be not recent
> >>> activity on the bug; but they indeed look interested in
> implementing
> >>> color-scheme property. Do we have any feedback from Mozilla about
> >>> this
> >>> "only" keyword?
> >>>
> >>>
> >>> Emilio (added) has been fixing blocker issues, fixing tests, doing
> >>> spec changes for , etc, which I took as a
> >>> signal of Mozilla working on it.
> >>
> >> Yeah, indeed. I guess my only question about the only keyword is
> >> whether it'd be applicable to printing as well.
> >>
> >> In particular, Chrome right now respects  >> content=dark> while printing, but it might be reasonable for UAs to
> >> force it to light in that case, in order to save ink...
> >>
> >> I guess `only` could also serve as a hint for the UA to not do such
> >> thing... But then again we already have a way to opt out of similar
> >> adjustments with `color-adjust: exact`. Was extending / expanding the
> >> scope of the `color-adjust` property for this, instead of adding an
> >> `only` value to `color-scheme` considered?
> >>
> >>  -- Emilio
> >>
> >>> --
> >>> Rune Lillesveen
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> >>> Groups "blink-dev" group.
> >>> To unsubscribe from this group and stop receiving emails from it,
> >>> send an email to blink-dev+unsubscr...@chromium.org
> >>> .
> >>> To view this discussion on the web visit
> >>>
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeTAFoyWbcQxnnHqhGcUWoZyOrBtfc%2BjcgnUVESnoSyPYw%40mail.gmail.com
> >>> <
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeTAFoyWbcQxnnHqhGcUWoZyOrBtfc%2BjcgnUVESnoSyPYw%40mail.gmail.com?utm_medium=email_source=footer
> >.
> >>>
> >>
> >
>
> --
> You received this message 

Re: [blink-dev] Intent to Ship: CSS Color Adjust: 'only' keyword for color-scheme

[Manuel Rego Casasnovas]

LGTM2, it's nice we're catching up with WebKit.

I still miss the whole picture in the spec with all the properties and
different values: https://drafts.csswg.org/css-color-adjust/
Maybe a good explainer for the whole thing would be welcomed.

Cheers,
  Rego

On 04/11/2021 19:49, Daniel Bratell wrote:
> LGTM1
> 
> /Daniel
> 
> On 2021-10-29 21:09, Emilio Cobos Álvarez wrote:
>>
>>
>> On 10/28/21 13:14, Rune Lillesveen wrote:
>>> On Thu, Oct 28, 2021 at 12:11 PM Manuel Rego Casasnovas
>>> mailto:r...@igalia.com>> wrote:
>>>
>>>     Hi,
>>>
>>>     Some comments inline.
>>>
>>>     On 27/10/2021 16:09, Rune Lillesveen wrote:
>>>  >         Summary
>>>  >
>>>  > The 'only' keyword has been re-added to the specification for
>>>  > color-scheme as a way of per-element opt-out of color-scheme
>>> override
>>>  > like forced darkening.
>>>
>>>     I guess this is the CSSWG discussion about re-adding it:
>>>     https://github.com/w3c/csswg-drafts/issues/5089
>>>     
>>>
>>>
>>> Correct.
>>>
>>>  > Previously, both declarations below would force the div
>>> element into
>>>  > color-scheme dark and apply forced darkening. With this
>>> change, the
>>>  > second declaration would opt-out of forced darkening and keep the
>>>     used
>>>  > color-scheme 'light'.
>>>  >
>>>  > div { color-scheme: light } div { color-scheme: only light } will
>>>     keep
>>>  > the color-scheme for the element light and opt-out of forced
>>>     darkening.
>>>
>>>     Let me clarify this comment, this is happening when we're in forced
>>>     darkening, am I right?
>>>     First I read it too quickly and "color-scheme: light" forcing the
>>> DIV
>>>     into color-scheme dark was weird.
>>>
>>> Correct, when we're in forced darkening, or color-scheme override
>>> which is the term used by the specification.
>>>
>>>  > This feature is already enabled as part of an original trial
>>> in M96:
>>>  > https://chromestatus.com/features/5672533924773888
>>>     
>>>  > >> >
>>>
>>>     Do we have any results to comment from the origin trial? Or it was
>>>     mostly for auto dark mode and this was just a small bit of it?
>>>
>>>
>>> That was mostly for auto dark mode, but Peter can confirm.
>>>
>>>  > Gecko: In development
>>>  > (https://bugzilla.mozilla.org/show_bug.cgi?id=1576289
>>>     
>>>  > >> >) Development of
>>>  > the color-scheme property in progress. At least blocker issues
>>>     are being
>>>  > fixed.
>>>
>>>     Not sure if this is in development, as there seems to be not recent
>>>     activity on the bug; but they indeed look interested in implementing
>>>     color-scheme property. Do we have any feedback from Mozilla about
>>> this
>>>     "only" keyword?
>>>
>>>
>>> Emilio (added) has been fixing blocker issues, fixing tests, doing
>>> spec changes for , etc, which I took as a
>>> signal of Mozilla working on it.
>>
>> Yeah, indeed. I guess my only question about the only keyword is
>> whether it'd be applicable to printing as well.
>>
>> In particular, Chrome right now respects > content=dark> while printing, but it might be reasonable for UAs to
>> force it to light in that case, in order to save ink...
>>
>> I guess `only` could also serve as a hint for the UA to not do such
>> thing... But then again we already have a way to opt out of similar
>> adjustments with `color-adjust: exact`. Was extending / expanding the
>> scope of the `color-adjust` property for this, instead of adding an
>> `only` value to `color-scheme` considered?
>>
>>  -- Emilio
>>
>>> -- 
>>> Rune Lillesveen
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to blink-dev+unsubscr...@chromium.org
>>> .
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeTAFoyWbcQxnnHqhGcUWoZyOrBtfc%2BjcgnUVESnoSyPYw%40mail.gmail.com
>>> .
>>>
>>
> 

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 

Re: [blink-dev] Intent to Experiment: Web app launch handler

[Chris Harrelson]

LGTM, but is this only in M97? Or did you want to run it for
additional milestones?

On Wed, Oct 27, 2021 at 1:55 AM Alan Cutter  wrote:

> Contact emailsalancut...@chromium.org, mgi...@chromium.org
>
> Explainerhttps://github.com/WICG/sw-launch/blob/main/launch_handler.md
>
> Summary
>
> Adds a "launch_handler" app manifest member that enables web apps to
> customise their launch behaviour across all types of app launch triggers.
> Example usage: { "name": "Example app", "start_url": "/index.html",
> "launch_handler": { "route_to": "existing", "navigate_existing_client":
> "always" } } This will cause all launches of the Example app to focus an
> existing app window and navigate it (if it exists) instead of always
> launching a new app window.
>
>
> Blink componentBlink>AppManifest
> 
>
> Search tagsweb app 
> , pwa , link capturing
> , link
> handling ,
> launch 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/683
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: No signal
> 
>
> WebKit:
>
> Web developers: Strong positive signals on the Declarative Link Capturing
> origin trial
>  
> which
> has overlapping behaviour with this API (which is replacing DLC).
>
>
> Goals for experimentation
>
> Replace the Declarative Link Capturing
> 
> API experiment and gather feedback on the "navigate_existing_client":
> "never" behaviour as it gets an implementation.
>
> Ongoing technical constraints
>
> Overlap with the Declarative Link Capturing origin trial
>  
> to
> enable existing clients to migrate over to this new API.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Windows, Mac, Linux and
> Chrome OS.
>
> Is this feature fully tested by web-platform-tests
> 
> ?No, this requires browser tests
> 
> .
>
> Flag nameWebAppEnableLaunchHandler
> chrome://flags/#enable-desktop-pwas-launch-handler
>
> Requires code in //chrome?True
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1231886
>
> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1247817
>
> Estimated milestones
>
> M97
>
>
> Link to entry on the Chrome Platform Status
> https://www.chromestatus.com/feature/5722383233056768
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/8tNe2jrJ78A
>
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANJJ2Cm5RFDLAf7n5eRhgHbgioCUe8uv16Sh5v5BSoMgSdKJrw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9e6oQN1tL-i3KoJWrRUxiQy7yQW%3DbVHxAjZr-j3bz31g%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Extend Origin Trial: Conversion Measurement API (Attribution Reporting API)

[Daniel Bratell]

LGTM3 to restart with more special origin trials

/Daniel

On 2021-11-03 21:05, Chris Harrelson wrote:



On Wed, Nov 3, 2021 at 12:56 PM John Delaney  
wrote:


Just to clarify, this extension requires 3 LGTMs correct?


I am assuming that the statement from the last extension is still
true:

https://groups.google.com/a/chromium.org/g/blink-dev/c/DmsUL3KHqMk/m/K6RhFq7nAAAJ


Correct. Yes it does. The API owners are meeting tomorrow and I'll ask 
the other about a third LGTM.



On Monday, November 1, 2021 at 11:27:40 AM UTC-4 Chris Harrelson
wrote:

(Sorry, ignore that email. Clicked the wrong button.)

LGTM2

On Mon, Nov 1, 2021 at 8:24 AM Chris Harrelson
 wrote:

Updated.

On Sun, Oct 31, 2021 at 6:34 AM Yoav Weiss
 wrote:

Thanks for the feedback report. It's great!!

LGTM1 to extend the OT to M97


On Sat, Oct 30, 2021, 00:37 John Delaney
 wrote:

> We're inclined to extend this OT, but wanted to
quickly check in to see if y'all have any interim
results from the trial thus far. Are you surveying
developers? Is there some feedback you could
perhaps aggregate to give us a sense for how it's
going?

Most definitely! We have received a lot of great
feedback from people testing the API. In general
we have been receiving two categories of feedback
from the Origin Trial: accuracy of API reports,
feedback on whether certain use-cases are met.

See

https://github.com/WICG/conversion-measurement-api/issues/201
for some exemplary feedback.

Feedback on accuracy:

Testers have identified some differences between
our API and cookie based conversions, where the
browser either doesn't send a report when expected
/ or sends an unexpected. We are continuing to
explore this space and are making progress.

See

https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting-data-clearing/
which deep dives into learnings regarding data
clearing from the OT.

In Chrome 94 we changed the way that Chrome
retries reports, and have marked improvement in
the accuracy of API reports as seen by some testers.

In general, we are hearing that
integrating/verifying the API comes with its own
set of challenges due to how different it is from
the status quo. We are actively collaborating to
improve the API in this regard

(https://github.com/WICG/conversion-measurement-api/issues/174)

Use-case feedback:

The other key area of feedback we are receiving is
use-cases not recoverable in the API. As
developers have dug into the API, they have raised
changes the API will need to work as expected.

Some examples:

  * Adding coverage for ads which navigate using
window.open
  o 
https://github.com/WICG/conversion-measurement-api/issues/77
  * Allowing attribution to be scoped more
granularly than "site"
  o 
https://github.com/WICG/conversion-measurement-api/issues/115
  * Adding more ergonomic ways to provide data to
the API
  o 
https://github.com/WICG/conversion-measurement-api/issues/261

We still have active development to cover cases
like these which come up in practice.

Please let me know if there is anything specific
you would like us to speak to!

John


On Thursday, October 28, 2021 at 3:34:33 PM UTC-4
Alex Russell wrote:

hey John,

In line with the policy we adopted earlier
regarding trials in this bucket of features
[1], I appreciate the reporting around total
page loads.

We're inclined to extend this OT, but wanted
to quickly check in to see if y'all have any
interim results from the trial thus far. Are
you surveying developers? Is there some

Re: [blink-dev] Intent to Ship: New Canvas 2D API

['Thomas Steiner' via blink-dev]

On Thu 4. Nov 2021 at 20:01 'Aaron Krajeski' via blink-dev <
blink-dev@chromium.org> wrote:

> During a WHATWG spec meeting this morning we agreed to not throw for
> malformed canvas filters. There are still a few editorial changes to go
> through on that PR, but other than that everything is settled for this
> launch.


What about the console warnings? Or is this not a spec-level decision, but
an implementation detail?

On Friday, October 29, 2021 at 1:53:20 PM UTC-4 dom...@chromium.org wrote:
>
>> The usual definition of "breaking change" that we use when shipping
>> features is not "if web developers always do valid things, then the change
>> we are making avoids breakages". We can't rely on web developers to write
>> valid code all the time... see e.g. stats about what percent of the web is
>> valid HTML.
>>
>> For example, while people might not write "asdf", they might write
>> "colourMatrix" (spot the typo), or similar.
>>
>> On Fri, Oct 29, 2021 at 1:50 PM Fernando Serboncini 
>> wrote:
>>
>>> yes, of course if you pass "asdf" one would throw and the other
>>> wouldn't. There will be a potential behavior difference.
>>>
>>> My point is nobody would write "asdf" as a filter, because "asdf" is not
>>> a spec'ed or implemented filter anywhere. There are no possible mismatches
>>> at this point. If CanvasFilter exists, the set of filters is well defined
>>> everywhere.
>>>
>>> On Fri, Oct 29, 2021 at 1:45 PM Domenic Denicola 
>>> wrote:
>>>
 I don't think that's true. If someone passes "asdf" to the CanvasFilter
 constructor, changing from not-throwing to throwing would be a breaking
 change. We'd need to add use counters, etc. to find out if anyone is
 passing such invalid values.

 Whereas, if we start off with throwing, we can always remove the
 throwing behavior later, with no use counters required.

 On Fri, Oct 29, 2021 at 1:43 PM Fernando Serboncini 
 wrote:

> Since the current implementation is not throwing, we could reasonably
> launch as-is and the add throwing if it is agreed to do so after.
> The added risk is the exact same risk that we are arguing to begin
> with (i.e., code that uses not-implemented filters without try/catch would
> break). But since there are no "not-implemented filters" yet, it may not 
> be
> a problem.
>
> On Fri, Oct 29, 2021 at 1:34 PM Domenic Denicola 
> wrote:
>
>> Yep. Reasonable people can disagree on the tradeoffs here. The
>> question is whether this is something we want to deadlock over with other
>> implementers.
>>
>> On Fri, Oct 29, 2021 at 12:28 PM Mike Taylor 
>> wrote:
>>
>>> On 10/29/21 1:23 AM, Yoav Weiss wrote:
>>>
>>> Hey Domenic! :)
>>>
>>> On Thu, Oct 28, 2021 at 11:00 PM Domenic Denicola <
>>> dom...@chromium.org> wrote:
>>>

 FWIW the two HTML editors on the thread (myself and Anne, with our
 HTML editor hats on), as well as Mozilla (via Anne with his Mozilla hat
 on), prefer the throwing behavior. I think in most cases to overcome 
 that
 position we would need some really strong reasons why the Chromium 
 project
 believes the non-throwing behavior is better. It's not clear to me how
 strong Chromium's position is on this issue, and whether it's worth
 delaying the feature over. (Or indeed, delaying all the features, 
 since the
 plan seems to be to bundle them together?)

>>>
>>> My concerns with the throwing behavior are similar to the ones we
>>> have discussed
>>> 
>>> in the context of MediaSession actions.
>>> If we go with the throwing behavior, every future addition of
>>> filters would have a significant interop risk, in case adopting 
>>> developers
>>> won't use try/catch properly. If they do that and they are not testing 
>>> in
>>> not-yet-supporting browsers, their apps are likely to break entirely in
>>> those browsers.
>>> If we go with a silent failure + feature detection approach,
>>> developers using the feature without properly detecting it may not have 
>>> the
>>> desired visual effects they are going for, but won't have unrelated 
>>> parts
>>> of their app break.
>>>
>>> From my perspective (with my API owner hat on), less risk is better,
>>> and the second approach seems less risky to me.
>>>
>>> I agree with Yoav here (sorry, I don't own any hats). Not throwing
>>> will likely result in fewer broken pages in less-well-tested browsers 
>>> that
>>> haven't implemented the APIs yet. And +1 for devtools warnings to help
>>> developers figure out "silent" failures.
>>>
>>> (I also wonder if requiring try/catch won't trip up new developers
>>> trying to use it inside Promises, who don't 

Re: [blink-dev] Intent to Ship: New Canvas 2D API

[Manuel Rego Casasnovas]

LGTM3

On 04/11/2021 20:04, Daniel Bratell wrote:
> LGTM2
> 
> /Daniel
> 
> On 2021-11-04 20:02, Chris Harrelson wrote:
>> LGTM1 to ship in parallel with landing the PR.
>>
>> On Thu, Nov 4, 2021 at 12:01 PM 'Aaron Krajeski' via blink-dev
>>  wrote:
>>
>> During a WHATWG spec meeting this morning we agreed to not throw
>> for malformed canvas filters. There are still a few editorial
>> changes to go through on that PR, but other than that everything
>> is settled for this launch.
>>
>> On Friday, October 29, 2021 at 1:53:20 PM UTC-4
>> dom...@chromium.org wrote:
>>
>> The usual definition of "breaking change" that we use when
>> shipping features is not "if web developers always do valid
>> things, then the change we are making avoids breakages". We
>> can't rely on web developers to write valid code all the
>> time... see e.g. stats about what percent of the web is valid
>> HTML.
>>
>> For example, while people might not write "asdf", they might
>> write "colourMatrix" (spot the typo), or similar.
>>
>> On Fri, Oct 29, 2021 at 1:50 PM Fernando Serboncini
>>  wrote:
>>
>> yes, of course if you pass "asdf" one would throw and the
>> other wouldn't. There will be a potential behavior difference.
>>
>> My point is nobody would write "asdf" as a filter, because
>> "asdf" is not a spec'ed or implemented filter anywhere.
>> There are no possible mismatches at this point. If
>> CanvasFilter exists, the set of filters is well defined
>> everywhere.
>>
>> On Fri, Oct 29, 2021 at 1:45 PM Domenic Denicola
>>  wrote:
>>
>> I don't think that's true. If someone passes "asdf" to
>> the CanvasFilter constructor, changing from
>> not-throwing to throwing would be a breaking change.
>> We'd need to add use counters, etc. to find out if
>> anyone is passing such invalid values.
>>
>> Whereas, if we start off with throwing, we can always
>> remove the throwing behavior later, with no use
>> counters required.
>>
>> On Fri, Oct 29, 2021 at 1:43 PM Fernando Serboncini
>>  wrote:
>>
>> Since the current implementation is not throwing,
>> we could reasonably launch as-is and the add
>> throwing if it is agreed to do so after.
>> The added risk is the exact same risk that we are
>> arguing to begin with (i.e., code that uses
>> not-implemented filters without try/catch would
>> break). But since there are no "not-implemented
>> filters" yet, it may not be a problem.
>>
>> On Fri, Oct 29, 2021 at 1:34 PM Domenic Denicola
>>  wrote:
>>
>> Yep. Reasonable people can disagree on the
>> tradeoffs here. The question is whether this
>> is something we want to deadlock over with
>> other implementers.
>>
>> On Fri, Oct 29, 2021 at 12:28 PM Mike Taylor
>>  wrote:
>>
>> On 10/29/21 1:23 AM, Yoav Weiss wrote:
>>> Hey Domenic! :)
>>>
>>> On Thu, Oct 28, 2021 at 11:00 PM Domenic
>>> Denicola  wrote:
>>>
>>>
>>> FWIW the two HTML editors on the
>>> thread (myself and Anne, with our
>>> HTML editor hats on), as well as
>>> Mozilla (via Anne with his Mozilla
>>> hat on), prefer the throwing
>>> behavior. I think in most cases to
>>> overcome that position we would need
>>> some really strong reasons why the
>>> Chromium project believes the
>>> non-throwing behavior is better. It's
>>> not clear to me how strong Chromium's
>>> position is on this issue, and
>>> whether it's worth delaying the
>>> feature over. (Or indeed, delaying
>>> all the features, since the plan
>>> seems to be to bundle them together?)
>>>
>>>
>>> My concerns with the throwing behavior
>>> are similar to the ones we have discussed
>>> 
>>> 

Re: [blink-dev] Intent to Ship: New Canvas 2D API

[Daniel Bratell]

LGTM2

/Daniel

On 2021-11-04 20:02, Chris Harrelson wrote:

LGTM1 to ship in parallel with landing the PR.

On Thu, Nov 4, 2021 at 12:01 PM 'Aaron Krajeski' via blink-dev 
 wrote:


During a WHATWG spec meeting this morning we agreed to not throw
for malformed canvas filters. There are still a few editorial
changes to go through on that PR, but other than that everything
is settled for this launch.

On Friday, October 29, 2021 at 1:53:20 PM UTC-4
dom...@chromium.org wrote:

The usual definition of "breaking change" that we use when
shipping features is not "if web developers always do valid
things, then the change we are making avoids breakages". We
can't rely on web developers to write valid code all the
time... see e.g. stats about what percent of the web is valid
HTML.

For example, while people might not write "asdf", they might
write "colourMatrix" (spot the typo), or similar.

On Fri, Oct 29, 2021 at 1:50 PM Fernando Serboncini
 wrote:

yes, of course if you pass "asdf" one would throw and the
other wouldn't. There will be a potential behavior difference.

My point is nobody would write "asdf" as a filter, because
"asdf" is not a spec'ed or implemented filter anywhere.
There are no possible mismatches at this point. If
CanvasFilter exists, the set of filters is well defined
everywhere.

On Fri, Oct 29, 2021 at 1:45 PM Domenic Denicola
 wrote:

I don't think that's true. If someone passes "asdf" to
the CanvasFilter constructor, changing from
not-throwing to throwing would be a breaking change.
We'd need to add use counters, etc. to find out if
anyone is passing such invalid values.

Whereas, if we start off with throwing, we can always
remove the throwing behavior later, with no use
counters required.

On Fri, Oct 29, 2021 at 1:43 PM Fernando Serboncini
 wrote:

Since the current implementation is not throwing,
we could reasonably launch as-is and the add
throwing if it is agreed to do so after.
The added risk is the exact same risk that we are
arguing to begin with (i.e., code that uses
not-implemented filters without try/catch would
break). But since there are no "not-implemented
filters" yet, it may not be a problem.

On Fri, Oct 29, 2021 at 1:34 PM Domenic Denicola
 wrote:

Yep. Reasonable people can disagree on the
tradeoffs here. The question is whether this
is something we want to deadlock over with
other implementers.

On Fri, Oct 29, 2021 at 12:28 PM Mike Taylor
 wrote:

On 10/29/21 1:23 AM, Yoav Weiss wrote:

Hey Domenic! :)

On Thu, Oct 28, 2021 at 11:00 PM Domenic
Denicola  wrote:


FWIW the two HTML editors on the
thread (myself and Anne, with our
HTML editor hats on), as well as
Mozilla (via Anne with his Mozilla
hat on), prefer the throwing
behavior. I think in most cases to
overcome that position we would need
some really strong reasons why the
Chromium project believes the
non-throwing behavior is better. It's
not clear to me how strong Chromium's
position is on this issue, and
whether it's worth delaying the
feature over. (Or indeed, delaying
all the features, since the plan
seems to be to bundle them together?)


My concerns with the throwing behavior
are similar to the ones we have discussed


in the context of MediaSession actions.
If we go with the throwing behavior,
every future addition of filters would
have a significant interop risk, in case
adopting developers won't 

Re: [blink-dev] Intent to Ship: New Canvas 2D API

[Chris Harrelson]

LGTM1 to ship in parallel with landing the PR.

On Thu, Nov 4, 2021 at 12:01 PM 'Aaron Krajeski' via blink-dev <
blink-dev@chromium.org> wrote:

> During a WHATWG spec meeting this morning we agreed to not throw for
> malformed canvas filters. There are still a few editorial changes to go
> through on that PR, but other than that everything is settled for this
> launch.
>
> On Friday, October 29, 2021 at 1:53:20 PM UTC-4 dom...@chromium.org wrote:
>
>> The usual definition of "breaking change" that we use when shipping
>> features is not "if web developers always do valid things, then the change
>> we are making avoids breakages". We can't rely on web developers to write
>> valid code all the time... see e.g. stats about what percent of the web is
>> valid HTML.
>>
>> For example, while people might not write "asdf", they might write
>> "colourMatrix" (spot the typo), or similar.
>>
>> On Fri, Oct 29, 2021 at 1:50 PM Fernando Serboncini 
>> wrote:
>>
>>> yes, of course if you pass "asdf" one would throw and the other
>>> wouldn't. There will be a potential behavior difference.
>>>
>>> My point is nobody would write "asdf" as a filter, because "asdf" is not
>>> a spec'ed or implemented filter anywhere. There are no possible mismatches
>>> at this point. If CanvasFilter exists, the set of filters is well defined
>>> everywhere.
>>>
>>> On Fri, Oct 29, 2021 at 1:45 PM Domenic Denicola 
>>> wrote:
>>>
 I don't think that's true. If someone passes "asdf" to the CanvasFilter
 constructor, changing from not-throwing to throwing would be a breaking
 change. We'd need to add use counters, etc. to find out if anyone is
 passing such invalid values.

 Whereas, if we start off with throwing, we can always remove the
 throwing behavior later, with no use counters required.

 On Fri, Oct 29, 2021 at 1:43 PM Fernando Serboncini 
 wrote:

> Since the current implementation is not throwing, we could reasonably
> launch as-is and the add throwing if it is agreed to do so after.
> The added risk is the exact same risk that we are arguing to begin
> with (i.e., code that uses not-implemented filters without try/catch would
> break). But since there are no "not-implemented filters" yet, it may not 
> be
> a problem.
>
> On Fri, Oct 29, 2021 at 1:34 PM Domenic Denicola 
> wrote:
>
>> Yep. Reasonable people can disagree on the tradeoffs here. The
>> question is whether this is something we want to deadlock over with other
>> implementers.
>>
>> On Fri, Oct 29, 2021 at 12:28 PM Mike Taylor 
>> wrote:
>>
>>> On 10/29/21 1:23 AM, Yoav Weiss wrote:
>>>
>>> Hey Domenic! :)
>>>
>>> On Thu, Oct 28, 2021 at 11:00 PM Domenic Denicola <
>>> dom...@chromium.org> wrote:
>>>

 FWIW the two HTML editors on the thread (myself and Anne, with our
 HTML editor hats on), as well as Mozilla (via Anne with his Mozilla hat
 on), prefer the throwing behavior. I think in most cases to overcome 
 that
 position we would need some really strong reasons why the Chromium 
 project
 believes the non-throwing behavior is better. It's not clear to me how
 strong Chromium's position is on this issue, and whether it's worth
 delaying the feature over. (Or indeed, delaying all the features, 
 since the
 plan seems to be to bundle them together?)

>>>
>>> My concerns with the throwing behavior are similar to the ones we
>>> have discussed
>>> 
>>> in the context of MediaSession actions.
>>> If we go with the throwing behavior, every future addition of
>>> filters would have a significant interop risk, in case adopting 
>>> developers
>>> won't use try/catch properly. If they do that and they are not testing 
>>> in
>>> not-yet-supporting browsers, their apps are likely to break entirely in
>>> those browsers.
>>> If we go with a silent failure + feature detection approach,
>>> developers using the feature without properly detecting it may not have 
>>> the
>>> desired visual effects they are going for, but won't have unrelated 
>>> parts
>>> of their app break.
>>>
>>> From my perspective (with my API owner hat on), less risk is better,
>>> and the second approach seems less risky to me.
>>>
>>> I agree with Yoav here (sorry, I don't own any hats). Not throwing
>>> will likely result in fewer broken pages in less-well-tested browsers 
>>> that
>>> haven't implemented the APIs yet. And +1 for devtools warnings to help
>>> developers figure out "silent" failures.
>>>
>>> (I also wonder if requiring try/catch won't trip up new developers
>>> trying to use it inside Promises, who don't yet know about 
>>> `then()/catch()`
>>> 

Re: [blink-dev] Intent to Ship: New Canvas 2D API

['Aaron Krajeski' via blink-dev]

During a WHATWG spec meeting this morning we agreed to not throw for 
malformed canvas filters. There are still a few editorial changes to go 
through on that PR, but other than that everything is settled for this 
launch.

On Friday, October 29, 2021 at 1:53:20 PM UTC-4 dom...@chromium.org wrote:

> The usual definition of "breaking change" that we use when shipping 
> features is not "if web developers always do valid things, then the change 
> we are making avoids breakages". We can't rely on web developers to write 
> valid code all the time... see e.g. stats about what percent of the web is 
> valid HTML.
>
> For example, while people might not write "asdf", they might write 
> "colourMatrix" (spot the typo), or similar.
>
> On Fri, Oct 29, 2021 at 1:50 PM Fernando Serboncini  
> wrote:
>
>> yes, of course if you pass "asdf" one would throw and the other wouldn't. 
>> There will be a potential behavior difference.
>>
>> My point is nobody would write "asdf" as a filter, because "asdf" is not 
>> a spec'ed or implemented filter anywhere. There are no possible mismatches 
>> at this point. If CanvasFilter exists, the set of filters is well defined 
>> everywhere.
>>
>> On Fri, Oct 29, 2021 at 1:45 PM Domenic Denicola  
>> wrote:
>>
>>> I don't think that's true. If someone passes "asdf" to the CanvasFilter 
>>> constructor, changing from not-throwing to throwing would be a breaking 
>>> change. We'd need to add use counters, etc. to find out if anyone is 
>>> passing such invalid values.
>>>
>>> Whereas, if we start off with throwing, we can always remove the 
>>> throwing behavior later, with no use counters required.
>>>
>>> On Fri, Oct 29, 2021 at 1:43 PM Fernando Serboncini  
>>> wrote:
>>>
 Since the current implementation is not throwing, we could reasonably 
 launch as-is and the add throwing if it is agreed to do so after.
 The added risk is the exact same risk that we are arguing to begin with 
 (i.e., code that uses not-implemented filters without try/catch would 
 break). But since there are no "not-implemented filters" yet, it may not 
 be 
 a problem.

 On Fri, Oct 29, 2021 at 1:34 PM Domenic Denicola  
 wrote:

> Yep. Reasonable people can disagree on the tradeoffs here. The 
> question is whether this is something we want to deadlock over with other 
> implementers.
>
> On Fri, Oct 29, 2021 at 12:28 PM Mike Taylor  
> wrote:
>
>> On 10/29/21 1:23 AM, Yoav Weiss wrote:
>>
>> Hey Domenic! :)
>>
>> On Thu, Oct 28, 2021 at 11:00 PM Domenic Denicola <
>> dom...@chromium.org> wrote:
>>
>>>
>>> FWIW the two HTML editors on the thread (myself and Anne, with our 
>>> HTML editor hats on), as well as Mozilla (via Anne with his Mozilla hat 
>>> on), prefer the throwing behavior. I think in most cases to overcome 
>>> that 
>>> position we would need some really strong reasons why the Chromium 
>>> project 
>>> believes the non-throwing behavior is better. It's not clear to me how 
>>> strong Chromium's position is on this issue, and whether it's worth 
>>> delaying the feature over. (Or indeed, delaying all the features, since 
>>> the 
>>> plan seems to be to bundle them together?)
>>>
>>
>> My concerns with the throwing behavior are similar to the ones we 
>> have discussed 
>>  
>> in the context of MediaSession actions.
>> If we go with the throwing behavior, every future addition of filters 
>> would have a significant interop risk, in case adopting developers won't 
>> use try/catch properly. If they do that and they are not testing in 
>> not-yet-supporting browsers, their apps are likely to break entirely in 
>> those browsers. 
>> If we go with a silent failure + feature detection approach, 
>> developers using the feature without properly detecting it may not have 
>> the 
>> desired visual effects they are going for, but won't have unrelated 
>> parts 
>> of their app break.
>>
>> From my perspective (with my API owner hat on), less risk is better, 
>> and the second approach seems less risky to me.
>>
>> I agree with Yoav here (sorry, I don't own any hats). Not throwing 
>> will likely result in fewer broken pages in less-well-tested browsers 
>> that 
>> haven't implemented the APIs yet. And +1 for devtools warnings to help 
>> developers figure out "silent" failures.
>>
>> (I also wonder if requiring try/catch won't trip up new developers 
>> trying to use it inside Promises, who don't yet know about 
>> `then()/catch()` 
>> patterns).
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: [blink-dev] Intent to Ship: CSS Color Adjust: 'only' keyword for color-scheme

[Daniel Bratell]

LGTM1

/Daniel

On 2021-10-29 21:09, Emilio Cobos Álvarez wrote:



On 10/28/21 13:14, Rune Lillesveen wrote:
On Thu, Oct 28, 2021 at 12:11 PM Manuel Rego Casasnovas 
mailto:r...@igalia.com>> wrote:


    Hi,

    Some comments inline.

    On 27/10/2021 16:09, Rune Lillesveen wrote:
 >         Summary
 >
 > The 'only' keyword has been re-added to the specification for
 > color-scheme as a way of per-element opt-out of color-scheme 
override

 > like forced darkening.

    I guess this is the CSSWG discussion about re-adding it:
    https://github.com/w3c/csswg-drafts/issues/5089
    


Correct.

 > Previously, both declarations below would force the div 
element into
 > color-scheme dark and apply forced darkening. With this 
change, the

 > second declaration would opt-out of forced darkening and keep the
    used
 > color-scheme 'light'.
 >
 > div { color-scheme: light } div { color-scheme: only light } will
    keep
 > the color-scheme for the element light and opt-out of forced
    darkening.

    Let me clarify this comment, this is happening when we're in forced
    darkening, am I right?
    First I read it too quickly and "color-scheme: light" forcing the 
DIV

    into color-scheme dark was weird.

Correct, when we're in forced darkening, or color-scheme override 
which is the term used by the specification.


 > This feature is already enabled as part of an original trial 
in M96:

 > https://chromestatus.com/features/5672533924773888
    
 > >

    Do we have any results to comment from the origin trial? Or it was
    mostly for auto dark mode and this was just a small bit of it?


That was mostly for auto dark mode, but Peter can confirm.

 > Gecko: In development
 > (https://bugzilla.mozilla.org/show_bug.cgi?id=1576289
    
 > >) Development of
 > the color-scheme property in progress. At least blocker issues
    are being
 > fixed.

    Not sure if this is in development, as there seems to be not recent
    activity on the bug; but they indeed look interested in implementing
    color-scheme property. Do we have any feedback from Mozilla about 
this

    "only" keyword?


Emilio (added) has been fixing blocker issues, fixing tests, doing 
spec changes for , etc, which I took as a 
signal of Mozilla working on it.


Yeah, indeed. I guess my only question about the only keyword is 
whether it'd be applicable to printing as well.


In particular, Chrome right now respects content=dark> while printing, but it might be reasonable for UAs to 
force it to light in that case, in order to save ink...


I guess `only` could also serve as a hint for the UA to not do such 
thing... But then again we already have a way to opt out of similar 
adjustments with `color-adjust: exact`. Was extending / expanding the 
scope of the `color-adjust` property for this, instead of adding an 
`only` value to `color-scheme` considered?


 -- Emilio


--
Rune Lillesveen

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, 
send an email to blink-dev+unsubscr...@chromium.org 
.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeTAFoyWbcQxnnHqhGcUWoZyOrBtfc%2BjcgnUVESnoSyPYw%40mail.gmail.com 
. 





--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a050a8ac-2d3c-4844-0d2e-36848a395704%40gmail.com.

Re: [blink-dev] Questions about WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS

[Xianzhu Wang]

Actually we have only two remaining usages of such macros in blink geometry
types:
1. float_size.h

:
  // Allows this class to be stored in a HeapVector.
  WTF_ALLOW_CLEAR_UNUSED_SLOTS_WITH_MEM_FUNCTIONS(blink::FloatSize)
  This seems unnecessary because FloatSize is not a garbage collected type,
and we don't have any usage of Vector in blink.
2. int_rect.h

:
  WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS(blink::IntRect)
  We have a lot of Vector usages. Will try perf tests.

About std::is_trivial, actually we don't allow particular trivial types to
use such macros. For example, in
WTF_ALLOW_MOVE_AND_INIT_WITH_MEM_FUNCTIONS, we have:
   static_assert(!std::is_trivially_default_constructible::value
|| \
!std::is_trivially_move_assignable::value, \
"macro not needed"); \

Also most of our classes (including all geometry classes) are not trivially
default constructible because they do need initialization. We could check
if a default constructed object is all zero to see if it can be initialized
by memset, but I'm not sure if this is possible at compile time.

It seems that we can check std::is_trivially_copyable and/or
std::is_trivially_move_assignable for kCan*WithMemcpy
and kCanCompareWithMemcmp.


On Thu, Nov 4, 2021 at 10:39 AM Xianzhu Wang 
wrote:

> One data point: the CL
>  that
> replaces blink::IntPoint (declared with the macro) with gfx::Point was
> landed 2 days ago, and I haven't received any performance bug yet. Perhaps
> we don't use Vector in performance critical code.
>
> Will try std::is_trivial before converting other types.
>
> On Thu, Nov 4, 2021 at 10:19 AM Daniel Bratell 
> wrote:
>
>> (see inline)
>> On 2021-11-03 12:15, Kentaro Hara wrote:
>>
>> The VectorTraits::kCan{Copy,Move,Fill,Compare}... fields are used for
>>> all Vectors though, no? This particular macro doesn't appear to
>>> explicitly define/override any Oilpan-related fields AFAICS.
>>
>>
>> You're right -- thanks for pointing it out :)
>>
>> a) The macros work as a performance optimization for all Vectors. I
>> have no data about the performance numbers though.
>>
>> The traits have a big effect on micro-benchmarks but it's always hard to
>> map that to user observable performance.
>>
>> Furthermore, is it possible to replace the macros with use of standard
>> C++ traits such as std::is_trivial
>> ? It would
>> require auditing current types, and possibly modifying them, but that is
>> something that has to be done anyway before a complete type merge between
>> Blink and
>>
>> /Daniel
>>
>>
>> b) Some of the macros are mandatory to make HeapVector work correctly
>> (e.g., see static_assert here
>> 
>> ).
>>
>> b) does not apply to the geometry types in question. Regarding a), maybe
>> can we just measure performance using benchmarks and see if dropping the
>> macros causes performance regressions? (I hope not.)
>>
>>
>> On Wed, Nov 3, 2021 at 7:19 PM Fredrik Söderquist  wrote:
>>
>>> On Wed, Nov 3, 2021 at 12:29 AM Kentaro Hara 
>>> wrote:
>>>
 The macro matters only for objects stored in HeapVector (i.e.
 Oilpan). So you don't need to export the macro outside Blink :)

>>>
>>> The VectorTraits::kCan{Copy,Move,Fill,Compare}... fields are used for
>>> all Vectors though, no? This particular macro doesn't appear to
>>> explicitly define/override any Oilpan-related fields AFAICS.
>>>
>>>
>>> /fs
>>>
>>>


 2021年11月3日(水) 8:04 Xianzhu Wang :

> Hi,
>
> I'm migrating blink to use gfx geometry types, and noticed
> that WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS is applied to 
> blink
> geometry types. It seems to optimize performance of Vector.
>
> I have the following questions:
>
> 1. For a type defined out of blink, how do we force users to include a
> header delaring WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS(Type)?
> I'm thinking of putting it in vector_traits.h
> ,
> but I would like to know if there are better ways.
>
> 2. Do we have data showing the performance difference with and without
> WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS?
>
> Thanks,
> Xianzhu
>
> --
> 

Re: [blink-dev] Re: Intent to Prototype and Ship: Control character handling in cookies

[Daniel Bratell]

The last thing happening in this thread was that we decided to wait for 
data. What is the current status of those usecounters, have they reached 
the user base now?


/Daniel

On 2021-09-20 07:59, Yoav Weiss wrote:



On Fri, Sep 17, 2021 at 6:36 PM Steven Bingler  
wrote:


Hi Ian and Yoav,

I believe the general guidance now for warning users of some
change is to use DevTools Issues rather than console warnings.
Would using Issues, instead of console warnings, be acceptable to
you? (This would be in addition to the reports.)


I don't believe the API OWNERS have a stand on console warnings vs. 
issues for deprecations. Whatever is the general guidance that will 
make this visible for developers seems good to me, assuming that 
issues are prominent in the UI and manage to grab the median 
developer's attention.



Also, for posterity, it is possible to emit a console warning
starting from EmitCookieWarningsAndMetrics() with a little work.
We used to do just that for SameSite warnings before we
transitioned them to DevTools Issue [1

]
[2

]
(many refactors ago). It looks like most of the necessary
functions still exist, so it shouldn't be too hard to recreate
that functionality if needed.


Thanks,
Steven

On Friday, September 17, 2021 at 8:45:10 AM UTC-7 Andrew Williams
wrote:

Thanks for the feedback Mike, Yoav, and Ian.  I will explore
the feasibility of using CountDeprecation (or something
similar) from the cookie-related code and will report back
once I have an update on this.

-Andrew

On Fri, Sep 10, 2021 at 10:11 AM Ian Clelland
 wrote:

That looks right -- that code path won't get you anywhere
near adding a console message, as far as I can tell, but
you would be able to queue a report that way. Ideally,
we'd have something like deprecation.cc for browser-side
that would handle the UMA as well as formatting the report
body consistently. As a first pass, until we have more
that one browser-generated deprecation report, just
generating and queuing it would work.

On Fri, Sep 10, 2021 at 6:42 AM Yoav Weiss
 wrote:

I may very well be wrong, but it seems like
CookieUtils::EmitCookieWarningsAndMetrics


 has
the right plumbing to reach RenderFrameHost, and from
it, get a ReportingSource


 that
can enable us to send


deprecation reports (even if through a different
mechanism than CountDeprecation).

Ian - thoughts on the above?

On Thu, Sep 9, 2021 at 9:21 PM Mike West
 wrote:

I don't think `countDeprecation` is going to work
here, insofar as that's a Blink-layer concept, and
the network stack isn't going to have an
understanding of page views or use counters or
etc. If we've wired things up such that
deprecation reports can be triggered from the
network stack, lovely, but I'm not sure that's the
case.

Another approach that might be reasonable to
approach might be to roll this out on a
percentage-basis, starting with a substantial
portion of beta, then rolling to stable iff we're
confident in that experience?

This feels like both the right directional and
philosophical thing to do with cookies. I'd like
to see it ship, and a staged rollout might well be
a reasonable way of gaining confidence in our
ability to do so?

-mike


On Thu, Sep 9, 2021 at 1:03 PM Yoav Weiss
   

Re: [blink-dev] Questions about WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS

[Xianzhu Wang]

One data point: the CL
 that
replaces blink::IntPoint (declared with the macro) with gfx::Point was
landed 2 days ago, and I haven't received any performance bug yet. Perhaps
we don't use Vector in performance critical code.

Will try std::is_trivial before converting other types.

On Thu, Nov 4, 2021 at 10:19 AM Daniel Bratell  wrote:

> (see inline)
> On 2021-11-03 12:15, Kentaro Hara wrote:
>
> The VectorTraits::kCan{Copy,Move,Fill,Compare}... fields are used for
>> all Vectors though, no? This particular macro doesn't appear to
>> explicitly define/override any Oilpan-related fields AFAICS.
>
>
> You're right -- thanks for pointing it out :)
>
> a) The macros work as a performance optimization for all Vectors. I
> have no data about the performance numbers though.
>
> The traits have a big effect on micro-benchmarks but it's always hard to
> map that to user observable performance.
>
> Furthermore, is it possible to replace the macros with use of standard C++
> traits such as std::is_trivial
> ? It would
> require auditing current types, and possibly modifying them, but that is
> something that has to be done anyway before a complete type merge between
> Blink and
>
> /Daniel
>
>
> b) Some of the macros are mandatory to make HeapVector work correctly
> (e.g., see static_assert here
> 
> ).
>
> b) does not apply to the geometry types in question. Regarding a), maybe
> can we just measure performance using benchmarks and see if dropping the
> macros causes performance regressions? (I hope not.)
>
>
> On Wed, Nov 3, 2021 at 7:19 PM Fredrik Söderquist  wrote:
>
>> On Wed, Nov 3, 2021 at 12:29 AM Kentaro Hara 
>> wrote:
>>
>>> The macro matters only for objects stored in HeapVector (i.e.
>>> Oilpan). So you don't need to export the macro outside Blink :)
>>>
>>
>> The VectorTraits::kCan{Copy,Move,Fill,Compare}... fields are used for
>> all Vectors though, no? This particular macro doesn't appear to
>> explicitly define/override any Oilpan-related fields AFAICS.
>>
>>
>> /fs
>>
>>
>>>
>>>
>>> 2021年11月3日(水) 8:04 Xianzhu Wang :
>>>
 Hi,

 I'm migrating blink to use gfx geometry types, and noticed
 that WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS is applied to blink
 geometry types. It seems to optimize performance of Vector.

 I have the following questions:

 1. For a type defined out of blink, how do we force users to include a
 header delaring WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS(Type)?
 I'm thinking of putting it in vector_traits.h
 ,
 but I would like to know if there are better ways.

 2. Do we have data showing the performance difference with and without
 WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS?

 Thanks,
 Xianzhu

 --
 You received this message because you are subscribed to the Google
 Groups "blink-dev" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to blink-dev+unsubscr...@chromium.org.
 To view this discussion on the web visit
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADBxriepZahOVJfzQseAyFfkjUPUgLWovXrKUYH54UGY6K2mEw%40mail.gmail.com
 
 .

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jxn-cipEGf%2BU04WVa3UNqLmqmFcX55dWCPy_KK6huAe3A%40mail.gmail.com
>>> 
>>> .
>>>
>>
>
> --
> Kentaro Hara, Tokyo
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jxmhADNpdOCAnq_VbH-R%2BVbhJc%3DvS2CAW4LQv10OukU6w%40mail.gmail.com
> 

Re: [blink-dev] Questions about WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS

[Daniel Bratell]

(see inline)

On 2021-11-03 12:15, Kentaro Hara wrote:


The VectorTraits::kCan{Copy,Move,Fill,Compare}... fields are
used for all Vectors though, no? This particular macro doesn't
appear to explicitly define/override any Oilpan-related fields AFAICS.


You're right -- thanks for pointing it out :)

a) The macros work as a performance optimization for all Vectors. I 
have no data about the performance numbers though.


The traits have a big effect on micro-benchmarks but it's always hard to 
map that to user observable performance.


Furthermore, is it possible to replace the macros with use of standard 
C++ traits such as std::is_trivial 
? It would 
require auditing current types, and possibly modifying them, but that is 
something that has to be done anyway before a complete type merge 
between Blink and


/Daniel


b) Some of the macros are mandatory to make HeapVector work 
correctly (e.g., see static_assert here 
).


b) does not apply to the geometry types in question. Regarding a), 
maybe can we just measure performance using benchmarks and see if 
dropping the macros causes performance regressions? (I hope not.)



On Wed, Nov 3, 2021 at 7:19 PM Fredrik Söderquist  wrote:

On Wed, Nov 3, 2021 at 12:29 AM Kentaro Hara
 wrote:

The macro matters only for objects stored in HeapVector
(i.e. Oilpan). So you don't need to export the macro outside
Blink :)


The VectorTraits::kCan{Copy,Move,Fill,Compare}... fields are
used for all Vectors though, no? This particular macro doesn't
appear to explicitly define/override any Oilpan-related fields AFAICS.


/fs



2021年11月3日(水) 8:04 Xianzhu Wang :

Hi,

I'm migrating blink to use gfx geometry types, and noticed
that WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS is
applied to blink geometry types. It seems to optimize
performance of Vector.

I have the following questions:

1. For a type defined out of blink, how do we force users
to include a header
delaring WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS(Type)?
I'm thinking of putting it in vector_traits.h

,
but I would like to know if there are better ways.

2. Do we have data showing the performance difference with
and without
WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS?

Thanks,
Xianzhu
-- 
You received this message because you are subscribed to

the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADBxriepZahOVJfzQseAyFfkjUPUgLWovXrKUYH54UGY6K2mEw%40mail.gmail.com

.

-- 
You received this message because you are subscribed to the

Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jxn-cipEGf%2BU04WVa3UNqLmqmFcX55dWCPy_KK6huAe3A%40mail.gmail.com

.



--
Kentaro Hara, Tokyo
--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jxmhADNpdOCAnq_VbH-R%2BVbhJc%3DvS2CAW4LQv10OukU6w%40mail.gmail.com 
.


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Add support for Promise to Blobs in clipboard item

['Thomas Steiner' via blink-dev]

On Wed, Nov 3, 2021 at 7:13 PM Anupam Snigdha 
wrote:

> This is a good scenario, but I'm not sure if this can be solved using the
> current design. You probably want a promise to the ClipboardItem? Also, I
> think the MIME type in the Clipboarditem is only useful when we are
> specifying DOMString instead of Blobs, which is currently not supported in
> Chromium. If we create a Blob after the data has been populated, then we
> can probably just use the MIME type from the Blob during the clipboard
> write operation. This feature can be implemented just like the promises to
> blobs without breaking the sites that use ClipboardItem instead of promises
> to ClipboardItem, so we should definitely consider adding this to the async
> clipboard API in the future.
> The promises to Blobs feature unblocks some of the key scenarios in Excel
> online as well as scenarios where a promise to the Blob helps in creating
> the Blob asynchronously without losing the transient user activation delay,
> so I think this feature will still be useful even if we implement promise
> to ClipboardItem.
>

Taking one step back, in my ideal world, Safari would just let me do the
following without expiring the user gesture:

// Works in Chromium, throws in Safari…
const { data, type } = await getDataOfUnknownType();
const blob = new Blob([data], { type });
navigator.clipboard.write([
  new ClipboardItem({
[blob.type]: blob,
  }),
]);

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrLkvjKBj0bqYd2Gj6kHmN6%3DuhkFTnDX-49HseX1f_xd9WA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CORS non-wildcard request-header

[Yutaka Hirano]

(friendly ping)

On Mon, Nov 1, 2021 at 1:57 PM Yutaka Hirano  wrote:

> Thank you for the feedback.
>
> Do you have concrete steps for the investigation in your mind?
>
> On Fri, Oct 29, 2021 at 4:30 AM Mike West  wrote:
>
>> I think it's reasonable for us to dig into the data a little bit to
>> determine whether the 0.04% number quoted above will result in user-facing
>> breakage. Yutaka, is that something you'd be willing to dig into?
>>
>> The direction seems philosophically correct to me, so I'd like to see it
>> ship, but I'd also like to make sure we're not making the web worse for
>> users by doing so.
>>
>> -mike
>>
>>
>> On Thu, Oct 21, 2021 at 12:04 PM Yutaka Hirano 
>> wrote:
>>
>>>
>>>
>>> On Thu, Oct 21, 2021 at 6:25 PM Yoav Weiss 
>>> wrote:
>>>


 On Thu, Oct 21, 2021 at 9:55 AM Yutaka Hirano 
 wrote:

> (The implementation CL
> 
> is under review. This intent is written as if it's landed.)
>
> Contact emailsyhir...@chromium.org
>
> Specification
> https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name
>
> Summary
>
> A CORS non-wildcard request header[1] is an HTTP request header which
> is not covered by the wildcard symbol ("*") in the
> access-control-allow-headers header. "authorization" is the only member of
> CORS non-wildcard request-header. Currently we treat the header as a usual
> header, which is problematic for security reasons. Implement it, and 
> change
> the current behavior. 1:
> https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name
>
>
> Blink componentBlink>SecurityFeature>CORS
> 
>
> TAG reviewNot needed because this implements an existing feature.
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interoperability risk is low because Mozilla and Apple showed an
> intent to implement this behavior. There is some compatibility risk, as 
> the
> use counter[2] shows 0.04% websites would be affected. To mitigate the
> risk, we've shown a deprecation message for a few milestones.
>

 Can you similarly send deprecation reports as well? How long have the
 deprecation messages been in place? Did we see any decline in the numbers?

 We've shown the deprecation message since Chrome 94
>>> 
>>>  whose
>>> beta promotion was on Aug 26 and stable release was on Sep 21.
>>> We use CountDeprecation which sends deprecation reports automatically
>>> IIUC.
>>>
>>> I don't see any decline.
>>>
>>>
 Have we looked into which URLs are triggering this? (and if it's a few
 medium-sized properties or many tiny ones)

>>>
>>> I haven't looked at the data.
>>>
 Did we try outreach?

>>> No.
>>>

 We have an enterprise policy so that administrators can keep the
> existing behavior. We're planning to remove the policy on Chrome 103. 2:
> https://www.chromestatus.com/metrics/feature/popularity#AuthorizationCovered
> ByWildcard
>
>
> Gecko: Positive Firefox showed a positive signal in a private thread.
>
> WebKit: Positive Apple showed a positive signal in a private thread.
>
> Web developers: No signals
>
>
> Debuggability
>
> We'll show a CORS error to the devtools console.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag nameCorsNonWildcardRequestHeadersSupport
>
> Requires code in //chrome?False (or, True only for the enterprise
> policy.)
>
> Tracking bughttps://crbug.com/1176753
>
> Estimated milestones
>
> 97
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5742041264816128
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%40mail.gmail.com
> 
> .
>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to 

Re: [blink-dev] Intent to Extend Origin Trial: Early Hints preload/preconnect during Navigation

[Anne van Kesteren]

On Wed, Nov 3, 2021 at 11:54 PM Kenichi Ishibashi  wrote:
> We plan to start working on the spec issue in this quarter.

That's great to hear, appreciate the update!

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78j0WKHRi7Dz0WryZiQ72G2_gPH6eqpPbryRJHeTBh%3DSCA%40mail.gmail.com.