Re: [blink-dev] Re: Intent to Ship: WebGLContextEvent on Web Workers

[Ken Russell]

Sorry, not sure. The living WebGL specs are hosted at:

https://registry.khronos.org/webgl/specs/latest/1.0/
https://registry.khronos.org/webgl/specs/latest/2.0/

The IDL is actually auto-extracted from the spec so should be easy to
ingest and validate against Blink's.

One other thing to consider is that Blink's IDL might not be exactly
identical to the spec's - for example, Blink uses several extended and
non-standard Web IDL attributes to optimize the calling convention of
certain entry points. I also vaguely recall some issues with overloads that
were legal in Web IDL but needed some hackery to build properly in Blink,
but not sure about this.

-Ken



On Mon, Feb 13, 2023 at 10:18 AM Joshua Bell  wrote:

> Super low priority question:
>
> We've got WPTs and tooling that slurps Web IDL from specs and validates it
> against implementations which in theory should have caught this. This is a
> fairly fragile process (requires spec to be just right, jobs to be
> configured, tests to exist, integration bots to successfully run it,
> failures to get bugs filed, humans to triage, etc) so I'm not surprised
> this was missed, but do you happen to know where in the pipeline we dropped
> the ball in this case?
>
>
>
>
> On Sun, Feb 12, 2023 at 9:35 AM Kenneth Russell  wrote:
>
>> Sorry for the delay replying...this email didn't show up in my Inbox nor
>> Spam folder.
>>
>> The other browsers handle this in the same way. Firefox has supported
>> WebGL on web workers for some time, and Safari had exactly the same IDL bug
>> which they just fixed.
>>
>> -Ken
>>
>>
>> On Wednesday, February 8, 2023 at 9:35:47 AM UTC-7 slightlyoff via
>> Chromestatus wrote:
>>
>>> LGTM1 Do we know if other browsers that support offscreen canvas (Safari
>>> TP, e.g.) handle this the same way? Or are we the first to ship?
>>>
>> --
>> 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/1da41865-85f7-449c-89e2-d000bf509d86n%40chromium.org
>> 
>> .
>>
>

-- 
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/CAMYvS2fgF4Jq4CZ7d9YCNo3DrGo52Etc4H6DtP_6GThEZ9MrCA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Expose Reporting API interfaces to JavaScript

[Rick Byers]

Thanks Ian. Let's continue this discussion off blink-dev to the
blink-api-owners-discuss
thread

.


On Mon, Feb 13, 2023 at 11:56 AM Ian Clelland 
wrote:

> I've been working on the transition to dict, but failed to revert the
> initial exposure, which we believed was unlikely to have any real compat
> issues.
>
> That seems to be wrong, as
> https://bugs.chromium.org/p/chromium/issues/detail?id=1414463 was filed
> recently saying that it breaks an enterprise use case. I'm going to revert
> the original change immediately, but unfortunately we did allow this to
> ship in M110.
>
> I'd appreciate any guidance here from API owners for any
> additional steps to take to mitigate this; my immediate plan is to revert
> and merge back to M111, and propose a merge back to M110 for the next point
> release.
>
> On Fri, Nov 25, 2022 at 1:51 PM Ian Clelland 
> wrote:
>
>>
>>
>> On Fri, Nov 25, 2022 at 12:03 PM Manuel Rego Casasnovas 
>> wrote:
>>
>>> WebKit has been doing some work implementing the Reporting API:
>>> https://bugs.webkit.org/show_bug.cgi?id=189365
>>>
>>> Do we know their plans regarding this topic? Should we ask for signals?
>>>
>>
>> Thanks Rego --
>>
>> The last time I heard, Chris Dumez had been working on an implementation,
>> but it didn't include ReportingObserver. I'll reach out to see if that's
>> changed, and I suppose it can't hurt to file for an official signal, now
>> that they've implemented that as a repository.
>>
>> Ian
>>
>>
>>> Cheers,
>>>   Rego
>>>
>>> On 25/11/2022 15:39, Rick Byers wrote:
>>> > On Fri, Nov 25, 2022 at 9:27 AM Ian Clelland >> > > wrote:
>>> >
>>> >
>>> >
>>> > On Fri, Nov 25, 2022 at 1:54 AM Domenic Denicola
>>> > mailto:dome...@chromium.org>> wrote:
>>> >
>>> >
>>> >
>>> > On Fri, Nov 25, 2022, 14:53 Yoav Weiss >> > > wrote:
>>> >
>>> >
>>> > On Fri, Nov 25, 2022 at 5:50 AM Domenic Denicola
>>> > mailto:dome...@chromium.org>>
>>> wrote:
>>> >
>>> > Note that in the past I've suggested these not be
>>> > interfaces at
>>> > all: https://github.com/w3c/reporting/issues/216
>>> >  . As far
>>> > as I can tell that issue is still open, and it would
>>> > have been better to resolve it by making everything use
>>> > dictionaries (or even just non-dictionary objects, like
>>> > several specs do today) instead of creating new
>>> > interfaces against proposed W3C TAG Design Principles
>>> > >> >.
>>> >
>>> >
>>> > Thanks Domenic. Turning those into dictionaries does sound
>>> > appealing. Let's wait to hear what Ian says.
>>> >
>>> >
>>> >
>>> > Also that there is no spec for several of these
>>> > interfaces (at least CoopAccessViolationReportBody,
>>> > possibly others). So I think there's considerable
>>> > interop risk.
>>> >
>>> >
>>> > That interop risk is orthogonal to whether we expose those
>>> > interfaces or not, right? Not saying it shouldn't be fixed,
>>> > just that the risk exists already.
>>> >
>>> >
>>> > I don't think it's orthogonal. Once the interfaces are exposed,
>>> > they're much easier to depend on the existence of, and given
>>> > that there is no spec for their shape or behavior, such
>>> > dependence seems like an Interop risk.
>>> >
>>> >
>>> > Most of these are spec'd:
>>> > Report: https://w3c.github.io/reporting/#ref-for-dom-report
>>> > 
>>> > ReportBody: https://w3c.github.io/reporting/#reportbody
>>> > 
>>> > CSPViolationReportBody:
>>> https://www.w3.org/TR/CSP3/#cspviolationreportbody <
>>> https://www.w3.org/TR/CSP3/#cspviolationreportbody>
>>> > DeprecationReportBody:
>>> https://wicg.github.io/deprecation-reporting/#deprecationreportbody <
>>> https://wicg.github.io/deprecation-reporting/#deprecationreportbody>
>>> > InterventionReportBody:
>>> https://wicg.github.io/intervention-reporting/#interventionreportbody <
>>> https://wicg.github.io/intervention-reporting/#interventionreportbody>
>>> >
>>> > CoopAccessViolationReportBody and DocumentPolicyViolationReportBody
>>> > are not. CrashReportBody *is*, though not usefully, as it's not
>>> > observable.
>>> >
>>> >
>>> > We definitely shouldn't be exposing interface objects that aren't
>>> > spec'd.  Thanks for catching this Domenic.
>>> >
>>> > I'm definitely not against turning these into WebIDL dictionaries,
>>> > 

Re: [blink-dev] Re: Intent to Ship: WebGLContextEvent on Web Workers

[Joshua Bell]

Super low priority question:

We've got WPTs and tooling that slurps Web IDL from specs and validates it
against implementations which in theory should have caught this. This is a
fairly fragile process (requires spec to be just right, jobs to be
configured, tests to exist, integration bots to successfully run it,
failures to get bugs filed, humans to triage, etc) so I'm not surprised
this was missed, but do you happen to know where in the pipeline we dropped
the ball in this case?




On Sun, Feb 12, 2023 at 9:35 AM Kenneth Russell  wrote:

> Sorry for the delay replying...this email didn't show up in my Inbox nor
> Spam folder.
>
> The other browsers handle this in the same way. Firefox has supported
> WebGL on web workers for some time, and Safari had exactly the same IDL bug
> which they just fixed.
>
> -Ken
>
>
> On Wednesday, February 8, 2023 at 9:35:47 AM UTC-7 slightlyoff via
> Chromestatus wrote:
>
>> LGTM1 Do we know if other browsers that support offscreen canvas (Safari
>> TP, e.g.) handle this the same way? Or are we the first to ship?
>>
> --
> 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/1da41865-85f7-449c-89e2-d000bf509d86n%40chromium.org
> 
> .
>

-- 
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/CAD649j4yUbH0aCd6Ju0NYVoQ%3D1Rm1oqx_LAHdraOewZq1Nk%3DrQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Expose Reporting API interfaces to JavaScript

[Ian Clelland]

I've been working on the transition to dict, but failed to revert the
initial exposure, which we believed was unlikely to have any real compat
issues.

That seems to be wrong, as
https://bugs.chromium.org/p/chromium/issues/detail?id=1414463 was filed
recently saying that it breaks an enterprise use case. I'm going to revert
the original change immediately, but unfortunately we did allow this to
ship in M110.

I'd appreciate any guidance here from API owners for any
additional steps to take to mitigate this; my immediate plan is to revert
and merge back to M111, and propose a merge back to M110 for the next point
release.

On Fri, Nov 25, 2022 at 1:51 PM Ian Clelland  wrote:

>
>
> On Fri, Nov 25, 2022 at 12:03 PM Manuel Rego Casasnovas 
> wrote:
>
>> WebKit has been doing some work implementing the Reporting API:
>> https://bugs.webkit.org/show_bug.cgi?id=189365
>>
>> Do we know their plans regarding this topic? Should we ask for signals?
>>
>
> Thanks Rego --
>
> The last time I heard, Chris Dumez had been working on an implementation,
> but it didn't include ReportingObserver. I'll reach out to see if that's
> changed, and I suppose it can't hurt to file for an official signal, now
> that they've implemented that as a repository.
>
> Ian
>
>
>> Cheers,
>>   Rego
>>
>> On 25/11/2022 15:39, Rick Byers wrote:
>> > On Fri, Nov 25, 2022 at 9:27 AM Ian Clelland > > > wrote:
>> >
>> >
>> >
>> > On Fri, Nov 25, 2022 at 1:54 AM Domenic Denicola
>> > mailto:dome...@chromium.org>> wrote:
>> >
>> >
>> >
>> > On Fri, Nov 25, 2022, 14:53 Yoav Weiss > > > wrote:
>> >
>> >
>> > On Fri, Nov 25, 2022 at 5:50 AM Domenic Denicola
>> > mailto:dome...@chromium.org>> wrote:
>> >
>> > Note that in the past I've suggested these not be
>> > interfaces at
>> > all: https://github.com/w3c/reporting/issues/216
>> >  . As far
>> > as I can tell that issue is still open, and it would
>> > have been better to resolve it by making everything use
>> > dictionaries (or even just non-dictionary objects, like
>> > several specs do today) instead of creating new
>> > interfaces against proposed W3C TAG Design Principles
>> > > >.
>> >
>> >
>> > Thanks Domenic. Turning those into dictionaries does sound
>> > appealing. Let's wait to hear what Ian says.
>> >
>> >
>> >
>> > Also that there is no spec for several of these
>> > interfaces (at least CoopAccessViolationReportBody,
>> > possibly others). So I think there's considerable
>> > interop risk.
>> >
>> >
>> > That interop risk is orthogonal to whether we expose those
>> > interfaces or not, right? Not saying it shouldn't be fixed,
>> > just that the risk exists already.
>> >
>> >
>> > I don't think it's orthogonal. Once the interfaces are exposed,
>> > they're much easier to depend on the existence of, and given
>> > that there is no spec for their shape or behavior, such
>> > dependence seems like an Interop risk.
>> >
>> >
>> > Most of these are spec'd:
>> > Report: https://w3c.github.io/reporting/#ref-for-dom-report
>> > 
>> > ReportBody: https://w3c.github.io/reporting/#reportbody
>> > 
>> > CSPViolationReportBody:
>> https://www.w3.org/TR/CSP3/#cspviolationreportbody <
>> https://www.w3.org/TR/CSP3/#cspviolationreportbody>
>> > DeprecationReportBody:
>> https://wicg.github.io/deprecation-reporting/#deprecationreportbody <
>> https://wicg.github.io/deprecation-reporting/#deprecationreportbody>
>> > InterventionReportBody:
>> https://wicg.github.io/intervention-reporting/#interventionreportbody <
>> https://wicg.github.io/intervention-reporting/#interventionreportbody>
>> >
>> > CoopAccessViolationReportBody and DocumentPolicyViolationReportBody
>> > are not. CrashReportBody *is*, though not usefully, as it's not
>> > observable.
>> >
>> >
>> > We definitely shouldn't be exposing interface objects that aren't
>> > spec'd.  Thanks for catching this Domenic.
>> >
>> > I'm definitely not against turning these into WebIDL dictionaries,
>> > as they don't actually have any behaviour - they're just a
>> > collection of named data. They were originally defined as
>> > interfaces, I believe, in order to spec the constraints on the names
>> > and types of their data members. Using plain objects at the time
>> > would have made that more difficult. As I understand it, WebIDL
>> > dictionaries do not expose any 

Re: [blink-dev] Intent to Ship: URL Standard-compatible IPv4 embedded IPv6 host parser

['Jiacheng Guo' via blink-dev]

The implementation and the feature has been updated with the feature flag
StrictIPv4EmbeddedIPv6AddressParsing.

Thanks for the advice.

On Thu, Feb 9, 2023 at 12:15 AM Yoav Weiss  wrote:

>
>
> On Tue, Feb 7, 2023 at 6:56 AM 'Jiacheng Guo' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails...@google.com
>>
>> ExplainerThis is an implementation of an established standard.
>>
>> Specificationhttps://url.spec.whatwg.org/#concept-ipv6-parser
>>
>> Summary
>>
>> The behavior of parsing IPv4 embedded IPv6 host parser will be updated to
>> strictly follow the web URL standard:
>> https://url.spec.whatwg.org/#concept-ipv6-parser The introduced
>> restrictions on the IPv6 address are: * The embedded IPv4 address shall
>> always consist of 4 parts. Addresses with less than 4 parts like 
>> http://[::1.2]
>> will be no longer valid. * Embedded IPv4 addresses with trailing dots like
>> http://[::1.2.3.4.] will be no longer valid. The feature is a part of
>> the URL interop 2023.
>>
>>
>> Blink componentBlink>Network
>> 
>>
>> TAG reviewNot required for the URL standard.
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> The URL standard is a well-established standard and the fix is a part of
>> the Interop. No interoperability risk is expected. Shortened IPv4 addresses
>> embedded in IPv6 are rarely used. Compatibility risk shall be minimal.
>>
>
> How many such URLs do we see? Any use counters? (or another form of risk
> analysis)
>
>
>>
>>
>> *Gecko*: Shipped/Shipping (
>> https://wpt.fyi/results/url/url-constructor.any.html%3Fexclude%3D) The
>> IPv6 parser in Safari has already forced the check.
>>
>
> You mean Gecko?
>
>
>>
>> *WebKit*: Shipped/Shipping (
>> https://wpt.fyi/results/url/url-constructor.any.html%3Fexclude%3D) The
>> IPv6 parser in Safari has already forced the check.
>>
>> *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
>>
>>
>> Invalid URLs will be reported in devtools.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>> Under https://wpt.fyi/results/url/url-constructor.any.html%3Fexclude%3D
>>
>> Flag name
>> Not under a flag.
>>
>
> You probably want to put such a change behind a base feature flag, to
> enable turning it off in case of unanticipated breakage.
>
>
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1411619
>>
>> Sample links
>> https://chromium-review.googlesource.com/c/chromium/src/+/4206417
>>
>> Estimated milestones
>>
>> M113
>>
>> Anticipated spec changes
>>
>> No spec change
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5184515301965824
>>
>> Links to previous Intent discussions
>>
>> 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/CAJQw1NxUtU8Wns3TYrEQZGQbWQNhNzKm41xYsfv0CKxSO_AngA%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/CAJQw1NyRzX7trcwZH%3Dm4zUaTGN8qOoLaucbGyWFLz1dM6zEN-A%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Mitar]

Hi!

Done: https://bugs.chromium.org/p/chromium/issues/detail?id=1415291


Mitar

On Wed, Nov 2, 2022 at 11:46 PM Mike Taylor  wrote:
>
> Hi Mitar,
>
> This is really good feedback. Would you mind filing a bug at
> crbug.com/new? Feel free to respond here with the link.
>
> thanks,
> Mike
>
> On 11/1/22 11:25 AM, Mitar wrote:
> > Hi!
> >
> > After playing more with link preload header, I have found another
> > issue where it fails flat as a replacement for server push: where
> > response type depends on Accept header (e.g., APIs which can return
> > XML or JSON depending on Accept header, i.e., content negotiation).
> > You cannot really specify what is used as an Accept header with link
> > rel="preload" and as="fetch" and it looks like Chrome always sets
> > Accept: */*, even if you specify type="application/json".
> >
> >
> > Mitar
> >
> > On Sun, Jul 10, 2022 at 8:04 PM Mitar  wrote:
> >> Hi!
> >>
> >> On Sun, Jul 10, 2022 at 4:19 PM Patrick Meenan  
> >> wrote:
> >>> Presumably if you are protecting something behind HTTP Auth then the PUSH 
> >>> is happening AFTER the 401 challenge and the browser has made the 
> >>> follow-on request with the Authorization header.  If not, then the 
> >>> resources aren't actually protected by authorization and PUSH is 
> >>> bypassing the auth.
> >> I am not talking about HTTP Auth, but a simple SPA which fetches JSON
> >> data from REST API using Authorization header. The server-side can
> >> know that after loading the code, SPA will contact the REST API, so
> >> with HTTP2 you can push the JSON data to the client (setting
> >> Authorization header. as an expected header to be used in the request,
> >> and because it knows the logic of SPA it can also know the value of
> >> the Authorization header). This mitigates the question about whether
> >> you should embed this JSON into HTML response or provide it through
> >> API. Because you can push, there is little difference, but it can be
> >> seen as cleaner to separate HTML payload from data payload.
> >>
> >>> In the early-hints case, the 103 should presumably also be after the 
> >>> request has made it past HTTP Auth so any requests for subresources would 
> >>> use the cached credentials,
> >> That works with cookies, but not with REST API which uses bearer token
> >> in Authorization header. Or am I mistaken?
> >>
> >>> Content negotiation works fine for "as" types that have "accept" types 
> >>> associated with them.
> >> There are some issues opened for Chromium around that [1] [2], but
> >> maybe that is just implementation bug?
> >>
> >>> The PUSH case doesn't support custom authorization or content negotiation 
> >>> either.
> >> You can provide Authorization header in request headers in PUSH_PROMISE 
> >> frame?
> >>
> >>> PUSH is going to go away, the only real question is how long it will 
> >>> take, not if enough edge cases are found to keep it.
> >> I think I understand that. But I am trying to understand what are
> >> alternatives for the edge cases I care about. Initially it looked like
> >> Early Hints is the proposed alternative, but it looks like it does not
> >> support all use cases.
> >>
> >> Currently to me it looks like the best bet is to move the bearer token
> >> to Cookie header. That one might be included when doing a preload
> >> through Link header.
> >>
> >> [1] https://bugs.chromium.org/p/chromium/issues/detail?id=962642
> >> [2] https://bugs.chromium.org/p/chromium/issues/detail?id=1072144
> >>
> >>
> >> Mitar
> >>
> >> --
> >> http://mitar.tnode.com/
> >> https://twitter.com/mitar_m
> >
> >
>


-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

-- 
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/CAKLmikP19rmngMvjxC-n4cGrSYbMShXdvTYJzTT0Mi019pJwdg%40mail.gmail.com.