Re: [blink-dev] PSA: Throw exception when text encode alloc memory fail.

[Dave Tapuska]

Does it make sense to put it behind a feature flag? I know an OOM is
terminal, I'm just wondering if something could have a side effect of not
OOMing and removing some state when the exception fires instead.

dave.

On Mon, Aug 5, 2024 at 12:51 AM Adam Rice  wrote:

> Could it be a bug in the TextEncoding that is asking for a very large
>> allocation size?
>
>
> I've checked the code
> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/wtf/text/text_codec_utf8.cc?q=TextCodecUTF8::EncodeCommon%20file:%5C.cc=chromium%2Fchromium%2Fsrc>,
> and it doesn't appear to have major issues. If the input is latin1, it
> allocates 3*length, where it only needs 2*length, but that doesn't seem
> like a major issue.
>
> According to
> https://chromium-review.googlesource.com/c/chromium/src/+/5742992/comments/03be0cf3_828fe5f2
> Firefox and Safari do different things, and this change will make us match
> Firefox.
>
> On Fri, 2 Aug 2024 at 23:46, Dave Tapuska  wrote:
>
>> If you look at the OOM handler of Windows version
>> <https://source.chromium.org/chromium/chromium/src/+/main:base/allocator/partition_allocator/src/partition_alloc/oom.cc;l=30;drc=c1b9831c8c232ab9470645977a18527cfa7bb993;bpv=1;bpt=1>
>> in PartitionAlloc we do not debug alias the size of allocation. So you may
>> not see the size that was failing in the minidump.  Have you had any
>> success in getting a histogram of the sizes of the allocations that are
>> failing from those minidumps? Could it be a bug in the TextEncoding that is
>> asking for a very large allocation size?
>> Also there is CrashMemoryMetricsCollector
>> <https://source.chromium.org/chromium/chromium/src/+/main:components/crash/content/browser/crash_memory_metrics_collector_android.h;l=19>
>>  on
>> Android that you could expose on desktop to collect any additional
>> histograms via shared memory (ie. I don't know if a histogram of the size
>> of allocation that failed might be useful or not).
>>
>> Perhaps the partition alloc folks have any ideas that additional reasons
>> could be logged in crash keys or in the shared memory crash metrics.
>>
>> dave.
>>
>> On Fri, Aug 2, 2024 at 6:22 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>> On Fri, Aug 2, 2024 at 11:40 AM Adam Rice  wrote:
>>>
>>>> Usually specs don't cover what happens when you run out of memory, as
>>>> implied by https://infra.spec.whatwg.org/#algorithm-limits. I think
>>>> this is fine. I'm interested in what other browsers do, but it's hard to
>>>> test unless you have a VM handy.
>>>>
>>>
>>> This section indicates that algorithms shouldn't impose specific limits,
>>> but I don't think that implies that there shouldn't be standard behavior
>>> when those limits are (naturally) met. An example of that is the
>>> QuotaExceededError
>>> <https://webidl.spec.whatwg.org/#dom-domexception-quota_exceeded_err>
>>> exception. We expect developers to be able to deal with different quota
>>> levels in different browsers, but the exception they get when they hit the
>>> limit is the same everywhere.
>>>
>>> IMO, it may make sense to define an exception that developers can expect
>>> in those cases. (maybe depending on what other browsers are doing in that
>>> case)
>>>
>>>
>>>> On Fri, 2 Aug 2024 at 01:17, Mike Taylor 
>>>> wrote:
>>>>
>>>>> Hi there,
>>>>>
>>>>> Have we done any sort of web compatibility analysis of what this
>>>>> change implies? A broken page might be a better choice than a crashed tab,
>>>>> but it's hard to know without any sense of the potential impact of this
>>>>> change. Also, is there a plan to specify this behavior? What's the interop
>>>>> situation?
>>>>>
>>>>> thanks,
>>>>> Mike
>>>>> On 8/1/24 4:38 AM, 'xu ms' via blink-dev wrote:
>>>>>
>>>>> *Contact emails*: xuzha...@microsoft.com
>>>>>
>>>>> *Summary：*
>>>>>
>>>>> We are currently observing many renderer crashes occurring in text
>>>>> encode.Encoding Standard (whatwg.org)
>>>>> <https://encoding.spec.whatwg.org/>
>>>>> This is because DOMArrayBuffer::Create is currently used to create a
>>>>> buffer, and when memory allocation fails, renderer process crashes. The
>>>>> rea

Re: [blink-dev] PSA: Throw exception when text encode alloc memory fail.

[Dave Tapuska]

If you look at the OOM handler of Windows version

in PartitionAlloc we do not debug alias the size of allocation. So you may
not see the size that was failing in the minidump.  Have you had any
success in getting a histogram of the sizes of the allocations that are
failing from those minidumps? Could it be a bug in the TextEncoding that is
asking for a very large allocation size?
Also there is CrashMemoryMetricsCollector

on
Android that you could expose on desktop to collect any additional
histograms via shared memory (ie. I don't know if a histogram of the size
of allocation that failed might be useful or not).

Perhaps the partition alloc folks have any ideas that additional reasons
could be logged in crash keys or in the shared memory crash metrics.

dave.

On Fri, Aug 2, 2024 at 6:22 AM Yoav Weiss (@Shopify) 
wrote:

>
>
> On Fri, Aug 2, 2024 at 11:40 AM Adam Rice  wrote:
>
>> Usually specs don't cover what happens when you run out of memory, as
>> implied by https://infra.spec.whatwg.org/#algorithm-limits. I think
>> this is fine. I'm interested in what other browsers do, but it's hard to
>> test unless you have a VM handy.
>>
>
> This section indicates that algorithms shouldn't impose specific limits,
> but I don't think that implies that there shouldn't be standard behavior
> when those limits are (naturally) met. An example of that is the
> QuotaExceededError
> 
> exception. We expect developers to be able to deal with different quota
> levels in different browsers, but the exception they get when they hit the
> limit is the same everywhere.
>
> IMO, it may make sense to define an exception that developers can expect
> in those cases. (maybe depending on what other browsers are doing in that
> case)
>
>
>> On Fri, 2 Aug 2024 at 01:17, Mike Taylor  wrote:
>>
>>> Hi there,
>>>
>>> Have we done any sort of web compatibility analysis of what this change
>>> implies? A broken page might be a better choice than a crashed tab, but
>>> it's hard to know without any sense of the potential impact of this change.
>>> Also, is there a plan to specify this behavior? What's the interop
>>> situation?
>>>
>>> thanks,
>>> Mike
>>> On 8/1/24 4:38 AM, 'xu ms' via blink-dev wrote:
>>>
>>> *Contact emails*: xuzha...@microsoft.com
>>>
>>> *Summary：*
>>>
>>> We are currently observing many renderer crashes occurring in text
>>> encode.Encoding Standard (whatwg.org)
>>> 
>>> This is because DOMArrayBuffer::Create is currently used to create a
>>> buffer, and when memory allocation fails, renderer process crashes. The
>>> reasons for memory allocation failure are unclear and not solely due to
>>> allocating excessively large memory.
>>>
>>> Therefore, we want to change the logic here so that when memory
>>> allocation fails, a DOMException is thrown from text encode instead of
>>> crashing.
>>>
>>> *Blink component*: Blink>TextEncoding
>>> 
>>>
>>> *Tracking bug*:[OOM] Is it a real OOM for
>>> blink::DOMArrayBuffer::Create? [355018938] - Chromium
>>> 
>>>
>>>
>>> --
>>> 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/f4cfdc62-707f-4d21-80d5-43ed37ce52fan%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/c6b00d44-599f-47bf-be3d-9e977681b827%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
>> 

Re: [blink-dev] Turning off use_v8_context_snapshot in non-production builds by default

[Dave Tapuska]

Have you thought about setting gn config v8_use_external_startup_data on
any bots?

I don't know why they are failing. The window constructor one is weird as
well because the prototype chain is different...

dave.

On Mon, Jul 15, 2024 at 2:13 PM Nico Weber  wrote:

> Hello,
>
> use_v8_context_snapshot causes us to build lots of files (blink +
> dependencies) twice on bots that cross-compiler (win/arm64, android, etc).
>
> We'd like to turn off use_v8_context_snapshot in regular release builds by
> default, and only keep it enabled in is_official_build builds.
>
> However, a small number of tests, almost all of them inspector-protocol
> tests, fail if I try this:
> https://chromium-review.googlesource.com/c/chromium/src/+/5704136
>
> That's surprising to me. I would've expected use_v8_context_snapshot to
> not change behavior.
>
> Does anyone have an idea why this might happen?
>
> Thanks,
> Nico
>
> --
> 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/CADZ1XibPV%3Dd448fckQeYFaO617_9aahsxysAjMEdQ4sy%3DQw4kQ%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/CAHgVhZU-er_dfh_esgBmfLQ%2BOVf24y2yN7K6W6yjGqNkH%3Df%3D6w%40mail.gmail.com.

Re: [blink-dev] Blink version

[Dave Tapuska]

Chrome://version will tell you the chromium version. Blink is in the main
repository and is not versioned separately.

On Mon, Apr 22, 2024, 10:43 AM Alexander Low  wrote:

> May I know is there any information about Blink? I try to find it but I
> could not manage to make it. Is there any method to verify Blink version
> that I am using right now?
>
> --
> 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/be5994af-8447-4341-8d80-e2d26433c58en%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/CAHgVhZWDrCdxqicMTy1rn-snrFQLQ90VFZtpeCZNOAW4zsOzBQ%40mail.gmail.com.

Re: [blink-dev] Re: Chromium’s migration to the new issue tracker begins Feb 2

[Dave Tapuska]

It's issue-tracker-support at chromium.org

On Wed, Jan 31, 2024, 8:31 PM David Dabbs  wrote:

> Thank you for the reminder Joe.
> My digest message does not include a full e-mail address:
>
>You can reach out at any time to issue-trac...@chromium.org
>  with questions or concerns.
>
> Can you kindly please supply this so I can post a question?
>
> Thanks,
> dd
>
> On Tuesday, January 30, 2024 at 3:27:59 PM UTC-6 jcgre...@google.com
> wrote:
>
> Hi all,
>
> As we shared last year
> ,
> Chromium is moving to a different issue tracker to provide a well-supported
> user experience for the long term. Migration is on track to begin
> February 2, 2024 at 5pm PST, and we expect migration will be completed by
> the end of day February 4, 2024 PST. There will be downtime during this
> period as Chromium’s Monorail project will be marked as read-only and the
> new Issue Tracker will not yet be available.
>
> If any critical issues arise during this period, please follow the
> escalation paths below:
>
>-
>
>P0 Security bugs: email secu...@chromium.org
>-
>
>P0 General bugs: email file...@chromium.org
>
>
> For all non-critical issues, please wait until the migration is complete
> to file in Chromium’s new Issue Tracker.
>
> We will share daily updates through migration, as well as confirm via
> email once the new Issue Tracker is ready for use. Also, emails later in
> the week will include links to documentation on the new issue tracker.
>
> You can reach out at any time to issue-trac...@chromium.org with
> questions or concerns.
>
> Thanks,
>
> -joe, on behalf of the Chromium Issue Tracker team
>
> --
> 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/29208990-3cb4-4fb7-91a7-09ad60d397dan%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/CAHgVhZWqTXC7DUFRn4ef9rfBpsT-HzXeF5FZQ8F9kRT2wckpSg%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: Call stacks in crash reports from unresponsive web pages

[Dave Tapuska]

Yes I was thinking of how the stack trace format was standardized as well.
How do wasm call stacks work with this proposal?

dave.

On Wed, Jan 24, 2024 at 8:27 PM Domenic Denicola 
wrote:

> I agree with Dave's take on the importance of not including extension
> scripts themselves, and Rick's take on how it is OK to include
> extension-injected main world scripts.
>
> One additional interop concern that's worth highlighting here is that the
> stack trace format itself is not compatible across browsers. However, I
> don't think that should block this intent. It is already exposed throughout
> the web platform (via the `error.stack` getter), and there is already a lot
> of software, both client- and server-side, which deals with parsing the
> different browsers' formats. I don't think this would make the situation
> any worse.
>
> I do wish that one day browsers would get together and standardize the
> stack trace format. https://github.com/tc39/proposal-error-stacks is one
> attempt at that, but it has been largely dormant for 3 years.
>
> On Thu, Jan 25, 2024 at 5:59 AM Rick Byers  wrote:
>
>> Not to distract from Dave's good technical questions. But I just wanted
>> to say that I'm quite excited about this work - I think it's an important
>> capability for any serious platform to have that app developers can get
>> actionable crash and hang reports, and this has been a gap. Thank you for
>> working on it! Don't hesitate to reach out if I can help unblock progress
>> in any way.
>>
>> What you have listed as a spec is more of a design doc so you'll
>> eventually need a formal spec. But the reporting spec editor @Ian
>> Clelland  mentioned over breakfast to me today
>> that he was helping to support this work, so that's great to hear.
>>
>> Dave's question about extensions in the main thread and privacy
>> implications is a good one. My initial personal take is that we probably
>> shouldn't report from extension isolated worlds, but when an extension
>> injects script into the main world, I think I can argue that they're
>> explicitly informing the site developer about their presence. In practice I
>> believe sites can detect such extensions already if suitably motivated (eg.
>> hook into the prototype of various APIs and identify their calling patterns
>> or look at JS exception stack traces). I can see an argument for not giving
>> sites easy access to such information in real-time and wonder if this has
>> come up already for the self-profiling API proposal
>> <https://wicg.github.io/js-self-profiling/>? But for an asynchronous
>> crash report sent only after the page has been shut down, I personally
>> don't think it's a threat we should be trying to defend against. I'd go
>> even further and say that if a site is hanging or crashing only under the
>> presence of extension-injected code in the main world, then that's critical
>> information for the site owner to know from a customer support perspective.
>>
>> Rick
>>
>> On Wed, Jan 24, 2024 at 3:10 PM Dave Tapuska 
>> wrote:
>>
>>> Just a few thoughts...
>>>
>>> I haven't seen a proposed implementation but I presume you are going to
>>> restrict this only to execution stacks in the main world?
>>> If you get an extension executing scripts in the main world how will you
>>> prevent the endpoint from knowing about the agent's execution
>>> environment such as what extensions they have installed?
>>> How do you know from the IO thread what the main thread isolate is?
>>> (blink::MainThreadIsolate is deprecated, please don't use it).
>>> How do document policies work across same origin documents? What realms
>>> are you checking that the policy applies, do you walk the stack looking at
>>> realms and checking if the policies apply? Or is it the current realm or
>>> incumbent realm or what?
>>>
>>> dave.
>>>
>>> On Wed, Jan 24, 2024 at 12:47 PM 'Issack John' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>>> Contact emails
>>>> issackj...@microsoft.com, seth.bren...@microsoft.com
>>>>
>>>> Explainer
>>>> https://github.com/WICG/crash-reporting/issues/12
>>>>
>>>> Specification
>>>>
>>>> https://docs.google.com/document/d/19DpvHIiYbmB9wgIP0BdI4vOnfVLcAZFmfIAml7SqRQA/edit?usp=sharing
>>>>
>>>> Summary
>>>>
>>>> This feature captures the JS call stack when a web page becomes
>>>> unresponsive due to JavaScript code running an infinite loop or other ve

Re: [blink-dev] Intent to Prototype: Call stacks in crash reports from unresponsive web pages

[Dave Tapuska]

Just a few thoughts...

I haven't seen a proposed implementation but I presume you are going to
restrict this only to execution stacks in the main world?
If you get an extension executing scripts in the main world how will you
prevent the endpoint from knowing about the agent's execution
environment such as what extensions they have installed?
How do you know from the IO thread what the main thread isolate is?
(blink::MainThreadIsolate is deprecated, please don't use it).
How do document policies work across same origin documents? What realms are
you checking that the policy applies, do you walk the stack looking at
realms and checking if the policies apply? Or is it the current realm or
incumbent realm or what?

dave.

On Wed, Jan 24, 2024 at 12:47 PM 'Issack John' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
> issackj...@microsoft.com, seth.bren...@microsoft.com
>
> Explainer
> https://github.com/WICG/crash-reporting/issues/12
>
> Specification
>
> https://docs.google.com/document/d/19DpvHIiYbmB9wgIP0BdI4vOnfVLcAZFmfIAml7SqRQA/edit?usp=sharing
>
> Summary
>
> This feature captures the JS call stack when a web page becomes
> unresponsive due to JavaScript code running an infinite loop or other very
> long computation. This helps developers to identify the cause of the
> unresponsiveness and fix it more easily. The JS call stack is included in
> the crash reporting API when the reason is unresponsive.
>
>
> Blink component
> Blink>ReportingObserver
> 
>
> Motivation
>
> When a web page becomes unresponsive, it's often because of JavaScript
> code which is busy running an infinite loop or other very long computation.
> When a developer receives a report from the crash reporting API, and the
> reason is unresponsive, it would be very helpful to include the JS call
> stack from when the page was deemed unresponsive. This would let the
> website developer more easily find the find and fix the problem. What
> happens instead? The page reports that it was terminated due to being
> unresponsive, but the developer of the page has no further information
> about how to fix the problem.
>
>
> Initial public proposal
> https://bugs.chromium.org/p/chromium/issues/detail?id=1445539
>
> TAG review
> None
>
> TAG review status
> Pending
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *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?*
>
> None
>
>
> Debuggability
>
> None
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
> No
>
> Flag name on chrome://flags
> None
>
> Finch feature name
> None
>
> Non-finch justification
> None
>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1445539
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/4731248572628992
>
> 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/MW2PPF6784DDB763E2DA7BFC75AE51613ABC27B2%40MW2PPF6784DDB76.namprd00.prod.outlook.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/CAHgVhZUui22mB-J5SAEmEd%3DCk%2BrcyRSr4tGASLGFcsvRn9QVOQ%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: Partitioning :visited links history

[Dave Tapuska]

I look forward to this. Will this include an implementation whereby the
visited links are only sent to the relevant
AgentSchedulingGroup/SiteInstanceGroup? My recollection is that the visited
link map was propagated to each renderer unconditionally.

Dave

On Wed, Jun 28, 2023, 3:21 AM Yoav Weiss  wrote:

> Amazing work that we should've done long ago. Thanks for taking this on!!
>
> On Tue, Jun 27, 2023 at 10:46 PM Kyra Seevers 
> wrote:
>
>> Contact emails
>>
>> kyraseev...@chromium.org
>>
>> Explainer
>>
>> https://github.com/kyraseevers/Partitioning-visited-links-history
>>
>> Specification
>>
>> TBD
>>
>> Summary
>>
>> To eliminate user browsing history leaks, anchor elements will be styled
>> as :visited if and only if they have been visited from the same top-level
>> site and frame origin before. On the browser-side, this means that the
>> VisitedLinks hashtable will now be partitioned via "triple-keying", or by
>> storing the following for each visited link: > frame origin>. By only styling links that have been visited from this site
>> and frame before, the many side-channel attacks that have been developed to
>> obtain :visited links styling information will be obsolete, as they no
>> longer provide sites with new information about users.
>>
>> Blink component
>>
>> Blink>History>VisitedLinks
>> 
>>
>> Motivation
>>
>> Since 2010, the number of side-channel attacks to leak the user’s
>> browsing history by abusing :visited links styling has grown, including user
>> interaction attacks, timing attacks, pixel color attacks, and process-level
>> attacks
>> .
>> While these attack vectors are slowed down by the 2010 mitigations
>> ,
>> they are not eliminated; browsers are still actively leaking user browsing
>> history today.
>>
>> Triple-keyed history partitioning only styles links have been visited
>> from the same top-level site and frame origin before. As a result, the many
>> side-channel attacks that have been developed to obtain the global :visited
>> links state will now be obsolete, as they will no longer provide sites with
>> new information about users.
>>
>> This feature will improve user privacy and security. The resulting
>> implementation will be relevant to users who will see slight changes to
>> which links appear styled on their screens, and to bad actors who will no
>> longer be able to use side-channel attacks to reveal user browsing history.
>>
>> Initial public proposal
>>
>> https://github.com/WICG/proposals/issues/100
>>
>> Search tags
>>
>> visited links , 
>> :visited
>> selector , 
>> partitioning
>> history 
>>
>> TAG review
>>
>> TBD
>>
>> TAG review status
>>
>> Not Started
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Gecko: Positive initial signals from presentation at WebAppSec
>> 
>>
>> WebKit: Positive initial signals from presentation at WebAppSec
>> 
>>
>> Web developers: Feedback from UX that CSS extensibility is in-demand
>> from developers right now, and this work would pave the way for less
>> restricted CSS on anchor elements. In addition, support from various
>> developers who believe that taking care of this long-standing privacy leak
>> will allow their own security and privacy solutions to advance once history
>> sniffing is no longer an issue.
>>
>> Other signals: N/a
>>
>> WebView application risks
>>
>> No - this feature deals with platform-specific code, and Android WebView
>> does style :visited links based on user browsing history, but we do not
>> expect significant challenges for WebView users.
>>
>>
>> Debuggability
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> No
>>
>> Flag name
>>
>> (Tentatively) base::features::PartitionVisitedLinks
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1448609
>>
>> Launch bug
>>
>> https://launch.corp.google.com/launch/4259382
>>
>> Estimated milestones
>>
>> No milestones specified yet
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5101991698628608
>>
>> --
>> 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 

Re: [blink-dev] Allow Navigator.registerProtocolHandler to register "payto"

[Dave Tapuska]

I feel the chromestatus is a bit misleading on the Mozilla position. It
indicates "Worth Prototyping" with a link to the Mozilla positions github
issue. But no one from Mozilla has indicated a position.

dave.

On Thu, Apr 13, 2023 at 3:05 PM Rastislav Vašička <
rastislav.vasi...@codetech.cc> wrote:

> Thank you. Created https://chromestatus.com/feature/5199727026503680
>
> On Thursday, April 13, 2023 at 4:57:13 PM UTC+2 mike...@chromium.org
> wrote:
>
>> Got it - we'll treat this as an Intent to Prototype then (typically an
>> Intent starts with "Intent to Prototype" (or Experiment, Ship, etc.).
>>
>> You'll want to create a chromestatus.com entry with the proposed new
>> feature (see
>> https://www.chromium.org/blink/launching-features/#launch-process - that
>> explains how to get access to create a new feature, if you don't already
>> have it).
>>
>> I think it would also be useful to flesh out the Explainer a bit,
>> focusing on the concrete use cases you're trying to enable.
>>
>> thanks,
>> Mike
>> On 4/13/23 10:44 AM, Rastislav Vašička wrote:
>>
>> Sure, Mike.
>>
>> As the protocol is defined in RFC 8905, it may be implemented in the
>> system.
>>
>> The bug is located here:
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1432881
>>
>> Prototype and PR are in progress.
>>
>> On Thursday, April 13, 2023 at 3:28:27 PM UTC+2 mike...@chromium.org
>> wrote:
>>
>>> Hi Rastislav,
>>>
>>> Can you clarify - do you intend to prototype this? Do you have a bug or
>>> CL where you're doing the work?
>>>
>>> thanks,
>>> Mike
>>> On 4/13/23 5:24 AM, Rastislav Vašička wrote:
>>>
>>> Explainer
>>> A unified URI scheme for all payment target types allows applications to
>>> offer user interactions with URIs that represent payment targets,
>>> simplifying the introduction of new payment systems and applications.
>>>
>>> Specification
>>> RFC 8905 
>>>
>>> Summary
>>>
>>> Add "payto" to the list of protocols available for registration via
>>> registerProtocolHandler(). The Payto scheme is described in RFC 8905
>>>  but not adapted in the
>>> safelisted scheme list. To support this standard it will be great to adapt
>>> it.
>>>
>>>
>>> Blink component
>>> Blink>HTML>CustomHandlers
>>> 
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>> The implementation gives precedence to native protocol handlers before
>>> consulting sites registered via registerProtcolHandler.
>>>
>>> Gecko: No signal
>>>
>>> WebKit: No signal
>>>
>>> Web developers: No signals
>>>
>>> --
>>> 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+...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44b54a21-2f87-4aca-8c06-6a76a93daac8n%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/60c4c259-9d01-41b1-ab03-f2956d88ffc2n%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/CAHgVhZXg92%3DwOiC9hsufrhGTXYX9MWaG7%3DoCc2Ztkj4u7xadew%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Send Mouse Events to Disabled Form Controls

[Dave Tapuska]

So the initial attempt was problematic for interop due to mouseup, and
mousedown being displaced for the entire event path. I had removed my
request to ship in order to address the concerns of other vendors (proposed
another 3 milestones to collect more data). It appears this attempt does
fix that by not dispatching them. I did not complete the analysis at the
time due to changing priorities of projects. I am happy that Joey has
spearheaded this work and do support this intent.

dave.

On Mon, Oct 17, 2022 at 8:33 AM Yoav Weiss  wrote:

>
>
> On Sun, Oct 16, 2022 at 12:08 AM Joey Arhar  wrote:
>
>> Contact emailsjar...@chromium.org
>>
>> Specificationhttps://github.com/whatwg/html/issues/2368
>> https://github.com/whatwg/html/issues/5886
>> No changes have been made to the spec yet, but if this launch goes well
>> then we will likely change the HTML spec to reflect this behavior.
>>
>> Summary
>>
>> This will make mouse events other than click, mouseup, and mousedown
>> become dispatched on disabled form controls instead of blocking them. It
>> will also stop propagating click, mouseup, and mousedown events to the
>> parents of disabled form controls when the event is targeted at a child of
>> a disabled form control, which is the same behavior that Firefox currently
>> has. A previous attempt at this was not shipped here:
>> https://chromestatus.com/feature/5685077795143680
>>
>
> Any details on why that past attempt didn't make it? Any compat issues
> encountered?
>
>
>> Here are the previous blink-dev threads:
>>
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/rhNbsYDBJes/m/Jvmtv6IbBwAJ
>>
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/KHXNJINUrj0/m/OAAh-sWuAwAJ
>>
>>
>> Blink componentBlink>DOM
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> *Gecko*: Shipped/Shipping
>>
>> *WebKit*: No signal
>>
>> *Web developers*: Positive
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> This change will not be used in tandem with any other APIs. This change
>> will not affect Chrome's performance.
>>
>>
>> Activation
>>
>> This change will not be challenging for developers to take advantage of.
>>
>>
>> Security
>>
>> I have no security concerns for this change.
>>
>>
>> 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
>>
>> I'm not aware of any event path debugging or disabled attribute debugging
>> that would need to be updated for this change.
>>
>>
>> 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
>> 
>> ?https://wpt.fyi/results/dom/events/Event-dispatch-click.html
>> https://github.com/web-platform-tests/wpt/pull/32381
>>
>> Flag nameSendMouseEventsDisabledFormControls
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=588760
>>
>> Estimated milestones
>>
>> 109
>>
>>
>> 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).
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/6128674512830464
>>
>> 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/CAK6btwK6HEE0ujdJ9rjHChr5FGx3eXOEm4Vvaxo-BFVw5jfQtg%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/CAL5BFfXk7jVTytyfBvYbpFSeOmXB6wVB%3DXKToaLGcM6E9VPp_g%40mail.gmail.com
> 

Re: [blink-dev] Debugging compressed pointers in Blink

[Dave Tapuska]

Anton, can you add this to
https://source.chromium.org/chromium/chromium/src/+/main:docs/linux/debugging.md
?

On Tue, Oct 11, 2022 at 10:19 AM Anton Bikineev 
wrote:

> I'm now submitting a CL
>  that adds
> some quick gdb helpers:
>
>   (gdb) source v8/tools/gdbinit
>   # Print Member:
>   (gdb) cpm **
>   # Print Compressed Pointer:
>   (gdb) cpcp **
>
> It currently erases the pointee type, but this can be improved in the
> future.
>
> On Tue, Oct 11, 2022 at 4:05 PM Anton Bikineev 
> wrote:
>
>> Which should hopefully be callable from the debugger and not eliminated
>>> by the linker?
>>
>> We can apply __attribute__((used,retain)) to make sure that the linker
>> doesn't strip the functions with --gc-sections, same as did
>>  for V8
>> helpers (a week ago :) ). I'll prepare a CL.
>>
>> On Mon, Oct 10, 2022 at 8:45 PM Daniel Cheng  wrote:
>>
>>> For now, I guess it should be sufficient to add something
>>> to v8/include/cppgc/internal/member-storage.h like
>>>
>>> #ifndef NDEBUG  // DCHECK_IS_ON() would be nicer, but not sure what v8
>>> uses
>>> extern "C" void* DecompressPointerForDebugger(uint32_t value) {
>>>   return cppgc::internal::CompressedPointer::Decompress(value);
>>> }
>>> #endif
>>>
>>> Which should hopefully be callable from the debugger and not eliminated
>>> by the linker?
>>>
>>> Daniel
>>>
>>> On Mon, 10 Oct 2022 at 11:32, Stefan Zager  wrote:
>>>
 I ran into this today, and it's pretty frustrating:

 (rr) p inner_node_

 $11 = {

= {

 raw_ = {

   static kCompressedSentinel = 1,

   value_ = 2148082696 <(214)%20808-2696>

 }

   },

= {}, >>> data fields>}
 (rr) p inner_node_.Load()

 Couldn't find method blink::Member::Load

 (rr) p inner_node_.raw_.Load()

 Cannot evaluate function -- may be inlined

 (rr) p
 cppgc::internal::CompressedPointer::Decompress(inner_node_.raw_.value_)

 Cannot evaluate function -- may be inlined

 (rr)

 I found that I can avoid the issue with this in args.gn:

 cppgc_enable_caged_heap = false
 cppgc_enable_pointer_compression = false

 ... but I would prefer a better solution.

 On Mon, Oct 10, 2022 at 10:22 AM Ian Kilpatrick <
 ikilpatr...@chromium.org> wrote:

> Is there a bug to follow regarding the debuggability of the pointers?
>
> Ian
>
> On Thu, Sep 22, 2022 at 11:10 AM Anton Bikineev 
> wrote:
>
>> There is "cppgc::internal::CompressedPointer::Decompress(void*)". I
>> would, however, hide it behind a simpler name in .gdbinit.
>>
>> On Thu, Sep 22, 2022 at 5:51 PM Daniel Cheng 
>> wrote:
>>
>>> Is there a callable C++ function that can turn a compressed pointer
>>> into the actual pointer value?
>>>
>>> Daniel
>>>
>>> On Thu, 22 Sept 2022 at 08:43, Anton Bikineev 
>>> wrote:
>>>
 We have plans to provide more debugging tooling for Oilpan. I
 haven't had a need to examine compressed pointers myself, however I see
 that some simple gdb/windbg function that'd follow pointers would be 
 useful.

 On Thu, Sep 22, 2022 at 1:14 AM Kentaro Hara 
 wrote:

> +Michael Lippautz 
>
> 2022年9月22日(木) 4:01 'Daniel Libby' via blink-dev <
> blink-dev@chromium.org>:
>
>> https://crrev.com/c/3835682 enabled pointer compression for
>> Blink Member<> pointers. How are folks handling these while
>> debugging (either live or crash dumps)? Is there some tooling 
>> available
>> that will look up and apply the cage base?
>>
>> I didn't see anything mentioned in
>> https://docs.google.com/document/d/1neGN8Jq-1JLrWK3cvwRIfrSjLgE0Srjv-uq7Ze38Iao/edit#
>> but maybe there are better known tools/techniques from v8 (which 
>> IIUC has
>> had compressed pointers for some time now).
>>
>> --
>> 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/4b3e5bbb-134a-4483-9a1e-8e33fbc6f38en%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 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Dave Tapuska]

BFCache has different behavior. Pages are evicted if an extension tries to
communicate with something that is in the cache. We did outreach to help
increase BFCache rates because we know what extensions cause eviction.

In terms of prerender it is different because extensions can modify/block
content on the page and you really need to do this during the prerender
phase to really do what an extension wants. It is difficult to quantify
which extensions could be broken, but we did do some testing of popular
extensions and discovered no problems. We have finch and enterprise policy
fail safes in place if we do run into something in the wild that is causing
significant issues.

dave.

On Mon, Sep 5, 2022 at 5:33 AM Yoav Weiss  wrote:

> Thanks!! Were extensions affected by previous multi-page arch shipped
> features, such as BFCache?
> Is there a way for us to scan the various extension stores, look for
> patterns that would be affected by this change and notify the extension's
> authors ahead of time?
>
> On Thu, Sep 1, 2022 at 4:23 PM Dave Tapuska  wrote:
>
>> I drafted a blog post highlighting the additions/changes to the extension
>> APIs. It is just going through reviews before being posted to
>> developer.chrome.com, hopefully sometime next week.
>>
>> dave.
>>
>> On Thu, Sep 1, 2022 at 2:49 AM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Thu, Sep 1, 2022 at 8:24 AM Takashi Toyoshima 
>>> wrote:
>>>
>>>> Thank you for the feedback.
>>>>
>>>> Yes, the Extensions is the thing we have paid the biggest attention to
>>>> support Prerendering on Desktop.
>>>>
>>>> https://docs.google.com/document/d/16Sy2Xq-AcnhwnpC0q232OMSmxTpQYDANRAO-zJ8DKiA/edit?usp=sharing
>>>> This is the document we discussed especially on Prerendering and
>>>> Extensions. In the design discussion we tried finding the best choice to
>>>> minimize possible compatibility breakage for most Extensions, but at the
>>>> same time, we understood it's unavoidable that some Extensions may be
>>>> surprised to see unexpected prerendering pages.
>>>>
>>>> So, our prepared mitigations are
>>>> - Enterprise Policy to disable Prerendering completely
>>>> - Users' report based incompatible Chrome Extensions list that disables
>>>> Prerendering when a user installs one in the list.
>>>>
>>>
>>> That sounds reasonable, but I wonder if more communication to the
>>> extensions community is warranted.
>>>
>>> +Simeon Vincent  for thoughts
>>>
>>>
>>>>
>>>> It minimizes the risk to block the rollout for such unexpected
>>>> Extensions compatibility breakages.
>>>>
>>>> For more visibility, here is the crbug entry to report such
>>>> incompatible Extensions quickly.
>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1351312
>>>>
>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1351312>
>>>> T <https://bugs.chromium.org/p/chromium/issues/detail?id=1351312>hanks!
>>>>
>>>> On Thu, Sep 1, 2022 at 6:20 AM Daniel Bratell 
>>>> wrote:
>>>>
>>>>> In addition to the LGTM, I want to point out that during our
>>>>> discussion among the API Owners, we did specifically wonder about 
>>>>> extension
>>>>> compatibility. Since this will change things for extensions, I think it
>>>>> will be important to look for compatibility problems popping up, and, if
>>>>> necessary, delay until any such problems are fully understood.
>>>>>
>>>>> /Daniel
>>>>> On 2022-08-31 16:34, Daniel Bratell wrote:
>>>>>
>>>>> LGTM3
>>>>>
>>>>> /Daniel
>>>>> On 2022-08-30 10:58, Yoav Weiss wrote:
>>>>>
>>>>> LGTM2 to expand support for desktop.
>>>>>
>>>>> On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent 
>>>>> wrote:
>>>>>
>>>>>> LGTM1.
>>>>>> It's pretty safe to expand support to desktop platforms, and it
>>>>>> seems there are no negative signals.
>>>>>>
>>>>>> On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev <
>>>>>> blink-dev@chromium.org> wrote:
>>>>>>
>>>>>>> Contact emails
>>>>>>>
>>>>>>> toyos...@chromium.org, angelrapo...@google.

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Dave Tapuska]

I drafted a blog post highlighting the additions/changes to the extension
APIs. It is just going through reviews before being posted to
developer.chrome.com, hopefully sometime next week.

dave.

On Thu, Sep 1, 2022 at 2:49 AM Yoav Weiss  wrote:

>
>
> On Thu, Sep 1, 2022 at 8:24 AM Takashi Toyoshima 
> wrote:
>
>> Thank you for the feedback.
>>
>> Yes, the Extensions is the thing we have paid the biggest attention to
>> support Prerendering on Desktop.
>>
>> https://docs.google.com/document/d/16Sy2Xq-AcnhwnpC0q232OMSmxTpQYDANRAO-zJ8DKiA/edit?usp=sharing
>> This is the document we discussed especially on Prerendering and
>> Extensions. In the design discussion we tried finding the best choice to
>> minimize possible compatibility breakage for most Extensions, but at the
>> same time, we understood it's unavoidable that some Extensions may be
>> surprised to see unexpected prerendering pages.
>>
>> So, our prepared mitigations are
>> - Enterprise Policy to disable Prerendering completely
>> - Users' report based incompatible Chrome Extensions list that disables
>> Prerendering when a user installs one in the list.
>>
>
> That sounds reasonable, but I wonder if more communication to the
> extensions community is warranted.
>
> +Simeon Vincent  for thoughts
>
>
>>
>> It minimizes the risk to block the rollout for such unexpected Extensions
>> compatibility breakages.
>>
>> For more visibility, here is the crbug entry to report such incompatible
>> Extensions quickly.
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1351312
>>
>> 
>> T hanks!
>>
>> On Thu, Sep 1, 2022 at 6:20 AM Daniel Bratell 
>> wrote:
>>
>>> In addition to the LGTM, I want to point out that during our discussion
>>> among the API Owners, we did specifically wonder about extension
>>> compatibility. Since this will change things for extensions, I think it
>>> will be important to look for compatibility problems popping up, and, if
>>> necessary, delay until any such problems are fully understood.
>>>
>>> /Daniel
>>> On 2022-08-31 16:34, Daniel Bratell wrote:
>>>
>>> LGTM3
>>>
>>> /Daniel
>>> On 2022-08-30 10:58, Yoav Weiss wrote:
>>>
>>> LGTM2 to expand support for desktop.
>>>
>>> On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent  wrote:
>>>
 LGTM1.
 It's pretty safe to expand support to desktop platforms, and it
 seems there are no negative signals.

 On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev <
 blink-dev@chromium.org> wrote:

> Contact emails
>
> toyos...@chromium.org, angelrapo...@google.com
>
> Explainer
>
> This I2S aims to expand our efforts on Prerender2 (currently shipped
> only on Android) to Desktop.
>
> The full prerendering revamped explainer can be found at
>
> https://github.com/WICG/nav-speculation/blob/main/README.md
>
> Specification
>
> https://wicg.github.io/nav-speculation/prerendering.html
>
> Design docs
>
>
> https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs
>
> Summary
>
> Prerendering is “pre”-rendering, it’s about pre-loading and rendering
> a Web page before the user actually navigates to it. The main goal of
> prerendering is to make the next page navigation faster, or ideally nearly
> instant.
>
> Sites can inform the user agent about which pages the user may likely
> visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
> user is at page A and will likely navigate to page B next). Once the
> prerender is triggered, the browser pre-fetches the main resource,
> instantiates a hidden page, and processes the main resource to fetch and
> process more subresources.
>
> After shipping Prerender2 for Android (I2S speculation rules
> triggered Prerender2
> 
> and I2S for Omnibox triggered Prerender2
> ),
> we are now requesting approval to ship Prerender2 for Desktop. This 
> release
> will enable the same triggers (speculation rules and Omnibox) for Desktop.
>
> With this feature, Chrome (Desktop) will start prerendering
> high-confidence URL suggestions provided by the page using speculation
> rules or directly by Omnibox. During the prerendering process, a page will
> process and construct the full DOM tree, including the execution of 
> scripts
> (this differs from No-state Prefetch
> 
> which only prefetches resources and doesn’t execute scripts).
>
> Note that we are not shipping cross-origin prerendering, which 

Re: [blink-dev] Intent to Experiment: Align Timers (including DOM timers) at 125 Hz

[Dave Tapuska]

Stefan, this was just for "non-zero delay" timers? Are there still
potential issues there?

On Fri, Aug 5, 2022 at 1:19 PM Stefan Zager  wrote:

> This is a common programming pattern:
>
> requestAnimationFrame(() => {
>   setTimeout(() => {
> // At this point, it's very likely that layout is clean,
> // because we *just* completed a rendering update.
> // Queries of layout information are very unlikely to
> // trigger a forced layout.
> document.body.offsetTop;
>   });
> });
>
> Aligning timers will make this strategy for avoiding forced layout less
> effective, because other non-timer tasks may run ahead of the setTimeout
> and invalidate layout.
>
> Also: the rAF(setTimeout()) construct is used extensively in chromium's
> test corpus, to schedule work ASAP after a rendering update. Many of our
> tests use a synchronous compositor: rendering updates happen without delay
> whenever there are no other tasks ready to run. In other tests, we increase
> the frequency of rendering updates from 60Hz to 200Hz, just because we know
> there won't be any long-running tasks and we want the tests to run faster.
>
> So... I see potential issues here.
>
> On Wed, Aug 3, 2022 at 6:50 AM Etienne Pierre-doray 
> wrote:
>
>> etien...@chromium.org
>>
>> ExplainerNone
>>
>> Specification
>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>>
>> Design docs
>>
>> https://docs.google.com/document/d/1OjZoHNvn_vz6bhyww68B_KZBi6_s5arT8xMupuNEnDM/edit
>>
>> Summary
>>
>> Run all timers (with a few exceptions) with a non-zero delay on a regular
>> 8ms aligned wake up (125 Hz), instead of as soon as their delay has passed.
>> This affect DOM timers; On foreground pages, run DOM timers with a non-zero
>> delay on a regular 8ms aligned wake up, instead of as soon as their delay
>> has passed. On background pages, DOM timers already run on a regular 1s
>> aligned wake up (1 Hz), or even less frequently after 5 minutes.
>>
>>
>> Blink componentBlink>Scheduling
>> 
>>
>> TAG review
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This feature changes the behavior of an existing API in a way that is
>> spec-compliant (the spec says "Optionally, wait a further
>> implementation-defined length of time", ref.:
>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout).
>> Content that relies on precise timing for DOM Timers may stop working
>> properly in Chromium with this feature. The risk is mitigated by delaying
>> DOM Timers by at most 8 ms, and by disabling the feature when WebRTC has
>> active connections in the process. Content that cannot support a 8 ms delay
>> would probably be better served by alternative APIs described at
>> https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds.
>> Due to the significant battery savings that come with this feature, we
>> expect that most browsers will decide to implement it after some time.
>>
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *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?
>>
>>
>>
>> Goals for experimentation
>>
>> Gain insight on potential compatibility issues and evaluate impact on
>> guardian metrics (page load, latency).
>>
>>
>> Reason this experiment is being extended
>>
>>
>>
>> Ongoing technical constraints
>>
>>
>>
>> Debuggability
>>
>> This changes the behavior of an existing API. No new debugging support is
>> added.
>>
>>
>> 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
>> 
>> ?No
>>
>> DevTrial instructions
>> https://github.com/eti-p-doray/align-wakeups/blob/main/HOWTO.md
>>
>> Flag namealign-wakeups
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1153139
>>
>> Estimated milestones
>> OriginTrial desktop last 105
>> OriginTrial desktop first 105
>> DevTrial on desktop 105
>> OriginTrial Android last 105
>> OriginTrial Android first 105
>> DevTrial on Android 105
>> OriginTrial webView last 105
>> OriginTrial webView first 105We plan to do a 1% Stable experiment for
>> M105 stable.
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5680188671655936
>>
>> --
>> 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] Re: Intent to Ship: Element.isVisible method

[Dave Tapuska]

Ya I only ran into this when investigating how visibility really works.
Such as visibilityChanged events and document.visibilityState do not change
for a hidden iframe. (which I guess is correct based on its definition,
because those are about the tab being in the foreground or not). The only
problem I have with this definition is that the CSS spec declares it as
"rendered" and if someone is considering that as pixels on the display that
isn't quite correct.

I did find enough stack overflow articles about people asking about
interactions with the parent document. I don't think making it work for
same origin iframes vs cross origin iframes is something that would give
much benefit.

dave.

On Fri, May 20, 2022 at 2:39 PM Joey Arhar  wrote:

> > Oh that is what was debated here
> <https://github.com/w3c/csswg-drafts/issues/6850#issuecomment-1010363945>
>
> I think that the use of "document" there was about being in the viewport
> and being painted, not about iframes.
>
> Currently, isVisible doesn't look at parent iframes. I don't think there's
> anything wrong with adding that functionality for LocalFrames, but doing so
> for RemoteFrames would probably have security/privacy considerations.
>
> On Thu, May 19, 2022 at 5:17 PM Dave Tapuska 
> wrote:
>
>> So how does this method work for iframes that have their visibility
>> hidden? Is it intended to work for that?
>>
>> 
>>  
>> 
>>
>> div's isVisible will always be true. Perhaps isVisible needs a caveat
>> that it only works for the current document. Oh that is what was debated
>> here
>> <https://github.com/w3c/csswg-drafts/issues/6850#issuecomment-1010363945>
>> .
>>
>> dave.
>>
>> On Thu, May 19, 2022 at 6:52 PM Mike Taylor 
>> wrote:
>>
>>> Given the CSSWG resolution in
>>> https://github.com/w3c/csswg-drafts/issues/7274#issuecomment-1130214343,
>>> LGTM1 to ship assuming we're not shipping `checkInert` with the rest.
>>>
>>> Thanks for addressing Mozilla's feedback.
>>>
>>> On 5/5/22 4:26 PM, Joey Arhar wrote:
>>>
>>> > Can you ask for signals?
>>>
>>> https://github.com/mozilla/standards-positions/issues/634
>>> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032218.html
>>>
>>> On Wed, May 4, 2022 at 3:02 AM Yoav Weiss 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wednesday, May 4, 2022 at 1:08:11 AM UTC+2 Joey Arhar wrote:
>>>>
>>>>> Contact emails jar...@chromium.org
>>>>>
>>>>> Explainer
>>>>> https://github.com/WICG/display-locking/blob/main/explainers/isvisible.md
>>>>>
>>>>> Specification
>>>>> https://drafts.csswg.org/cssom-view/#dom-element-isvisible
>>>>>
>>>>> Summary
>>>>>
>>>>> Element.isVisible() returns true if the element is visible, and false
>>>>> if it is not. It checks a variety of factors that would make an element
>>>>> invisible, including display:none, visibility, content-visibility, and
>>>>> opacity.
>>>>>
>>>>>
>>>>> Blink component Blink>DOM
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM>
>>>>>
>>>>> TAG review https://github.com/w3ctag/design-reviews/issues/734
>>>>>
>>>>> TAG review status Pending
>>>>>
>>>>> Risks
>>>>>
>>>>>
>>>>> Interoperability and Compatibility
>>>>>
>>>>> This feature is not particularly contentious or complicated, but is
>>>>> mostly useful in the presence of content-visibility.
>>>>>
>>>>>
>>>>> Gecko: No signal
>>>>>
>>>>> WebKit: No signal
>>>>>
>>>>
>>>> Can you ask for signals?
>>>>
>>>>
>>>>>
>>>>> Web developers: No signals
>>>>>
>>>>
>>>> Would be good to gather signals here as well.
>>>>
>>>>
>>>>>
>>>>> Other signals:
>>>>>
>>>>> Ergonomics
>>>>>
>>>>> This feature could be used in tandem with content-visibility or
>>>>> details elements. Usage of this API will not make it hard for Chrome to
>>>>> maintain good performance.
>>>>>
>>>>>
>>>>> Activ

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[Dave Tapuska]

So how does this method work for iframes that have their visibility hidden?
Is it intended to work for that?


 


div's isVisible will always be true. Perhaps isVisible needs a caveat that
it only works for the current document. Oh that is what was debated here
.

dave.

On Thu, May 19, 2022 at 6:52 PM Mike Taylor  wrote:

> Given the CSSWG resolution in
> https://github.com/w3c/csswg-drafts/issues/7274#issuecomment-1130214343,
> LGTM1 to ship assuming we're not shipping `checkInert` with the rest.
>
> Thanks for addressing Mozilla's feedback.
>
> On 5/5/22 4:26 PM, Joey Arhar wrote:
>
> > Can you ask for signals?
>
> https://github.com/mozilla/standards-positions/issues/634
> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032218.html
>
> On Wed, May 4, 2022 at 3:02 AM Yoav Weiss  wrote:
>
>>
>>
>> On Wednesday, May 4, 2022 at 1:08:11 AM UTC+2 Joey Arhar wrote:
>>
>>> Contact emails jar...@chromium.org
>>>
>>> Explainer
>>> https://github.com/WICG/display-locking/blob/main/explainers/isvisible.md
>>>
>>> Specification https://drafts.csswg.org/cssom-view/#dom-element-isvisible
>>>
>>> Summary
>>>
>>> Element.isVisible() returns true if the element is visible, and false if
>>> it is not. It checks a variety of factors that would make an element
>>> invisible, including display:none, visibility, content-visibility, and
>>> opacity.
>>>
>>>
>>> Blink component Blink>DOM
>>> 
>>>
>>> TAG review https://github.com/w3ctag/design-reviews/issues/734
>>>
>>> TAG review status Pending
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> This feature is not particularly contentious or complicated, but is
>>> mostly useful in the presence of content-visibility.
>>>
>>>
>>> Gecko: No signal
>>>
>>> WebKit: No signal
>>>
>>
>> Can you ask for signals?
>>
>>
>>>
>>> Web developers: No signals
>>>
>>
>> Would be good to gather signals here as well.
>>
>>
>>>
>>> Other signals:
>>>
>>> Ergonomics
>>>
>>> This feature could be used in tandem with content-visibility or details
>>> elements. Usage of this API will not make it hard for Chrome to maintain
>>> good performance.
>>>
>>>
>>> Activation
>>>
>>> This feature is easy to feature detect and polyfill.
>>>
>>>
>>> Security
>>>
>>> I have no security risks/considerations for this feature.
>>>
>>>
>>> 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?
>>>
>>> This does not deprecate or change any existing APIs and does not have
>>> any risk for WebView.
>>>
>>>
>>> Debuggability
>>>
>>> This feature does not need any new debugging features.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ? Yes
>>>
>>> Flag name --enable-blink-features=isVisible
>>>
>>> Requires code in //chrome? False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1309533
>>>
>>> Estimated milestones
>>>
>>> 103
>>>
>>>
>>> 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).
>>> https://github.com/w3c/csswg-drafts/issues/7232
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5163102852087808
>>>
>>> Links to previous Intent discussions Intent to prototype:
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwK01yGZ0LVb6M_8WdeC5OM0qfUv5T1TUO%3D1if1G%2BKogRw%40mail.gmail.com
>>> 
>>>
>>>
>>> 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/CAK6btwKkoRBHUja0MePoXLRq0vN_WVeF%3Dr2se34ThXo5Tr%2BdtQ%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 Ship: Same-origin prerendering triggered by the speculation rules API

[Dave Tapuska]

This intent is for Android only, correct?
Will there be another Intent to Ship on Desktop?
Presumably desktop is blocked on extensions and the compatibility risk
regarding those. (I recently discussed this at the WECG

meeting).

dave.

On Fri, Apr 22, 2022 at 1:27 PM 'Angel Raposo' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> noam.j.rosent...@gmail.com
> dome...@chromium.org, jbro...@chromium.org, nhir...@chromium.org,
> navigation-...@chromium.org
>
> Explainer
>
> This feature:
>
> https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md
>
> Larger project:
> https://github.com/WICG/nav-speculation/blob/main/README.md
>
> Specification
>
> https://wicg.github.io/nav-speculation/prerendering.html
>
> Design docs
>
>
> https://docs.google.com/document/d/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing
>
> Summary
>
> Prerendering is “pre”-rendering, it’s about pre-loading and rendering a
> Web page before the user actually navigates to it. The main goal of
> prerendering is to make the next page navigation faster, or ideally nearly
> instant.
>
> Sites can tell the user agents about which pages the user may likely
> visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
> user is at page A and will likely navigate to page B next). Once the
> prerender is triggered, the browser pre-fetches the main resource,
> instantiates a hidden page, and processes the main resource to fetch and
> process more subresources.
>
> We would like to ship same-origin speculation rules prerendering. With
> this feature, Chrome will start prerendering high-confidence URL
> suggestions provided by the page using speculation rules. During the
> prerendering process, a page will process and construct the full DOM tree,
> including the execution of scripts (this differs from the prefetching
> resources using No-state Prefetch
> )
>
> This prerendering affects how the prerendered pages are processed. The
> website gets loaded before the navigation is committed, and the
> side-effects are delayed until activation (the actual navigation to the
> website was committed). The website can know that it is being prerendered
> (document.prerendering) and when it was activated (prerenderingchange
> event, performance.activationStart timing). These APIs have already been
> approved by the previous intent-to-ship for Omnibox prerendering
> 
> .
>
> Note that we are not shipping cross-origin speculation rules, which allows
> a web page to prerender another page under a different domain (external
> site). For details about our web exposed changes shipping plan, please
> consult this doc: Interoperability Roadmap for Shipping Prerender2
> Incrementally
> 
> .
>
>
> Blink component
>
> Internals>Preload>Prerender
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/667
>
> TAG review status
>
> Closed
>
> Risks
> Interoperability and Compatibility
>
> Compatibility
>
> There are some use cases that will need to know whether a page is being
> prerendered by the user agent or navigated by the user, e.g. Ads and
> analytics are likely examples of this.
>
> To solve this challenge, this feature exposes `document.prerendering`
> which indicates if the page is prerendered or not. We understand that
> there’s always a risk of sites, that would benefit from using this API, not
> actually using it.
>
> We believe that this risk is tractable because:
>
> (1) triggering a prerender isn’t an entirely new behavior. E.g. Chrome
> used to have a prerendering feature a long while ago
>  triggered
> by URLs entered in the navigation bar
>
> (2) Similar behaviors are already present in other browsers, e.g. “Preload
> Top Hit” feature in Safari
>
> To give more flexibility to web authors (site owners) who want to
> implement speculation rules, we are already including a header to network
> requests as `Purpose: prefetch` so that origin servers can identify
> requests for prerendered pages and decide how to handle them. A new header
> will be included to provide a CORS safelist alternative using
> `Sec-purpose: prefetch;prerender`
> https://fetch.spec.whatwg.org/#cors-safelisted-request-header
>
> https://chromestatus.com/feature/6247959677108224
>
> There’s also a future risk of the speculation rules specification changing
> :
> including new rules, modifying 

Re: [blink-dev] Fwd: Can't run Web Tests locally on MacOS 12 device

[Dave Tapuska]

FYI... Seems PHP was removed in macOS Monterey. Nico sounds like we need to
revert your patch.

dave

On Thu, Dec 16, 2021 at 5:20 PM Dave Tapuska  wrote:

> I get it too.. I wonder if
> https://source.chromium.org/chromium/chromium/src/+/1156f94e35e73182126f17cf52c45f70a8d4c45b
> is the cause because my default system http conf doesn't have a PHP library.
>
> Nico?
>
> dave.
>
> On Thu, Dec 16, 2021 at 5:01 PM 'Alexis Hétu' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> +blink-dev
>>
>> -- Forwarded message -
>> De : Alexis Hétu 
>> Date: jeu. 16 déc. 2021, à 16 h 42
>> Subject: Can't run Web Tests locally on MacOS 12 device
>> To: 
>>
>>
>> Hi all,
>>
>>   When I try to run Web Tests locally on my 2017 iMac Pro or 2018 Macbook
>> Pro, both on MacOS 12, I get this error:
>>
>> No code signing authority for module at /usr/libexec/apache2/libphp7.so
>> specified in LoadModule directive
>>   How do I fix that?
>>
>> Thanks
>>
>> Alexis
>>
>> --
>> 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/CAPB1aKAp9Nz9Dk%2BFQ5xXL0BmUeYkPAE%2Bjfs54OiRd2JA3wBc7Q%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPB1aKAp9Nz9Dk%2BFQ5xXL0BmUeYkPAE%2Bjfs54OiRd2JA3wBc7Q%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CAHgVhZW56h7a%3DBNL0f01Lsx1eHUBqGjxOwiA%2BC7WpWLTsKR%3D7g%40mail.gmail.com.

Re: [blink-dev] Fwd: Can't run Web Tests locally on MacOS 12 device

[Dave Tapuska]

I get it too.. I wonder if
https://source.chromium.org/chromium/chromium/src/+/1156f94e35e73182126f17cf52c45f70a8d4c45b
is the cause because my default system http conf doesn't have a PHP library.

Nico?

dave.

On Thu, Dec 16, 2021 at 5:01 PM 'Alexis Hétu' via blink-dev <
blink-dev@chromium.org> wrote:

> +blink-dev
>
> -- Forwarded message -
> De : Alexis Hétu 
> Date: jeu. 16 déc. 2021, à 16 h 42
> Subject: Can't run Web Tests locally on MacOS 12 device
> To: 
>
>
> Hi all,
>
>   When I try to run Web Tests locally on my 2017 iMac Pro or 2018 Macbook
> Pro, both on MacOS 12, I get this error:
>
> No code signing authority for module at /usr/libexec/apache2/libphp7.so
> specified in LoadModule directive
>   How do I fix that?
>
> Thanks
>
> Alexis
>
> --
> 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/CAPB1aKAp9Nz9Dk%2BFQ5xXL0BmUeYkPAE%2Bjfs54OiRd2JA3wBc7Q%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/CAHgVhZUbruucBUAEaq3Wu6TzYOrmH5bjYDpQx6mkFSRNBGVRHA%40mail.gmail.com.

Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API

[Dave Tapuska]

For a cross origin renderer the browser process would be involved because
the allow attribute restriction is in one renderer, and the enforcement of
the permission is in the renderer that wants to use it. I do not think it
is difficult to check the policy on the mojo request of the keyboard map in
the browser process. Although you'll likely want some additional response
enums
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/public/mojom/keyboard_lock/keyboard_lock.mojom;l=15;drc=5539ecff898c79b0771340051d62bf81649e448d;bpv=1;bpt=1?q=keyboard_lock.mojom=chromium%2Fchromium%2Fsrc>
.

I ask because we would need to adjust this model for fenced frames
implementation and the enforcement on the browser side better aligns with
our security design.

dave.

On Wed, Oct 27, 2021 at 5:42 PM Anupam Snigdha  wrote:

> I’m not sure if checking that in the browser would make sense here because
> the allow attribute restriction is specified in the DOM and the browser
> process isn’t involved. I did ask this in the slack channel and pretty much
> got the same response that the renderer should be enforcing this check. If
> you have any other ideas though, then please let me know!
>
>
>
> *From:* Dave Tapuska 
> *Sent:* Wednesday, October 27, 2021 2:27 PM
> *To:* Anupam Snigdha 
> *Cc:* slightly...@chromium.org; blink-dev@chromium.org;
> yoavwe...@chromium.org; Bo Cupp ; Scott Low <
> sc...@microsoft.com>; gary...@chromium.org; dome...@chromium.org
> *Subject:* Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and
> Ship: Feature policy for Keyboard API
>
>
>
> I was looking at the implementation of this. Is it possible to move the
> check of the policy to be based in the browser when the map is fetched? As
> of right now the policy enforcement is on the renderer side, so a
> compromised renderer can request the keyboard map.
>
>
>
> dave.
>
>
>
> On Wed, Oct 27, 2021 at 4:53 PM 'Anupam Snigdha' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> Created an issue to get feedback from TAG:
> https://github.com/w3ctag/design-reviews/issues/685
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3ctag%2Fdesign-reviews%2Fissues%2F685=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d08204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268251129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=%2FQQPxFtkWm7mlvljFCgRJqjQYTK7vA6SOUa%2FTKoxDcw%3D=0>
>
> I added this to the webappsec-permission policy:
> https://github.com/w3c/webappsec-permissions-policy/pull/428
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwebappsec-permissions-policy%2Fpull%2F428=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d08204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268261122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=3huSRtIRvPEdaKXk0FRkPNSHWNgxUEtAAqt%2BP3BgWpo%3D=0>,
> but will also create an issue to investigate Permissions API integration.
> Thanks!
>
>
>
> *From:* Alex Russell 
> *Sent:* Thursday, October 21, 2021 12:21 PM
> *To:* blink-dev 
> *Cc:* Yoav Weiss ; Anupam Snigdha <
> sni...@microsoft.com>; blin...@chromium.org ; Bo
> Cupp ; Scott Low ;
> gar...@chromium.org ; Domenic Denicola <
> dome...@chromium.org>
> *Subject:* Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and
> Ship: Feature policy for Keyboard API
>
>
>
> Not consulting the TAG in this instance may have been an error. In
> general, we should be putting things into consistent surfaces that they
> affect. In this case, it seems like we're missing integrations w/ the
> Permissions API.
>
>
>
> I'm LGTM2 on this intent contingent on a commitment to follow up w/ the
> TAG as an FYI and a commitment to investigate Permissions API integration.
>
>
>
> Best Regards,
>
>
>
> Alex
>
>
>
> On Sunday, October 17, 2021 at 10:16:58 PM UTC-7 Yoav Weiss wrote:
>
> LGTM1
>
>
>
> On Sat, Oct 16, 2021 at 12:35 AM Domenic Denicola 
> wrote:
>
> Just chiming in from the sidelines: in general I think this sort of
> exposure via permissions policies is a good thing, and should be encouraged.
>
>
>
> It shouldn't have any additional concerns for an API like this which is
> about exposing information:
>
>- Same-origin iframes can already call
>top.navigator.keyboard.getLayoutMap()
>- The parent can call navigator.keyboard.getLayoutMap(), serialize the
>information, and send it to any cross-origin descendants that it wants to
>receive that information via postMessage().
>
> Per

Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API

[Dave Tapuska]

I was looking at the implementation of this. Is it possible to move the
check of the policy to be based in the browser when the map is fetched? As
of right now the policy enforcement is on the renderer side, so a
compromised renderer can request the keyboard map.

dave.

On Wed, Oct 27, 2021 at 4:53 PM 'Anupam Snigdha' via blink-dev <
blink-dev@chromium.org> wrote:

> Created an issue to get feedback from TAG:
> https://github.com/w3ctag/design-reviews/issues/685
>
> I added this to the webappsec-permission policy:
> https://github.com/w3c/webappsec-permissions-policy/pull/428, but will
> also create an issue to investigate Permissions API integration. Thanks!
>
>
>
> *From:* Alex Russell 
> *Sent:* Thursday, October 21, 2021 12:21 PM
> *To:* blink-dev 
> *Cc:* Yoav Weiss ; Anupam Snigdha <
> sni...@microsoft.com>; blin...@chromium.org ; Bo
> Cupp ; Scott Low ;
> gar...@chromium.org ; Domenic Denicola <
> dome...@chromium.org>
> *Subject:* Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and
> Ship: Feature policy for Keyboard API
>
>
>
> Not consulting the TAG in this instance may have been an error. In
> general, we should be putting things into consistent surfaces that they
> affect. In this case, it seems like we're missing integrations w/ the
> Permissions API.
>
>
>
> I'm LGTM2 on this intent contingent on a commitment to follow up w/ the
> TAG as an FYI and a commitment to investigate Permissions API integration.
>
>
>
> Best Regards,
>
>
>
> Alex
>
>
>
> On Sunday, October 17, 2021 at 10:16:58 PM UTC-7 Yoav Weiss wrote:
>
> LGTM1
>
>
>
> On Sat, Oct 16, 2021 at 12:35 AM Domenic Denicola 
> wrote:
>
> Just chiming in from the sidelines: in general I think this sort of
> exposure via permissions policies is a good thing, and should be encouraged.
>
>
>
> It shouldn't have any additional concerns for an API like this which is
> about exposing information:
>
>- Same-origin iframes can already call
>top.navigator.keyboard.getLayoutMap()
>- The parent can call navigator.keyboard.getLayoutMap(), serialize the
>information, and send it to any cross-origin descendants that it wants to
>receive that information via postMessage().
>
> Permissions policy just streamlines this: same-origin iframes now don't
> need to go via top, and the parent can avoid writing custom code to
> communicate the information to cross-origin descendants, instead replacing
> it with a simple allow="keyboard-map" or allow="keyboard-map
> https://specific-origin;.
>
>
>
> I hope the API owners can support this kind of improvement to the
> platform, not only for this case but in general whenever we introduce
> ergonomic permissions policy-based delegation for any feature.
>
>
>
>
>
> On Fri, Oct 15, 2021 at 6:00 PM 'Anupam Snigdha' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> getLayoutMap() can already be accessed by the top level browsing context
> and I believe it does have fingerprinting concerns: a site can gain
> knowledge of the keyboard layout of the user even before the user has typed
> anything. Try this site switching between French and English keyboard
> layouts: https://fortunate-onyx-wren.glitch.me/french-or-english.html
> .
> The privacy mitigation section
> 
> describes some mitigations we could add for fingerprinting related concerns.
>
>
> I don't think exposing this by default to same origin iframes and allowing
> the top-level browsing context to delegate its authority to use
> getLayoutMap() to other iframes increases the concern any. If I'm thinking
> about that wrong please let me know.
>
>
>
> For the privacy section: I’ll make a change to add permission policy along
> with the top level browsing context restriction to the spec.
>
>
>
> *From:* Yoav Weiss 
> *Sent:* Friday, October 15, 2021 5:46 AM
> *To:* blink-dev 
> *Cc:* Anupam Snigdha ; Bo Cupp ;
> Scott Low ; gar...@chromium.org ;
> Yoav Weiss 
> *Subject:* Re: [EXTERNAL] Re: Intent to Implement and Ship: Feature
> policy for Keyboard API
>
>
>
> Reading through https://wicg.github.io/keyboard-map/#privacy
>