RE: [EXTERNAL] Re: [blink-dev] Re: Intent To Ship: Prevent fixed elements from moving during elastic overscroll.

['Rahul Arakeri' via blink-dev]

The failing tests have now been 
fixed. 
Thanks for the quick review Chris !
Now that this is done, can you please tell me what the process would look like 
to get this ON in stable? I have a CL for 
this but I 
assume you'd want to run experiments first?

Thanks,
Rahul

From: Yoav Weiss 
Sent: Wednesday, June 1, 2022 2:10 PM
To: Chris Harrelson 
Cc: Mike Taylor ; Ben Mathwig 
; Rahul Arakeri ; 
blin...@chromium.org ; inpu...@chromium.org 
; Olga Gerchikov ; Mike Jackson 
(EDGE) ; Ben Mathwig ; 
Diego Gonzalez ; Amanda Baker 
; jsb...@google.com ; Ajay 
Rahatekar ; Hassan Talat 
; wangxianzhu ; Philip 
Rogers ; Robert Flack ; Emilio Cobos 
Alvarez 
Subject: [EXTERNAL] Re: [blink-dev] Re: Intent To Ship: Prevent fixed elements 
from moving during elastic overscroll.

LGTM3

On Wed, Jun 1, 2022 at 11:07 PM Chris Harrelson 
mailto:chris...@chromium.org>> wrote:
Spec 
text.

On Wed, Jun 1, 2022 at 1:13 PM Mike Taylor 
mailto:miketa...@chromium.org>> wrote:
Thanks Chris. LGTM2.

On 6/1/22 1:26 PM, Chris Harrelson wrote:

A spec edit is indeed needed. However, I think it's a one-liner. I pinged the 
editor of the spec just now about it.

LGTM1 to ship; I'll make sure that the spec commit lands via my CSSWG hat.

On Wed, Jun 1, 2022 at 12:45 AM Yoav Weiss 
mailto:yoavwe...@chromium.org>> wrote:
Thanks for the explainer. My question regarding a spec still stands :)
On Friday, May 27, 2022 at 10:49:31 PM UTC+2 Chris Harrelson wrote:
Ah yes! That counts, and saves filing a signal. Thanks Emilio!

On Fri, May 27, 2022 at 1:46 PM Emilio Cobos Álvarez 
mailto:emi...@mozilla.com>> wrote:
On 5/27/22 20:40, Chris Harrelson wrote:
> No. it has to be done via the 
> https://bit.ly/blink-signals
> >
>  process, because otherwise we might
> accidentally misconstrue their true organizational positions.

FWIW in case it saves some time, we're actively working on this in
>.

-- Emilio
--
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/5f816069-432f-b85a-4abc-ada3ea0dc71f%40mozilla.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 Deprecate and Remove: Non-ASCII characters in cookie domain attributes

[Johann Hofmann]

Hi Mike and Yoav, thank you for the guidance.

Regarding public use counters, devtools messaging, reporting and getting
more precise information on domains:
I'm working on getting a devtools deprecation warning in place, and the
other pieces should be easy to integrate from there, according to sbingler.
Happy to report back once that's done.

> What's the deprecation period you had in mind?

Usage is quite low but there's also no particular rush on this, so I was
thinking of a deprecation period of two releases after we get developer
warnings in place, which might happen by M105, so estimated M107.

> Our typical process for getting such signals is
https://bit.ly/blink-signals

Huh! I read that document and interpreted "Statement made through an
Official Standards Process for that implementation" as given since both
Mozilla and Apple voiced their support in the HTTP WG. If this is the case,
asking them to confirm via their standards positions channels feels
somewhat noisy, no?

> At the same time, as you said above, Mozilla is already shipping

the
behavior you want to align on here.

Right, I'll update the status to "Shipping", apologies.

> Can you send a request to webkit-dev, letting them know that we're moving
on that front?

I'm happy to do that, or alternatively ping John on the GitHub issue if you
agree with me that this is preferable (being more targeted and less noisy)
to an email to webkit-dev.

Thanks!


On Fri, Jun 3, 2022 at 3:09 PM Mike Taylor  wrote:

> On 6/3/22 6:42 AM, Yoav Weiss wrote:
>
> What's the deprecation period you had in mind?
>
> Also, from a technical perspective, it might be worthwhile to talk to
> folks that did past cookie related deprecations, to make sure you're
> reusing the same path for reporting them to the devtools. Also also, it'd
> be great if that deprecation would result in Deprecation Reports, if at all
> feasible.
>
> On Fri, Jun 3, 2022 at 12:21 PM Johann Hofmann 
> wrote:
>
>> Contact emails johann...@chromium.org
>>
>> Explainer None
>>
>> Specification
>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#section-5.5
>>
>> Summary
>>
>> To align with the latest specification in RFC 6265bis, Chromium will
>> reject cookies with a "Domain" attribute that contains a non-ASCII
>> character (e.g. Domain=éxample.com 
>> ).
>>
>>
>> Blink component Blink>Network
>> 
>>
>> Motivation
>>
>> Support for IDN domain attributes in cookies has been long unspecified,
>> with Chromium, Safari and Firefox all behaving differently.
>> https://github.com/httpwg/http-extensions/issues/1707 fixes this issue
>> by standardizing Firefox's behavior of rejecting cookies with non-ASCII
>> domain attributes. Since Chromium has previously accepted non-ASCII
>> characters and tried to convert them to normalized punycode for storage, we
>> will now apply stricter rules and require valid ASCII (punycode if
>> applicable) domain attributes.
>>
>>
>> Initial public proposal
>>
>> TAG review
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> There is a general risk of breakage compared to past Chromium versions
>> from rejecting previously accepted cookies, but UMA measurements show the
>> percentage of cookies with non-ASCII characters (including potentially
>> invalid cookies) to be below 0.0001%.
>>
>
> Any public use counters you could share?
> Or is that something we couldn't add due to cookies being processed
> outside the renderer?
>
> Usage is quite low, but it would be good to know if there are any patterns
> that might affect certain locales more than others. Is there any way we can
> get a sample list of domains to spot check?
>
>
>
>> This change improves interoperability by aligning with what Firefox is
>> shipping and what Safari aims to ship as well.
>>
>>
>> *Gecko*: Positive (https://github.com/httpwg/http-extensions/issues/1707)
>>
>> *WebKit*: Positive (https://github.com/httpwg/http-extensions/issues/1707
>> )
>>
>
> Our typical process for getting such signals is
> https://bit.ly/blink-signals
> At the same time, as you said above, Mozilla is already shipping
> 
> the behavior you want to align on here.
> Can you send a request to webkit-dev, letting them know that we're moving
> on that front?
>
>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>>
>> Debuggability
>>
>> TBD
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes
>>
>> Flag name
>>
>> Requires 

[blink-dev] Blink bug status as of 2022-06-06

[tkent]

Title: Blink bug summary




Blink bug status as of 2022-06-06

Component
Open


Slow Triage
Pri-0/1



⭐
No owner
Oldest


Whole Blink16,881(+14)69,887(+69)1,050(-16)1,011(+2)288Jan 2015
Uncategorized8(+1)11(+1)1(+1)2(-1)0Jun 2022
Blink>Accessibility368(+6)1,217(-4)0(-1)32(-1)11Jul 2019
Blink>Animation2541,386(+6)0(-1)12(+1)7Nov 2020
Blink>AppManifest31197231Jan 2020
Blink>AudioOutputDevices9(-1)32(-3)100
Blink>BackgroundFetch40(+1)62(+1)17(+1)22(+1)9Sep 2018
Blink>BackgroundSync1543543Nov 2020
Blink>BatteryStatus953622Nov 2016
Blink>Bindings293(+7)1,012(+12)824(+3)7Apr 2016
Blink>Bluetooth120(-1)574(-1)0(-2)22Jan 2020
Blink>CSS475(-1)3,527(+14)1(-3)1(-1)0May 2022
Blink>Canvas3211,19413(+1)140Jun 2016
Blink>CaptureFromElement2072331Feb 2022
Blink>Compositing2037241(+1)40Dec 2021
Blink>Contacts1127020Apr 2020
Blink>ContentIndexing525110May 2020
Blink>DOM212(+2)920(+6)14(+1)1Mar 2022
Blink>DataTransfer270(+1)1,247(+1)017(+2)4Nov 2017
Blink>DocumentMetadata1123211Feb 2020
Blink>Editing977(-3)3,717(+1)20(+9)126Apr 2020
Blink>EnumerateDevices2691310Feb 2022
Blink>FeaturePolicy471491877Jun 2021
Blink>FencedFrames73(+2)1261622(+2)10May 2021
Blink>FoldableAPIs647000
Blink>Fonts368(-3)1,871(-7)10(+3)3(-1)0Mar 2022
Blink>Forms4372,061(-5)0(-6)30May 2021
Blink>Fullscreen77(+1)262(+1)140Aug 2020
Blink>GamepadAPI112388020Feb 2019
Blink>GarbageCollection153(+3)410(+4)48(+1)3Jan 2020
Blink>Geolocation493121(+1)52May 2018
Blink>Geometry46(-1)145(-2)3(+1)00
Blink>GetDisplayMedia158(+1)534(+5)922(-2)2Jul 2020
Blink>GetUserMedia113(-2)473(-3)17160Jan 2021
Blink>HID41136000
Blink>HTML4932,114(+4)2(-2)22May 2022
Blink>Handwriting55400
Blink>History34(+1)125(+2)110Oct 2021
Blink>HitTesting461871(+1)00
Blink>Identity96(+3)136(+3)19(+1)28(+1)3May 2021
Blink>Image112590(-2)010Feb 2022
Blink>ImageCapture1970(+1)200
Blink>Infra145(+1)440(+2)1500
Blink>Input834(+3)2,813(+5)2(-2)39(+2)20Apr 2019
Blink>InterestCohort1117130Apr 2022
Blink>InterestGroups44(-2)81(-2)23(-3)10Feb 2021
Blink>Internals233679(+2)121(+2)45(-1)21Aug 2017
Blink>_javascript_1,058(+20)2,909(+23)7497(+6)20Aug 2015
Blink>Layout1,018(-9)5,664(-3)11(+1)224Aug 2021
Blink>LazyLoad41181(+1)000
Blink>Loader5132,293(-2)3(-4)19(-1)1Feb 2017
Blink>Managed11000
Blink>MathML23343211Jun 2020
Blink>Media891(+7)3,138(+12)81(-2)97(-1)33Aug 2015
Blink>MediaRecording47259(+1)411Feb 2021
Blink>MediaStream91441(+2)18(-1)8(+1)1Feb 2021
Blink>MemoryAllocator181(-1)601(-2)7(+2)432Sep 2015
Blink>Messaging35(-1)132(-2)208(-1)4Feb 2017
Blink>NFC635000
Blink>Network442(-5)2,177(-3)9(-1)40(-3)9Aug 2015
Blink>PageLifecycle612292721Aug 2017
Blink>Paint665(-5)2,261(+5)5(+4)15(+1)0Jul 2021
Blink>Payments145(-2)391(-2)26(-4)0Oct 2019
Blink>PerformanceAPIs185(-1)700(+6)24(+1)1Apr 2022
Blink>PermissionsAPI36(-1)143(-5)1320Oct 2021
Blink>Portals134(+1)388(+2)11138Mar 2020
Blink>PresentationAPI40130020May 2019
Blink>Previews22000
Blink>PrivateAggregation1012000
Blink>PushAPI29125521Jul 2021
Blink>ReportingObserver716010Aug 2021
Blink>SVG320(-1)1,864(-3)02(+1)2Feb 2022
Blink>SavePage111732(+1)81(-1)63Jan 2015
Blink>Scheduling2411,849105(-1)121Oct 2017
Blink>Screen23(+2)54(+3)020Apr 2022
Blink>ScreenOrientation277219(+1)22Feb 2021
Blink>Scroll755(+5)2,668(+40)0(-2)42(+1)25Dec 2019
Blink>SecurityFeature548(+7)2,351(+27)0(-5)38(+4)13Sep 2017
Blink>Sensor25145010Apr 2020
Blink>Serial28134(-1)010Jun 2021
Blink>ServiceWorker316(-1)1,696(+2)3(-6)40Sep 2021
Blink>ShapeDetection23100021Jun 2019
Blink>Speech114(+1)522(+1)8873Sep 2019
Blink>Storage598(-12)3,394(-16)2(+2)56(-2)15Sep 2015
Blink>TextAutosize25239000
Blink>TextEncoding2799833Jul 2021
Blink>TopicsAPI29020Jan 2022
Blink>URLPattern34000
Blink>USB361820(-2)20Jan 2021
Blink>Vibration921900
Blink>ViewSource18162(+1)000
Blink>WakeLock748000
Blink>WebAudio153680(+2)2(-12)7(+1)1Oct 2020
Blink>WebAuthentication115(+2)345(+10)25204Jan 2020
Blink>WebCrypto22(-1)57(-3)140(-1)0
Blink>WebFonts28122100
Blink>WebGL648(-2)2,143(-5)4(+2)22(-1)1Jun 2020
Blink>WebGPU116(-9)328(-27)4(+1)13(-5)1May 2020
Blink>WebHD12000
Blink>WebMIDI26127320Nov 2016
Blink>WebML819500
Blink>WebOTP37(+1)163(+5)1330Sep 2020
Blink>WebRTC496(+8)2,710(-12)27(+1)53(+2)9Feb 2018
Blink>WebShare50257621Aug 2021
Blink>WebXR102(-3)407(-6)02(-1)0Sep 2019
Blink>WindowDialog64577010Mar 2020
Blink>Workers156(-1)822(-1)0(-2)00
Blink>XML3316100(-2)0



A value is the number of bugs in a component and its sub-components.
e.g. The 'Blink>Layout' row contains all of bugs in sub-components of
Blink>Layout in addition to Blink>Layout bugs.
The data was fetched with a permission of a general @google.com account.
It takes account of non-public bugs, but doesn't have the owner field and
the open date field of Restrict-View bugs.
Links from delta parts in the 'Open' columns don't represent
anchor numbers precisely because a query depends on the currnet date and
it doesn't contain issues of which component was changed






-- 
You received this message because you are subscribed to the Google Groups "blink-dev"