Re: [blink-dev] Intent to Ship: Auto range support for font descriptors inside @font-face rule

[Yoav Weiss]

On Tue, Oct 18, 2022 at 5:27 PM 'Munira Tursunova' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> moon...@chromium.org, dr...@chromium.org
>
> Explainer
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=973194
>

That's restricted to Google folks, so not great as a public explainer. It's
also not very descriptive.
Can you write a few words inline about what how those ranges are used, what
developers typically do with them, and what are the implications on the
font download (if any)?


> https://drafts.csswg.org/css-fonts/#font-prop-desc
>
> Specification
>
> https://drafts.csswg.org/css-fonts/#font-prop-desc
>
> Summary
>
> Auto range support for variable fonts in 'font-weight', 'font-style' and
> 'font-stretch' descriptors inside '@font-face' rule.
>
> Motivation
>
> Variable fonts provide users the opportunity to choose how heavy or
> slanted or wide the typeface should be, rather than having those decided by
> the type designer.
>
> For variable fonts, in Chrome, it is required to add the supported range
> for 'font-weight', 'font-style' and 'font-stretch' descriptors inside
> @font-face rule, otherwise variable fonts would either be synthesizing bold
> faces or the text will appear as normal.
>
> In CSS WG issue 2485  it
> was resolved to add a default keyword 'auto'.
>
> Blink component
>
> Blink>Fonts
> 
>
> Search tags
>
> auto range , variable
> fonts ,
> font-weight ,
> font-style ,
> font-stretch 
>
> TAG reviewAlready shipped in other browsers, see below, no TAG review
> required.
>
> TAG review status
>
> Not applicable, existing standard, shipped in other UAs
>
> Risks
>
> Interoperability and Compatibility
>
> Low, feature already shipped in Firefox and Safari.
>
> Gecko: Shipped/Shipping Variable fonts work without specifying the
> supported range, however the browser does not yet support auto value
> parsing.
>

Is what they are shipping interoperable with what you want to ship here?


> Tests for 'font-stretch' and 'font-weight' descriptors are passing.
> Although the 'font-style' descriptor has a bug when it is synthetically
> obliquing out of the supported range.
>
> WebKit: Shipped/Shipping Variable fonts work without specifying the
> supported range, however the browser does not yet support auto value
> parsing. Tests for 'font-stretch' descriptors are passing. Although the
> 'font-weight' descriptor works without specifying the range, there are some
> pixel differences in the test results. 'font-style' descriptor looks like
> it is synthesizing oblique faces.
>
> Web developers: Positive (
> https://bugs.chromium.org/p/chromium/issues/detail?id=973194)
>
> Content authors have been running into this counterintuitive problem of
> not seeing their variable fonts working without explicitly specifying the
> range. A UX engineer at Google, for example, faced this issue when she
> wasn’t able to use font-weight property without specifying the supported
> range for the variable font. That’s what she said: “It would be useful if
> the variable fonts behavior was always consistent with normal fonts, where
> you don't need to declare font-weight within @font-face”
>
> Activation
>
> None expected; Feature already implemented in other browsers.
>
>
> Debuggability
>
> Same as existing descriptors, @font-face rules inspectable 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. ‘auto’ keyword parsing tests for each descriptor; Added WPT tests for
> variable and static fonts for ‘font-weight’, ‘font-style’ and
> ‘font-stretch’ descriptors.
>
> Flag name
>
> CSSFontFaceAutoVariableRange
>
> Requires code in //chrome?
>
> No
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=973194
>
> Estimated milestones109
> Anticipated spec changes
>
> None expected
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5173271981457408
>
> --
> 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/CAAO7W_C2%3DsXW53%2B08RULQvLXfWLqmxfmQ5ix%3D%3DV8qXhtbGhgAg%40mail.gmail.com
> 

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain

[Yoav Weiss]

Thanks for the detailed report!!

It's great that we've managed to bring the usage down, but 0.25% is still
too high for my comfort levels.
Taking a manual survey of the major users seems like the right approach. I
wonder if you could, on top of the top sites, also run a random survey of
the bottom half of usage, to get a sense of breakage there?


On Mon, Oct 17, 2022 at 4:39 PM Daniel Vogelheim 
wrote:

> Hello all,
>
> It's been a while and 109 is coming up. As I'm preparing the
> intent-to-ship for 109, I'd like to post an update on how the deprecation
> is going:
>
> Current usage: Since announcing the deprecation, usage of
> document.domain-enabled accesses have dropped by about 50%.
>
> - Feature stats: DocumentDomainEnabledCrossOriginAccess
> 
>
> - Note that this *includes* usage when an Origin-Agent-Cluster header is
> explicitly set, which is sustainable use that is not affected by the
> deprecation.
>
> - CrossOriginAccessBasedOnDocumentDomain
>  is
> usage of document.domain enabled access, but only when based on the
> Origin-Agent-Cluster's default (which is what this intent wants to change.)
> This graph has the correct numbers for this intent; but makes long-term
> trends harder to see because we only introduced the use counter *during*
> the deprecation period.
>
> - So basically, usage has dropped form ~0.5% of page views (
> DocumentDomainEnabledCrossOriginAccess
>  @ Nov
> '21) to about ~0.25% of page views (CrossOriginAccessBasedOnDocumentDomain
>  @
> Sept '22)
>
> When gathering the data for this post, I double-checked on a particular,
> well-known media site that we had contacted about the deprecation during
> the past months. I was surprised to notice that despite our outreach and
> communication, they *still* use document.domain and document.domain
> facilitated cross-origin access. But when taking a closer look, an
> interesting find emerged: They are using document.domain setting to enable
> auto-play of their media player, which is hosted on a separate domain. Our
> advice was to use the 'autoplay' permission policy with permission
> delegation instead. They are indeed doing so, but *in addition* to
> document.domain setting. In other words, they opted for a conservative
> implementation strategy where they auto-play their frame with two different
> methods. When I load their page with document.domain setting disabled, it
> works fine. That's a fine implementation strategy, but unfortunately it
> mucks up our statistics since our use counters cannot know whether other
> code exists to compensate for a failed document.domain facilitated access.
>
> When discussing this finding with another engineer, he suggested that
> we're really interested in user-visible web breakage. Since I don't know
> how to measure that directly, I manually looked at all top users of
> document.domain and loaded each page with/without document.domain setting
> to see if I could spot any difference. Document.domain usage - like the web
> in general - is quite "top heavy": 9 sites account for about 50% of all
> remaining dd usage.
>
> - 7 sites work without any discernible difference. (Caveat: Many use
> languages I do not understand, which makes it difficult to spot subtle
> differences in content. But to me, the sites looked and used the same,
> regardless of document.domain setting. Caveat 2: One site requires a login,
> so I could only really test the login page rather than their core
> functionality.)
>
> - 1 site worked just the same, except for a pair of very extra fancy ad
> frames that "framed" the main content left and right. The main content,
> including in-page ads, seemed just fine, but the fancy ad frames were
> missing.
>
> - 1 site was clearly missing content.
>
> For both of the last two, the console showed uncaught DOM exceptions for a
> failed cross-domain access. What I suspect happens in the first case is
> that during construction of the fancy ad frames an exception is thrown and
> hence the frames aren't inserted in the page. In the second case something
> similar happens, but when building up the main content. Or maybe before
> building up the main content. Thus, that part of the main content is
> missing.
>
> (We don't like broken web pages, so we reached out separately to the
> owners of that last page on Friday. Their support has promised to put us in
> contact with one of their developers which, as of this writing, hasn't
> happened yet.)
>
>
> On Fri, Jan 21, 2022 at 9:23 PM Yoav Weiss  wrote:
>
>> LGTM1 to deprecate under the following conditions:
>>
>>- As discussed, a 6 months deprecation period, as well as broad-scope
>>and targeted outreach, that would hopefully bring usage down.
>>- A 

Re: [blink-dev] Intent to Ship: Conditional Focus

[Yoav Weiss]

On Thu, Oct 13, 2022 at 10:24 PM 'Elad Alon' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailselada...@chromium.org
>
> Explainerhttps://github.com/WICG/conditional-focus/blob/main/README.md
>
> Specification
> https://w3c.github.io/mediacapture-screen-share/#dom-capturecontroller-setfocusbehavior
>
> Design docs
> https://docs.google.com/document/d/1LHJRt-ry9hwzFTbPxKrmD0VvtEFEU6lvqsD7k6wwGKM
> (Note that this reflects the old API shape. There is no substantive
> difference; the same functionality is simply exposed on a different surface
> now.)
>
> Summary
>
> Extend the getDisplayMedia() API by adding a CaptureController object
> which can be passed in as a parameter. This object exposes a
> setFocusBehavior() method. By calling this method, an app can control
> whether the captured tab/window is focused when capture starts, or whether
> the capturing page should retain focus.
>
>
> Blink componentBlink
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/679
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/697) Jan-Ivar
> Bruaroey from Mozilla, and Youenn Fablet from Apple, have both collaborated
> with us closely in shaping the PRs of this API. They have then approved
> merging the PRs into w3c/mediacapture-screen-share. This is implicit
> support, so I'd consider it POSITIVE even though, as of the time of this
> writing, the official request for position has not yet been answered.
>
> *WebKit*: Positive (
> https://github.com/WebKit/standards-positions/issues/73) Jan-Ivar
> Bruaroey from Mozilla, and Youenn Fablet from Apple, have both collaborated
> with us closely in shaping the PRs of this API. They have then approved
> merging the PRs into w3c/mediacapture-screen-share. This is implicit
> support, so I'd consider it POSITIVE even though, as of the time of this
> writing, the official request for position has not yet been answered.
>
> *Web developers*: Positive (https://github.com/WICG/proposals/issues/37)
> Support from Web developers inside+outside of Google.
>
> *Other signals*:
>
> Ergonomics
>
> N/A
>
>
> Activation
>
> N/A
>
>
> Security
>
> See design-doc.
>
>
> WebView application risks
>
> N/A
>
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?No
>
> Supported on all Desktop platforms.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>

Any particular reason?


>
>
> Flag nameConditionalFocus
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1215480
>
> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1214483
>
> Sample linkshttps://wicg.github.io/conditional-focus/demo
>
> Estimated milestones
>Expected full-ship milestone: 109
> OriginTrial desktop last 108 (or up to and including 111 if delays are
> encountered; already approved
> 
> .)
> OriginTrial desktop first 102
>
> Anticipated spec changes
>
> N/A
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5646614535340032
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/lbuqOGx07xY
> Intent to Experiment:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/I4RE2pbocTg
> Intent to Extend Experiment:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/CLmSojRQHoc/m/X-AroW-UAQAJ
>
>
> 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/CAMO6jDNmAMDVMxEKQRgVtHv7Cx_3%2BiHYWOCBi-VZ9%3DWqX6t5pw%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/CAL5BFfVhu9kZLSG8F%2BRxvhdVyF2eRqW7k30uN%2BjC7rMUaH_JgA%40mail.gmail.com.

Re: [blink-dev] Re: FYI Privacy Sandbox Ads APIs origin trial

[Josh Karlin]

Correction, the Private Aggregation API is available in canary/dev.

Josh

On Tue, Oct 18, 2022 at 4:15 PM Josh Karlin  wrote:

> Hey folks. The Private Aggregation API
>  is
> now available within Shared Storage and FLEDGE worklets on canary/dev/beta
> at 50%.
>
> Best,
>
> Josh
>
> On Wed, Sep 21, 2022 at 11:59 AM Paul Jensen 
> wrote:
>
>> Hi folks. In regards to the FLEDGE bug and subsequent ramp down of FLEDGE
>> for Chrome Stable, I wanted to bring your attention to a post from the
>> FLEDGE API Announce list yesterday
>> 
>>  that
>> impacts experimenters:
>>
>> "We fixed the bug and are ramping the origin trial back up on desktop and
>> Android, to make FLEDGE available for 1% of Stable users, on pages that
>> provide a valid trial token, as the Topics and Attribution Reporting APIs
>> are now."
>>
>> Paul
>>
>> On Friday, September 9, 2022 at 3:01:55 PM UTC-4 Josh Karlin wrote:
>>
>>> Topics, Fenced Frames, and Attribution Reporting are now ramping up to
>>> 1% on Android stable.
>>>
>>> Josh
>>>
>>> On Thu, Sep 1, 2022 at 2:01 PM Josh Karlin  wrote:
>>>
 Hi folks. I wanted to bring your attention to a post from FLEDGE API
 Announce
 
 list today that impacts experimenters:

 "We've discovered a bug in FLEDGE, so we are ramping down FLEDGE for
 Chrome Stable in the Privacy Sandbox Relevance and Measurement origin
 trial
 .
 Other APIs in the trial are unaffected.

 We've identified a fix for the bug and are working to validate it and
 re-enable the origin trial for FLEDGE with the fix soon (roughly two weeks
 from now if all goes well)."

 Best,

 Josh

 On Wed, Aug 24, 2022 at 8:29 AM Josh Karlin 
 wrote:

> Hey folks. Shared Storage's
>  
> selectURL()
> operation will begin to ramp up on canary/dev/beta in the next 24 hours at
> 50%. Aggregate reporting is forthcoming.
>
> Best,
>
> Josh
>
> On Thu, Aug 11, 2022 at 11:39 AM Josh Karlin 
> wrote:
>
>> We've been asked if canary/dev/beta will continue to hold at 50%
>> while stable is at 1%. Yes, the pre-stable channels will continue at 50%.
>>
>> On Wed, Aug 10, 2022 at 5:45 PM Josh Karlin 
>> wrote:
>>
>>> I should clarify that this stable push to m104 is for desktop only.
>>> Mobile is coming later.
>>>
>>> On Wed, Aug 10, 2022, 1:35 PM Josh Karlin 
>>> wrote:
>>>
 The unified origin trial will start ramping up to 1% of M104 Stable
 traffic tomorrow, August 11th.

 On Fri, Jun 3, 2022 at 1:22 PM Josh Karlin 
 wrote:

> The unified origin trial is also now at 50% of Chrome Beta for the
> Topics API as of May 27th.
>
>
> On Mon, May 23, 2022 at 6:23 PM John Delaney <
> johni...@chromium.org> wrote:
>
>> The unified origin trial for the Privacy Sandbox Ads APIs is now
>> at 50% of Chrome Beta population for FLEDGE and Attribution 
>> Reporting.  A
>> stability issue was identified and fixed in Topics code, and we 
>> expect the
>> API to be available to 50% of Chrome Canary and Chrome Dev by the 
>> end of
>> today, and 50% of Beta users within a few days.  Reports from early 
>> testers
>> help us identify and address such technical issues. This is to be 
>> expected
>> in the early days of origin trials and the reason we proceed 
>> gradually.
>>
>> We expect the origin trial to remain in Beta for at least a few
>> more weeks to help us identify and address any additional issues.  
>> Once
>> we’re confident we’ve fixed any major open issues, we will provide an
>> update with a timeline for moving the origin trial to Chrome Stable 
>> for
>> expanded testing with a larger volume of traffic.  To get support, 
>> report
>> issues, or provide feedback please see the resources for Topics
>> 
>> , FLEDGE
>> 
>>  and Attribution Reporting
>> 
>> .
>> On Thursday, April 28, 2022 at 4:18:05 PM UTC-4 John Delaney
>> wrote:
>>
>>> The unified origin trial for 

Re: [blink-dev] Re: FYI Privacy Sandbox Ads APIs origin trial

[Josh Karlin]

Hey folks. The Private Aggregation API
 is
now available within Shared Storage and FLEDGE worklets on canary/dev/beta
at 50%.

Best,

Josh

On Wed, Sep 21, 2022 at 11:59 AM Paul Jensen 
wrote:

> Hi folks. In regards to the FLEDGE bug and subsequent ramp down of FLEDGE
> for Chrome Stable, I wanted to bring your attention to a post from the
> FLEDGE API Announce list yesterday
> 
>  that
> impacts experimenters:
>
> "We fixed the bug and are ramping the origin trial back up on desktop and
> Android, to make FLEDGE available for 1% of Stable users, on pages that
> provide a valid trial token, as the Topics and Attribution Reporting APIs
> are now."
>
> Paul
>
> On Friday, September 9, 2022 at 3:01:55 PM UTC-4 Josh Karlin wrote:
>
>> Topics, Fenced Frames, and Attribution Reporting are now ramping up to 1%
>> on Android stable.
>>
>> Josh
>>
>> On Thu, Sep 1, 2022 at 2:01 PM Josh Karlin  wrote:
>>
>>> Hi folks. I wanted to bring your attention to a post from FLEDGE API
>>> Announce
>>> 
>>> list today that impacts experimenters:
>>>
>>> "We've discovered a bug in FLEDGE, so we are ramping down FLEDGE for
>>> Chrome Stable in the Privacy Sandbox Relevance and Measurement origin
>>> trial
>>> .
>>> Other APIs in the trial are unaffected.
>>>
>>> We've identified a fix for the bug and are working to validate it and
>>> re-enable the origin trial for FLEDGE with the fix soon (roughly two weeks
>>> from now if all goes well)."
>>>
>>> Best,
>>>
>>> Josh
>>>
>>> On Wed, Aug 24, 2022 at 8:29 AM Josh Karlin 
>>> wrote:
>>>
 Hey folks. Shared Storage's
  
 selectURL()
 operation will begin to ramp up on canary/dev/beta in the next 24 hours at
 50%. Aggregate reporting is forthcoming.

 Best,

 Josh

 On Thu, Aug 11, 2022 at 11:39 AM Josh Karlin 
 wrote:

> We've been asked if canary/dev/beta will continue to hold at 50% while
> stable is at 1%. Yes, the pre-stable channels will continue at 50%.
>
> On Wed, Aug 10, 2022 at 5:45 PM Josh Karlin 
> wrote:
>
>> I should clarify that this stable push to m104 is for desktop only.
>> Mobile is coming later.
>>
>> On Wed, Aug 10, 2022, 1:35 PM Josh Karlin 
>> wrote:
>>
>>> The unified origin trial will start ramping up to 1% of M104 Stable
>>> traffic tomorrow, August 11th.
>>>
>>> On Fri, Jun 3, 2022 at 1:22 PM Josh Karlin 
>>> wrote:
>>>
 The unified origin trial is also now at 50% of Chrome Beta for the
 Topics API as of May 27th.


 On Mon, May 23, 2022 at 6:23 PM John Delaney 
 wrote:

> The unified origin trial for the Privacy Sandbox Ads APIs is now
> at 50% of Chrome Beta population for FLEDGE and Attribution 
> Reporting.  A
> stability issue was identified and fixed in Topics code, and we 
> expect the
> API to be available to 50% of Chrome Canary and Chrome Dev by the end 
> of
> today, and 50% of Beta users within a few days.  Reports from early 
> testers
> help us identify and address such technical issues. This is to be 
> expected
> in the early days of origin trials and the reason we proceed 
> gradually.
>
> We expect the origin trial to remain in Beta for at least a few
> more weeks to help us identify and address any additional issues.  
> Once
> we’re confident we’ve fixed any major open issues, we will provide an
> update with a timeline for moving the origin trial to Chrome Stable 
> for
> expanded testing with a larger volume of traffic.  To get support, 
> report
> issues, or provide feedback please see the resources for Topics
> 
> , FLEDGE
> 
>  and Attribution Reporting
> 
> .
> On Thursday, April 28, 2022 at 4:18:05 PM UTC-4 John Delaney wrote:
>
>> The unified origin trial for the Privacy Sandbox relevance and
>> measurement APIs (Topics, FLEDGE and Attribution Reporting) is 
>> available in
>> Chrome Beta.  We plan to ramp up to approximately 50% of the Chrome 
>> Beta
>> population within the next two weeks.  We will continue to 

Re: [blink-dev] RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome

[John Abd-El-Malek]

Hi Sasha, I got looped in to a code review and I had a few questions:

1) Can we avoid modifying the Cookie header, and only modify "x-ms-"
headers?
2) Can this be scoped to just frame requests, e.g. only for requests to
fetch the html for main frames and subframes and not subresource requests
like images, XHR, JS, CSS etc. requests? Igor had tried this locally and it
seemed to work.

If we can do the above, either right away or with small changes to your
server, we can simplify the implementation in Chrome. This in turn would
help us reach a lower maintenance burden while still being performant.

Thanks

On Thu, Aug 11, 2022 at 4:30 PM 'Sasha Tokarev' via blink-dev <
blink-dev@chromium.org> wrote:

> With respect to credential mode “omit” it is fine not send those headers,
> if the other mode will allow it.
>
>
>
> We use sandboxed iframes in out authentication libs, but we set
> “allow-same-origin” token to be able to use cookies.
>
>
>
>
> https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/6756b300c5696ad4890f1f7f27de69f6941a71e7/lib/msal-browser/src/interaction_handler/SilentHandler.ts#L143
>
>
>
> We fine if “allow-same-origin” will relax restriction of not sending
> cookies.
>
>
>
>
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox
>
>
>
> Thank you,
>
> Sasha
>
>
>
> *From:* Matt Menke 
> *Sent:* Thursday, August 11, 2022 3:09 PM
> *To:* Sasha Tokarev 
> *Cc:* blink-dev ; Owen Min ;
> Greg Thompson ; Ryan Sleevi ;
> Adam Langley 
> *Subject:* Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome
>
>
>
>
>
>
>
> On Thu, Aug 11, 2022 at 5:43 PM Sasha Tokarev 
> wrote:
>
> Hi Matt,
>
>
>
> I apologize for not being able to respond, I was on vacation, but now I’m
> back. However, before the vacation, I had planned to ping this thread, as
> we are getting more and more feedback that the extension model is not
> working for various reasons, and the users do not have sufficient help to
> resolve it. In many cases the extension is either accidentally dismissed,
> or partially works (has icon on tab, but the rest functionality is
> blocked). In such cases we suggest to escalate to Google, but I’ve been
> seeing very few cases that successfully got attention from Google.
>
>
>
> You can read review feedback here:
>
>
>
>
> https://chrome.google.com/webstore/detail/windows-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji
> 
>
>
>
> In such cases the only recommendation we have is “use Edge”, as it has the
> native support and not a subject for the extension deployment issues.  In
> order to reduce support cost, we are also considering to change our
> remediation page, which we show when the users hit the conditional access
> issues, to detect such cases and show more explicit text to use Edge. I’m
> hopping we will be able to make a progress on this.
>
>
>
> Back to your question:
>
> * Do we need to bypass CORS for requests send to Microsoft's IDP?
>
> - no you don’t need. It is ok to respect CORS.
>
>
>
> * Do we need to send Microsoft SSO credentials in Credentials Mode: Omit
> requests?
>
> - I assume you meant this XHR requests with credentials?
> https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#requests_with_credentials
> 
>
> We don’t use XHR for authentication for now. So, if it is
> more simple, we can agree on “no”.
>
>
>
> No, I mean any request with a credentials mode of omit.  See
> https://fetch.spec.whatwg.org/#concept-request-credentials-mode
> .
> That's a fetch layer concept, not something unique to XHRs.
>
>
>
>
>
> * Do we need to send SSO credentials in sandboxed iframes of fenced frames?
>
>- no. I’ve 

[blink-dev] Don't forget to sign up to host a talk at BlinkOn 17!

[BlinkOn Planning Committee]

bcc: blink-dev@ and BlinkOn 17 attendees

Hi everyone,

If you’d like to host a 25-minute breakout talk or a 3-minute lightning
talk at BlinkOn 17, please sign up below and we’ll be in touch with more
information.



Breakout Talks

If you'd like to host a 25-minute breakout talk (presentation, discussion,
etc.), sign up here

by Wednesday, November 2nd.

Lightning Talks

If you'd like to host a 3-minute lightning talk, sign up here

by Monday, October 24th.

Also, if you haven’t already done so, don’t forget to register now

to attend BlinkOn 17. If you have any questions, please email us at
blin...@chromium.org.

Thanks,

Victor, on behalf of the BlinkOn Planning Committee

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

[blink-dev] Intent to Ship: Auto range support for font descriptors inside @font-face rule

['Munira Tursunova' via blink-dev]

Contact emails

moon...@chromium.org, dr...@chromium.org

Explainer

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

https://drafts.csswg.org/css-fonts/#font-prop-desc

Specification

https://drafts.csswg.org/css-fonts/#font-prop-desc

Summary

Auto range support for variable fonts in 'font-weight', 'font-style' and
'font-stretch' descriptors inside '@font-face' rule.

Motivation

Variable fonts provide users the opportunity to choose how heavy or slanted
or wide the typeface should be, rather than having those decided by the
type designer.

For variable fonts, in Chrome, it is required to add the supported range
for 'font-weight', 'font-style' and 'font-stretch' descriptors inside
@font-face rule, otherwise variable fonts would either be synthesizing bold
faces or the text will appear as normal.

In CSS WG issue 2485  it
was resolved to add a default keyword 'auto'.

Blink component

Blink>Fonts


Search tags

auto range , variable
fonts , font-weight
, font-style
, font-stretch


TAG reviewAlready shipped in other browsers, see below, no TAG review
required.

TAG review status

Not applicable, existing standard, shipped in other UAs

Risks

Interoperability and Compatibility

Low, feature already shipped in Firefox and Safari.

Gecko: Shipped/Shipping Variable fonts work without specifying the
supported range, however the browser does not yet support auto value
parsing. Tests for 'font-stretch' and 'font-weight' descriptors are
passing. Although the 'font-style' descriptor has a bug when it is
synthetically obliquing out of the supported range.

WebKit: Shipped/Shipping Variable fonts work without specifying the
supported range, however the browser does not yet support auto value
parsing. Tests for 'font-stretch' descriptors are passing. Although the
'font-weight' descriptor works without specifying the range, there are some
pixel differences in the test results. 'font-style' descriptor looks like
it is synthesizing oblique faces.

Web developers: Positive (
https://bugs.chromium.org/p/chromium/issues/detail?id=973194)

Content authors have been running into this counterintuitive problem of not
seeing their variable fonts working without explicitly specifying the
range. A UX engineer at Google, for example, faced this issue when she
wasn’t able to use font-weight property without specifying the supported
range for the variable font. That’s what she said: “It would be useful if
the variable fonts behavior was always consistent with normal fonts, where
you don't need to declare font-weight within @font-face”

Activation

None expected; Feature already implemented in other browsers.


Debuggability

Same as existing descriptors, @font-face rules inspectable 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. ‘auto’ keyword parsing tests for each descriptor; Added WPT tests for
variable and static fonts for ‘font-weight’, ‘font-style’ and
‘font-stretch’ descriptors.

Flag name

CSSFontFaceAutoVariableRange

Requires code in //chrome?

No

Tracking bug

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

Estimated milestones109
Anticipated spec changes

None expected


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5173271981457408

-- 
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/CAAO7W_C2%3DsXW53%2B08RULQvLXfWLqmxfmQ5ix%3D%3DV8qXhtbGhgAg%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Conditional Focus

['Elad Alon' via blink-dev]

Update - Firefox have officially marked 

 
this as "positive".

On Thursday, October 13, 2022 at 10:24:11 PM UTC+2 Elad Alon wrote:

> Contact emailselad...@chromium.org
>
> Explainerhttps://github.com/WICG/conditional-focus/blob/main/README.md
>
> Specification
> https://w3c.github.io/mediacapture-screen-share/#dom-capturecontroller-setfocusbehavior
>
> Design docs
> https://docs.google.com/document/d/1LHJRt-ry9hwzFTbPxKrmD0VvtEFEU6lvqsD7k6wwGKM
> (Note that this reflects the old API shape. There is no substantive 
> difference; the same functionality is simply exposed on a different surface 
> now.)
>
> Summary
>
> Extend the getDisplayMedia() API by adding a CaptureController object 
> which can be passed in as a parameter. This object exposes a 
> setFocusBehavior() method. By calling this method, an app can control 
> whether the captured tab/window is focused when capture starts, or whether 
> the capturing page should retain focus.
>
>
> Blink componentBlink 
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/679
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/697) Jan-Ivar 
> Bruaroey from Mozilla, and Youenn Fablet from Apple, have both collaborated 
> with us closely in shaping the PRs of this API. They have then approved 
> merging the PRs into w3c/mediacapture-screen-share. This is implicit 
> support, so I'd consider it POSITIVE even though, as of the time of this 
> writing, the official request for position has not yet been answered.
>
> *WebKit*: Positive (
> https://github.com/WebKit/standards-positions/issues/73) Jan-Ivar 
> Bruaroey from Mozilla, and Youenn Fablet from Apple, have both collaborated 
> with us closely in shaping the PRs of this API. They have then approved 
> merging the PRs into w3c/mediacapture-screen-share. This is implicit 
> support, so I'd consider it POSITIVE even though, as of the time of this 
> writing, the official request for position has not yet been answered.
>
> *Web developers*: Positive (https://github.com/WICG/proposals/issues/37) 
> Support from Web developers inside+outside of Google.
>
> *Other signals*:
>
> Ergonomics
>
> N/A
>
>
> Activation
>
> N/A
>
>
> Security
>
> See design-doc.
>
>
> WebView application risks
>
> N/A
>
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?No
>
> Supported on all Desktop platforms.
>
>
> Is this feature fully tested by web-platform-tests 
> 
> ?No
>
> Flag nameConditionalFocus
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1215480
>
> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1214483
>
> Sample linkshttps://wicg.github.io/conditional-focus/demo
>
> Estimated milestones
>Expected full-ship milestone: 109
> OriginTrial desktop last 108 (or up to and including 111 if delays are 
> encountered; already approved 
> 
> .)
> OriginTrial desktop first 102
>
> Anticipated spec changes
>
> N/A
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5646614535340032
>
> Links to previous Intent discussionsIntent to prototype: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/lbuqOGx07xY
> Intent to Experiment: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/I4RE2pbocTg
> Intent to Extend Experiment: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/CLmSojRQHoc/m/X-AroW-UAQAJ
>
>
> 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/de787ef0-bb05-4b87-83d2-4f4677631756n%40chromium.org.

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

[Alan Cutter]

Contact emailsalancut...@chromium.org, mgi...@chromium.org

Explainerhttps://github.com/WICG/sw-launch/blob/main/launch_handler.md

Specificationhttps://wicg.github.io/sw-launch

Summary

Add a "launch_handler" web app manifest member that enables web apps to
customize their launch behavior across all types of app launch triggers.
Example usage: { "name": "Example app", "start_url": "/index.html",
"launch_handler": { "client_mode": "navigate-existing" } } This will cause
all launches of the Example app to focus an existing app window and
navigate it (if it exists) instead of always opening 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 statusIssues addressed

Link to origin trial feedback summary
https://docs.google.com/document/d/1t60YeQ-d-FSr9i91jvylW6sA7_R4jDnX1G4_PDfssYE/edit

Risks


Interoperability and Compatibility



*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/567)

*WebKit*: No signal (
https://lists.webkit.org/pipermail/webkit-dev/2022-May/032243.html)

*Web developers*: Strongly positive. Feedback from sites using this API has
been strongly in favor of keeping the functionality.

*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?

None. This feature only affects installed web apps which run in a regular
browser environment rather than a WebView.


Debuggability

Adding the field to DevTools is in progress
.

Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?No, desktop only.

Is this feature fully tested by web-platform-tests

?No, this requires browser_tests

as
it involves managing windows.
Have raised an issue
 with testdriver.js
for web app specific support.

Flag namechrome://flags/#enable-desktop-pwas-launch-handler
kWebAppEnableLaunchHandler


Requires code in //chrome?True

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1231886

Launch bughttps://launch.corp.google.com/launch/4207744

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open
source repository and its open-source dependencies to function?
None.

Estimated milestones
OriginTrial desktop last 110
OriginTrial desktop first 98

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).

Currently launch_handler interacts poorly with share_target and may drop
in-transit user data. This will be fixed with follow up spec additions to
LaunchParams: https://github.com/WICG/sw-launch/issues/62
For the initial launch launch_handler will be ignored for share_target
launches.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5722383233056768

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/8tNe2jrJ78A
Intent to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/wNOClobsLrs
Request to Extend Experiment (rejected):
https://groups.google.com/a/chromium.org/g/blink-dev/c/pKl0eEeN5U4
Intent to Extend Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/BzwopwOFzFw
Intent to Extend Experiment 2:
https://groups.google.com/a/chromium.org/g/blink-dev/c/3jO8Ij2UZoI


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