Re: [blink-dev] Intent to Extend Experiment: Declarative Link Capturing for PWAs

2021-11-17 Thread Alan Cutter
Friendly ping. On Thursday, 11 November 2021 at 7:11:49 pm UTC+11 Alan Cutter wrote: > Request to extend M97 experiment end date to avoid breaking sites while > transitioning to the new launch_handler > API. > > - The launch_handl

[blink-dev] Intent to Prototype: 'blocking=rendering' attribute on scripts and link resources

2021-11-17 Thread Xiaocheng Hu
Contact emails xiaoche...@chromium.org Explainer https://gist.github.com/xiaochengh/fae2b549b3d37454beeb9028a829f4bd#explainer Specification https://gist.github.com/xiaochengh/fae2b549b3d37454beeb9028a829f4bd Summary This feature allows putting 'blocking=render' as an attribute and value to a

Re: [blink-dev] HTTP return code of iframe?

2021-11-17 Thread K. Moon
There's no generic way to do this, as it would leak information. I don't think this route is worth exploring. On Wed, Nov 17, 2021, 11:44 AM Tibor Goldschwendt wrote: > We explored postMessages for a bit, too. IIUC, this would only solve the > success case properly though. But how do we know the

Re: [blink-dev] Intent to Ship: Remove font-family -webkit-standard

2021-11-17 Thread Mike Taylor
On 11/17/21 6:02 AM, Frédéric Wang wrote: I started to poke through https://github.com/search?p=5&q=%22-webkit-standard%22&type=Code out of curiosity and a few things stand out: 1) Some tools used for archiving / exports appear: Evernote: https://github.com/karshih/Notes/blob/edf2d8658db89

Re: [blink-dev] HTTP return code of iframe?

2021-11-17 Thread 'Tibor Goldschwendt' via blink-dev
I only need to know if the iframe load failed – either because of a network error or because of an HTTP status code >= 400; the latter being the more prevalent case. I don't need to know why the iframe load failed. In my testing I managed to receive the load event in both error and success case

Re: [blink-dev] HTTP return code of iframe?

2021-11-17 Thread Tibor Goldschwendt
We explored postMessages for a bit, too. IIUC, this would only solve the success case properly though. But how do we know the iframe is broken? Not receiving the postMessage could also mean the iframe hasn't completed loading yet. On Wed, Nov 17, 2021 at 11:34 AM Domenic Denicola wrote: > The "e

Re: [blink-dev] HTTP return code of iframe?

2021-11-17 Thread Domenic Denicola
The "error" event does not fire on iframes though, precisely because we don't want to leak information cross-origin. Pages generally deal with broken iframes, in cases where they need to, by noticing that the iframe has not sent them the message they expect. (Via parent.postMessage() from inside t

Re: [blink-dev] HTTP return code of iframe?

2021-11-17 Thread Daniel Cheng
The iframe element supports "load" and "error event listeners. Is the exact HTTP error needed? Or does the feature just need to know if it succeed or not? Daniel On Wed, 17 Nov 2021 at 11:19, Tibor Goldschwendt wrote: > +Nasko Oskov > > Thanks, Kahmy. Adding custom code in the browser process

Re: [blink-dev] HTTP return code of iframe?

2021-11-17 Thread Tibor Goldschwendt
+Nasko Oskov Thanks, Kahmy. Adding custom code in the browser process is another avenue I'm exploring. Generally though, how do pages deal with broken iframes? On Wed, Nov 17, 2021 at 6:39 AM K. Moon wrote: > This would violate the same-origin policy, so I don't think you can do > this within

Re: [blink-dev] Intent to Ship: Window Controls Overlay for Installed Desktop Web Apps

2021-11-17 Thread Diego González
Hola, See the updated spec here: https://wicg.github.io/window-controls-overlay. Thanks On Monday, 15 November 2021 at 17:00:34 UTC Ajay Rahatekar wrote: > cc: ajayra...@google.com > > On Monday, November 15, 2021 at 8:53:37 AM UTC-8 Diego González wrote: > >> Hola Yoav, I am looking at makin

Re: [blink-dev] HTTP return code of iframe?

2021-11-17 Thread K. Moon
This would violate the same-origin policy, so I don't think you can do this within Blink, but given this is a chrome: page, maybe you could add some code in the browser to give this information to you. On Tue, Nov 16, 2021, 4:40 PM Tibor Goldschwendt wrote: > Hi Blink Dev! > > Is there any way t

Re: [blink-dev] BlinkOn 15 is Today and Tomorrow

2021-11-17 Thread 'Thomas Steiner' via blink-dev
> > It looks like the talks from yesterday are already in the usual YouTube > channel: > https://www.youtube.com/playlist?list=PL9ioqAuyl6UL_1DiG1tPRHbGJlGQ_gQJW Oh, nice! I looked on the event platform and it said there were no recorded sessions. Thanks for the link! -- You received this messa

Re: [blink-dev] BlinkOn 15 is Today and Tomorrow

2021-11-17 Thread Manuel Rego Casasnovas
On 17/11/2021 11:38, 'Thomas Steiner' via blink-dev wrote: > Does the event platform publish to YouTube in the background? If so, > does anyone have the unlisted livestream links so I could follow up? Thanks! It looks like the talks from yesterday are already in the usual YouTube channel: https

Re: [blink-dev] Intent to Ship: Remove font-family -webkit-standard

2021-11-17 Thread Frédéric Wang
I started to poke through https://github.com/search?p=5&q=%22-webkit-standard%22&type=Code out of curiosity and a few things stand out: 1) Some tools used for archiving / exports appear: Evernote: https://github.com/karshih/Notes/blob/edf2d8658db898a4d993a22db62722e2d8e23ee8/accounts/www.ever

Re: [blink-dev] Intent to Ship: Supports keyword format in @font-face src descriptor

2021-11-17 Thread Dominik Röttsches
Hi Eric, in the context of enabling COLRv1 and the discussion on feature detection in CSS WG issue #6520 we need a) implementation changes to the src: descriptor and b) we need a @supports font-technology function, which was recently defined in the

Re: [blink-dev] BlinkOn 15 is Today and Tomorrow

2021-11-17 Thread 'Thomas Steiner' via blink-dev
Does the event platform publish to YouTube in the background? If so, does anyone have the unlisted livestream links so I could follow up? Thanks! On Tue, Nov 16, 2021 at 7:04 PM Vincent Scheib wrote: > https://www.chromium.org/events/blinkon-15 > > -- > You received this message because you are