Re: [blink-dev] Intent to Prototype: Web Translation API

[Domenic Denicola]

On Wed, May 1, 2024 at 6:43 AM Alex Russell 
wrote:

> This effort seems worthwhile, and would like to see an explainer that
> discisses the various API options; that might provide some context for the
> security conversation.
>

Did you see the explainer linked in the original post? I'll post it here
again: https://github.com/WICG/translation-api/blob/main/README.md


>
> Best,
>
> Alex
>
> On Tue, Apr 30, 2024, 2:30 AM 'Fergal Daly' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>>
>>
>> On Tue, 30 Apr 2024 at 18:08, Daniel Vogelheim 
>> wrote:
>>
>>> Hi Domenic, et al.,
>>>
>>> This intent came up in the OWP sec review today. We wonder whether
>>> there's XSS potential, and how input with plain text interspersed with tags
>>> is meant to be handled:
>>>
>>> Several of the use cases seem to hint at the input being HTML strings
>>> (e.g. "pages with complicated DOM"). If the intended input would indeed be
>>> HTML strings, and the output is intended to be parsed & inserted into the
>>> DOM, then this basically implements a new XSS factory. In addition to the
>>> existing re-parsing risks, it would add new ones based on translation (e.g.
>>> "" turning into "

Re: [blink-dev] Intent to Ship: Tabbed web apps

[Marijn Kruisselbrink]

I don't think there are major technical reasons, no. With some rough edges
the flagged implementation should more or less work on other
desktop platforms as well. My understanding is that this is largely a
product choice and a choice not to prioritize the remaining engineering
needed to clean up the rough edges on other desktop platforms.

On Mon, May 6, 2024 at 3:29 PM Daniel Herr 
wrote:

> May I ask why? I've tried out the flagged implementation on Chrome OS, and
> I think it is a pretty nice UI paradigm. I don't see any technical reason
> it shouldn't be available on other platforms.
>
> On Monday, May 6, 2024 at 10:30:58 AM UTC-4 Brett Wilson wrote:
>
>> On Mon, May 6, 2024 at 3:02 AM Yoav Weiss (@Shopify) <
>> yoav...@chromium.org> wrote:
>>
>>>
>>>
>>> On Fri, May 3, 2024 at 7:28 PM Brett Wilson  wrote:
>>>
 Contact emailsbre...@chromium.org, alanc...@chromium.org,
 mgi...@chromium.org, loub...@google.com

 Explainer
 https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md

 Specificationhttps://wicg.github.io/manifest-incubations/#dfn-tabbed

 Summary

 Allow web app windows to have a tab strip. This adds a new display mode
 "tabbed" and a new manifest field to allow customizations to the tab strip.


 Blink componentBlink>AppManifest
 

 TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841

 TAG review statusIssues addressed

 Chromium Trial NameWebAppTabStrip

 Link to origin trial feedback summary
 https://github.com/WICG/manifest-incubations/issues

 Origin Trial documentation link
 https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md

 Risks


 Interoperability and Compatibility



 *Gecko*: Defer (
 https://github.com/mozilla/standards-positions/issues/811)

 *WebKit*: No signal (
 https://github.com/WebKit/standards-positions/issues/195)

 *Web developers*: Positive (https://github.com/w3c/manifest/issues/737)

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

 N/A


 Debuggability

 chrome://web-app-internals can be used for debugging, and the new
 manifest field could also be added to the DevTools Application pane.


 Will this feature be supported on all six Blink platforms (Windows,
 Mac, Linux, ChromeOS, Android, and Android WebView)?No

 The origin trial is available on ChromeOS only. Support for other
 desktop platforms is planned.


 Is this feature fully tested by web-platform-tests
 
 ?Yes


 https://github.com/web-platform-tests/wpt/tree/master/appmanifest/display-override-member


 Flag name on chrome://flags
 chrome://flags/#enable-desktop-pwas-tab-strip

 Finch feature nameDesktopPWAsTabStrip

 Requires code in //chrome?True

 Tracking bughttps://issuetracker.google.com/issues/40598974

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

 MeasurementLaunch.WebAppDisplayMode: Tabbed

 Availability expectationFeature is available only on
 Chrome-on-ChromeOS for the foreseeable future.

>>>
>>> This seems a bit contradictory with "Support for other desktop platforms
>>> is planned" above. Are there plans for support beyond CrOS?
>>>

 
>>>
>>>
>> Sorry, the first part was a mistake. Chrome team has requested this not
>> be on other platforms now.
>>
>> Brett
>>
> --
> 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/670da4b2-f0f9-4774-96a9-5cd5f96d168cn%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/CA%2BOSsVYpWsqAWNMx5A_TAiwgqNm_%2BLVWvU%2Bq0yhk9gHzfNPAGw%40mail.gmail.

Re: [blink-dev] Intent to Ship: Document picture-in-picture

['Sahil Talwar' via blink-dev]

My 2 cents - rendering a document PiP would be great, but it wouldn't help 
our use case unless we also have interactivity - the reason we want a 
document is precisely *because* we want the user to be able to interact 
with the PiP. Rendering a document while keeping the video controls would 
be an acceptable fallback, but wouldn't really add too much value for our 
use case. 

On Monday, May 6, 2024 at 5:05:28 PM UTC-4 ari picker wrote:

> +1 for feature parity, but honestly, what I need right now is 
> Android no-video PiP content.
>
> On Thursday, May 2, 2024 at 1:32:16 PM UTC-5 Maratona app wrote:
>
>> Hi Tommy, thank you for replying.
>>
>> My first instinct is not really about what to do on Android, but *feature 
>> parity* with Desktop, for example: 
>> https://dlitsman.github.io/document-pip/ since it's already possible to 
>> make interactive PiP, it seems odd to not have the same experience for 
>> mobile, I know the implementations for Android may be a restriction for 
>> this, so only sharing my thoughts as an *user*. Other APIs like Push 
>> Notifcation, Web Share and Badging all seem to have feature parity, even if 
>> the UI is different for each platform, they are supported somehow. 
>>
>> It feels unmotivated to adopt a new API that will only work for a 
>> specific platform, if there is a security reason behind this, it would be 
>> nice to prompt the user to allow the interaction or not, similar to 
>> allowing/denying Push Notifcations. At least I really enjoy this new API as 
>> a *temporary widget* for mobile devices, since it's not possible to 
>> build native widgets through PWA. I don't wanna be mean, only sharing 
>> initial thoughts and open to understand the real blockers.
>>
>>
>>
>> On Thu, May 2, 2024 at 3:05 PM Tommy Steimel  wrote:
>>
>>> Thanks for the interest in Document PiP on Android!
>>>
>>> Currently, we're not sure that it's feasible to make the pip window 
>>> interactive on Android (e.g. allowing HTML buttons to be clicked). Would an 
>>> API that only allows non-interactive pip (so you'd create an HTML document 
>>> that we'd show but would not receive user inputs) be useful in your 
>>> opinion? Or would it only be a useful API if the user could actually 
>>> interact with it?
>>>
>>> Thanks,
>>> Tommy
>>>
>>> On Wed, May 1, 2024 at 6:11 PM Maratona app  wrote:
>>>
 +1 for PiP on Android, it works really well for features like Pomodoro 
 Timer and To-do tasks and since PWA is growing... it seems a great feature 
 to support. (Currently using PWA -> TWA)

 I know there is an workaround that is to build the feature using a 
 , capture stream and pass to video for original PiP support 
 but 
 it makes really hard to map all interactions.

 Anyway, awesome work !

 On Wednesday, May 1, 2024 at 4:59:37 PM UTC-3 Sahil Talwar wrote:

> +1 - would love PiP on Android as well. 
>
> On Monday, April 29, 2024 at 8:43:26 AM UTC-4 ari picker wrote:
>
>> Thank you for all your work on PiP, it's awesome!
>> I am very interested in PiP on Android. Is any progress being made, 
>> and is there an ETA for PiP landing on Android?
>>
>> On Tuesday, June 13, 2023 at 12:25:11 PM UTC-5 Tommy Steimel wrote:
>>
>>> In the future, we may be able to do something on Android that 
>>> doesn't support input without any change to Android APIs. If we wanted 
>>> input in the PiP window, it would require changes to Android itself. 
>>> That 
>>> said, we haven't seen any interest from web developers for an inputless 
>>> document PiP on Android, and there isn't really anything you can do 
>>> with an 
>>> inputless document PiP that you can't do with a canvas-back video PiP, 
>>> so 
>>> we haven't pursued anything on Android.
>>>
>>> On Tue, Jun 13, 2023 at 7:06 AM Philip Jägenstedt <
>>> foo...@chromium.org> wrote:
>>>
 Thanks Domenic for mentoring and vouching :) I took a very cursory 
 look at the API shape and sent a small fix 
 , 
 thanks for reviewing that.

 The concerns on 
 https://github.com/WebKit/standards-positions/issues/41 are device 
 independence and portability. For the Android support, can you say 
 anything about future expectations? Is this feature simply not 
 important on 
 mobile and it might be a desktop-only API for the foreseeable future, 
 or 
 would Android support make sense for some use cases? If so, does it 
 seem 
 tractable given the requisite changes to Android APIs?

 On Tue, Jun 13, 2023 at 4:16 AM Domenic Denicola <
 dom...@chromium.org> wrote:

> I was the spec mentor for Tommy's work on this feature, and am 
> chiming in to provide the requested spec maturity summary 
> 

Re: [blink-dev] Intent to Ship: Tabbed web apps

[Daniel Herr]

May I ask why? I've tried out the flagged implementation on Chrome OS, and 
I think it is a pretty nice UI paradigm. I don't see any technical reason 
it shouldn't be available on other platforms.

On Monday, May 6, 2024 at 10:30:58 AM UTC-4 Brett Wilson wrote:

> On Mon, May 6, 2024 at 3:02 AM Yoav Weiss (@Shopify)  
> wrote:
>
>>
>>
>> On Fri, May 3, 2024 at 7:28 PM Brett Wilson  wrote:
>>
>>> Contact emailsbre...@chromium.org, alanc...@chromium.org, 
>>> mgi...@chromium.org, loub...@google.com
>>>
>>> Explainer
>>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>>
>>> Specificationhttps://wicg.github.io/manifest-incubations/#dfn-tabbed
>>>
>>> Summary
>>>
>>> Allow web app windows to have a tab strip. This adds a new display mode 
>>> "tabbed" and a new manifest field to allow customizations to the tab strip.
>>>
>>>
>>> Blink componentBlink>AppManifest 
>>> 
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841
>>>
>>> TAG review statusIssues addressed
>>>
>>> Chromium Trial NameWebAppTabStrip
>>>
>>> Link to origin trial feedback summary
>>> https://github.com/WICG/manifest-incubations/issues
>>>
>>> Origin Trial documentation link
>>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> *Gecko*: Defer (
>>> https://github.com/mozilla/standards-positions/issues/811)
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/195)
>>>
>>> *Web developers*: Positive (https://github.com/w3c/manifest/issues/737)
>>>
>>> *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?
>>>
>>> N/A
>>>
>>>
>>> Debuggability
>>>
>>> chrome://web-app-internals can be used for debugging, and the new 
>>> manifest field could also be added to the DevTools Application pane.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>>> Linux, ChromeOS, Android, and Android WebView)?No
>>>
>>> The origin trial is available on ChromeOS only. Support for other 
>>> desktop platforms is planned.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ?Yes
>>>
>>>
>>> https://github.com/web-platform-tests/wpt/tree/master/appmanifest/display-override-member
>>>
>>>
>>> Flag name on chrome://flagschrome://flags/#enable-desktop-pwas-tab-strip
>>>
>>> Finch feature nameDesktopPWAsTabStrip
>>>
>>> Requires code in //chrome?True
>>>
>>> Tracking bughttps://issuetracker.google.com/issues/40598974
>>>
>>> Launch bughttps://launch.corp.google.com/launch/4253814
>>>
>>> MeasurementLaunch.WebAppDisplayMode: Tabbed
>>>
>>> Availability expectationFeature is available only on Chrome-on-ChromeOS 
>>> for the foreseeable future.
>>>
>>
>> This seems a bit contradictory with "Support for other desktop platforms 
>> is planned" above. Are there plans for support beyond CrOS?
>>
>>>
>>> 
>>
>>
> Sorry, the first part was a mistake. Chrome team has requested this not be 
> on other platforms now.
>
> Brett 
>

-- 
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/670da4b2-f0f9-4774-96a9-5cd5f96d168cn%40chromium.org.

[blink-dev] Web-Facing Change PSA: Corrected timing for low-lead-time prefetches

[Jeremy Roman]

Chrome 126 (and corresponding releases from other Chromium browser vendors)
will reflect a bugfix to the reporting of the responseStart timestamp for
speculation rules prefetched navigation. It may cause a shift in some
metrics, notably an increase in computed time to first byte (or similar
metrics) and a corresponding decrease in metrics measured from after the
response body starts.

See this document for more detail:
https://docs.google.com/document/d/1oESLkgpXysbl_FQMZ5Ahj3xtHW6d_UTcB-StJrS7a1U/preview

This is intended as a bugfix, but I am mentioning it more broadly because
of the potential to look a little confusing in real user metrics.

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

Re: [blink-dev] Intent to Ship: Document picture-in-picture

[ari picker]

+1 for feature parity, but honestly, what I need right now is 
Android no-video PiP content.

On Thursday, May 2, 2024 at 1:32:16 PM UTC-5 Maratona app wrote:

> Hi Tommy, thank you for replying.
>
> My first instinct is not really about what to do on Android, but *feature 
> parity* with Desktop, for example: 
> https://dlitsman.github.io/document-pip/ since it's already possible to 
> make interactive PiP, it seems odd to not have the same experience for 
> mobile, I know the implementations for Android may be a restriction for 
> this, so only sharing my thoughts as an *user*. Other APIs like Push 
> Notifcation, Web Share and Badging all seem to have feature parity, even if 
> the UI is different for each platform, they are supported somehow. 
>
> It feels unmotivated to adopt a new API that will only work for a specific 
> platform, if there is a security reason behind this, it would be nice to 
> prompt the user to allow the interaction or not, similar to 
> allowing/denying Push Notifcations. At least I really enjoy this new API as 
> a *temporary widget* for mobile devices, since it's not possible to build 
> native widgets through PWA. I don't wanna be mean, only sharing initial 
> thoughts and open to understand the real blockers.
>
>
>
> On Thu, May 2, 2024 at 3:05 PM Tommy Steimel  wrote:
>
>> Thanks for the interest in Document PiP on Android!
>>
>> Currently, we're not sure that it's feasible to make the pip window 
>> interactive on Android (e.g. allowing HTML buttons to be clicked). Would an 
>> API that only allows non-interactive pip (so you'd create an HTML document 
>> that we'd show but would not receive user inputs) be useful in your 
>> opinion? Or would it only be a useful API if the user could actually 
>> interact with it?
>>
>> Thanks,
>> Tommy
>>
>> On Wed, May 1, 2024 at 6:11 PM Maratona app  wrote:
>>
>>> +1 for PiP on Android, it works really well for features like Pomodoro 
>>> Timer and To-do tasks and since PWA is growing... it seems a great feature 
>>> to support. (Currently using PWA -> TWA)
>>>
>>> I know there is an workaround that is to build the feature using a 
>>> , capture stream and pass to video for original PiP support but 
>>> it makes really hard to map all interactions.
>>>
>>> Anyway, awesome work !
>>>
>>> On Wednesday, May 1, 2024 at 4:59:37 PM UTC-3 Sahil Talwar wrote:
>>>
 +1 - would love PiP on Android as well. 

 On Monday, April 29, 2024 at 8:43:26 AM UTC-4 ari picker wrote:

> Thank you for all your work on PiP, it's awesome!
> I am very interested in PiP on Android. Is any progress being made, 
> and is there an ETA for PiP landing on Android?
>
> On Tuesday, June 13, 2023 at 12:25:11 PM UTC-5 Tommy Steimel wrote:
>
>> In the future, we may be able to do something on Android that doesn't 
>> support input without any change to Android APIs. If we wanted input in 
>> the 
>> PiP window, it would require changes to Android itself. That said, we 
>> haven't seen any interest from web developers for an inputless document 
>> PiP 
>> on Android, and there isn't really anything you can do with an inputless 
>> document PiP that you can't do with a canvas-back video PiP, so we 
>> haven't 
>> pursued anything on Android.
>>
>> On Tue, Jun 13, 2023 at 7:06 AM Philip Jägenstedt <
>> foo...@chromium.org> wrote:
>>
>>> Thanks Domenic for mentoring and vouching :) I took a very cursory 
>>> look at the API shape and sent a small fix 
>>> , 
>>> thanks for reviewing that.
>>>
>>> The concerns on 
>>> https://github.com/WebKit/standards-positions/issues/41 are device 
>>> independence and portability. For the Android support, can you say 
>>> anything about future expectations? Is this feature simply not 
>>> important on 
>>> mobile and it might be a desktop-only API for the foreseeable future, 
>>> or 
>>> would Android support make sense for some use cases? If so, does it 
>>> seem 
>>> tractable given the requisite changes to Android APIs?
>>>
>>> On Tue, Jun 13, 2023 at 4:16 AM Domenic Denicola <
>>> dom...@chromium.org> wrote:
>>>
 I was the spec mentor for Tommy's work on this feature, and am 
 chiming in to provide the requested spec maturity summary 
 
 .

 I'm very happy with the spec work for this feature. Tommy worked 
 hard to incorporate all my feedback about how to ensure everything was 
 rigorously defined, and integrated well with existing

[blink-dev] Intent to Ship: Protected Audience: reporting timeouts & multiple-bids

[Paul Jensen]

Contact emails

pauljen...@chromium.org


Explainer

Protected Audience reporting timeouts:
https://github.com/WICG/turtledove/pull/1101

Protected Audience multiple-bids:
https://github.com/WICG/turtledove/pull/1048


Specification

Protected Audience reporting timeouts:
https://github.com/WICG/turtledove/pull/1102

Protected Audience multiple-bids:
https://github.com/WICG/turtledove/pull/1138


Summary

Protected Audience (PA) reporting timeouts:

After a PA auction finishes selecting an ad and that ad is allowed to start
rendering, the browser then runs a JavaScript function from the seller(s)
and winning buyer to assemble reports that are sent back to their servers.
These functions are currently given 50ms to run, after which they're
aborted. We've heard feedback from users of the API that 50ms may not be
sufficient to assemble the reports and may result in broken billing and
other basic functionality, resulting in lower website revenue.  We’re
proposing making the timeout configurable up to 5s. (This JavaScript
generally runs in a separate process, i.e. off the main thread.)

Protected Audience multiple-bids:

Presently buyers participating in PA ad selection auctions are only allowed
to return one bid per interest group stored on a user's device. This has a
couple downsides:

   1.

   When that one bid does not pass the k-anonymity threshold, the bid
   generation logic must be invoked again which can be slow, potentially
   doubling auction runtime.
   2.

   This preferences adtechs that store more interest groups on device as a
   way to get more bids into the auction. Many interest groups on device is
   something we publicly have stated is undesirable:
   
https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/latency#fewer_interest_group_owners

To fix this we're allowing bidding scripts to return multiple bids.


Blink component

Blink>InterestGroups



TAG review

For Protected Audience: https://github.com/w3ctag/design-reviews/issues/723


TAG review status

Completed for Protected Audience, resolved unsatisfied.


RisksInteroperability and Compatibility

Both features represent optional new behavior that shouldn’t break existing
usage.


Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked in
the Mozilla forum here
, and in the
Webkit forum here 
.


Edge: Edge has announced plans to support the Ad Selection API
 which
shares much of its API surface with Protected Audience.


Web developers:

Protected Audience reporting timeouts: Multiple companies requesting on Github
issue  and WICG meeting
though notes

are missing several comments from others.

Protected Audience multiple-bids: 3+ companies requesting on Github issue
, discussed in 6 different WICG
meetings

.


Debuggability

PA reporting and bidding scripts are debuggable in DevTools.  Generated
bids also show up in the Application -> Storage -> Interest Groups DevTools
pane.


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, ChromeOS, Android, and Android WebView)?

It will be supported on all platforms that support Protected Audience, so
all but WebView.


Is this feature fully tested by web-platform-tests

?

We plan to land web-platform-tests for both features shortly.


Flag name on chrome://flags

None


Finch feature name

FledgeReportingTimeout, FledgeMultiBid


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop and Android in M124.


Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5095020001755136


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

Re: [blink-dev] Unable to write Serialized SkPicture into a File

['Vladimir Levin' via blink-dev]

Hey Steven,

The path to convert information necessary for rendering into SkPictures may
or may not exist in the Chromium codebase, but it's certainly not actively
maintained or developed. Ultimately all information is available, but it
may come from several different sources.

For images, for example, it's likely that the Skia information stores them
in an encoded format backed by one of the decoders in Blink. The cc
codebase has classes that extracts the encoded information and schedules
decoding and upload which is then rasterized and presented as necessary. It
isn't necessarily trivial to convert this whole process to a few Skia
commands, and largely depends on what you're looking to accomplish.

Here's a thread from skia-discuss@ roughly talking about the same thing:
https://groups.google.com/g/skia-discuss/c/hd1ZCRkM4OA. As Brian mentions
there, SkPictures are an important primitive (as are other Skia commands)
but it's not the only thing. Chromium uses display lists and paint ops to
draw its contents. You can probably look at the serialization code as the
closest thing that does all the right serialization (this is used in Out of
Process Rasterization):
https://source.chromium.org/chromium/chromium/src/+/main:cc/paint/paint_op_buffer_serializer.h;l=21;drc=e09826065bb5964f247be565890dcabda54ac9e3.
As I mentioned previously in a different thread, this won't help you with
images. Those need to be either decoded and serialized or serialized in
encoded form and dealt with on the client side.

As Ken also mentioned, graphics-dev (and also skia-discuss) may be better
forums for this type of discussion

Thanks,
Vlad

On Mon, May 6, 2024 at 3:32 AM Steven Whelan 
wrote:

> Hi,
> Also found out that through paint_op_helper's tostring method
> 
> , all the PaintOps related information can be printed. It includes all the
> information- coordinates, paint info etc.
> Wondering, can these be converted directly into SKIA commands to render
> the page?
> Please help me finalize the correct approach.
>
>
> On Sun, May 5, 2024 at 3:49 AM Ken Russell  wrote:
>
>> I'm not sure exactly how SkPicture recording works - please join
>> https://groups.google.com/a/chromium.org/g/graphics-dev and email
>> graphics-...@chromium.org .
>>
>> -Ken
>>
>>
>>
>> On Sat, May 4, 2024 at 6:21 AM Steven Whelan 
>> wrote:
>>
>>> Hi I am able to write the serialized SKData (captured from Serialize
>>> method of  paint_op_buffer_serializer
>>> 
>>>  as
>>> shown in the first mail) to a file and was also able to use this file for
>>> playback on canvas.
>>> However, it only played back the text. How do I ensure that images also
>>> get captured in my SKPicture recording? Do I have to have multiple
>>> SKPictureRecording at multiple places?
>>> Goal : To record everything being written on a canvas while loading  a
>>> page so that it can be played back on another browser.
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>> On Thursday, May 2, 2024 at 5:34:48 AM UTC+5:30 k...@chromium.org wrote:
>>>
 Yes - you can confirm this yourself - but we strongly recommend against
 disabling the renderer sandbox.


 On Tue, Apr 30, 2024 at 10:46 PM Steven Whelan 
 wrote:

> Yes, trying to do this in renderer process. Would it work if I run
> Chromium with --nosandbox flag.
>
> On Tue, Apr 30, 2024, 21:58 Ken Russell  wrote:
>
>> Are you trying to do this within Chrome's renderer or GPU processes?
>> If so, the sandbox will prevent you from touching the local disk. You 
>> would
>> need to extend the sandbox policies to allow writing to a directory on 
>> disk
>> - some place that will not collide with other programs, so that if a bad
>> actor causes data to be written to that directory, no harm will be 
>> caused.
>> See
>> https://source.chromium.org/chromium/chromium/src/+/main:sandbox/policy/mac/
>> for the macOS sandbox policies.
>>
>> -Ken
>>
>>
>>
>> On Tue, Apr 30, 2024 at 8:59 AM Steven Whelan 
>> wrote:
>>
>>> Hi
>>> I have modified the Serialize
>>> 
>>>  method
>>> to Record all PaintOp as SKPicture.
>>> I want to replay this SKPicture on a remote browser. So, I am trying
>>> to save this SKPicture to a file, but I am not able to do so, since
>>> file.isOpen gives false.
>>> Please help here
>>>
>>> void PaintOpBufferSerializer::Serialize(const PaintOpBuffer& buffer,

Re: [blink-dev] Intent to Ship: Tabbed web apps

[Brett Wilson]

On Mon, May 6, 2024 at 3:02 AM Yoav Weiss (@Shopify) 
wrote:

>
>
> On Fri, May 3, 2024 at 7:28 PM Brett Wilson  wrote:
>
>> Contact emailsbre...@chromium.org, alancut...@chromium.org,
>> mgi...@chromium.org, loubr...@google.com
>>
>> Explainer
>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>
>> Specificationhttps://wicg.github.io/manifest-incubations/#dfn-tabbed
>>
>> Summary
>>
>> Allow web app windows to have a tab strip. This adds a new display mode
>> "tabbed" and a new manifest field to allow customizations to the tab strip.
>>
>>
>> Blink componentBlink>AppManifest
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841
>>
>> TAG review statusIssues addressed
>>
>> Chromium Trial NameWebAppTabStrip
>>
>> Link to origin trial feedback summary
>> https://github.com/WICG/manifest-incubations/issues
>>
>> Origin Trial documentation link
>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> *Gecko*: Defer (https://github.com/mozilla/standards-positions/issues/811
>> )
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/195)
>>
>> *Web developers*: Positive (https://github.com/w3c/manifest/issues/737)
>>
>> *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?
>>
>> N/A
>>
>>
>> Debuggability
>>
>> chrome://web-app-internals can be used for debugging, and the new
>> manifest field could also be added to the DevTools Application pane.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?No
>>
>> The origin trial is available on ChromeOS only. Support for other desktop
>> platforms is planned.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>>
>> https://github.com/web-platform-tests/wpt/tree/master/appmanifest/display-override-member
>>
>>
>> Flag name on chrome://flagschrome://flags/#enable-desktop-pwas-tab-strip
>>
>> Finch feature nameDesktopPWAsTabStrip
>>
>> Requires code in //chrome?True
>>
>> Tracking bughttps://issuetracker.google.com/issues/40598974
>>
>> Launch bughttps://launch.corp.google.com/launch/4253814
>>
>> MeasurementLaunch.WebAppDisplayMode: Tabbed
>>
>> Availability expectationFeature is available only on Chrome-on-ChromeOS
>> for the foreseeable future.
>>
>
> This seems a bit contradictory with "Support for other desktop platforms
> is planned" above. Are there plans for support beyond CrOS?
>
>>
>> 
>
>
Sorry, the first part was a mistake. Chrome team has requested this not be
on other platforms now.

Brett

-- 
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/CABiGVV8N3PxBDPFGkE5M_-g22qWnQGhNq3sd%2BDxCgCmCN%3DS4Xg%40mail.gmail.com.

Re: [blink-dev] Running WebGPU on Amazon EC2 Windows instance

['François Beaufort' via blink-dev]

https://developer.chrome.com/blog/supercharge-web-ai-testing is the first
part.


On Mon, May 6, 2024 at 4:23 PM François Beaufort 
wrote:

> Hello Wen Han,
> May I recommend
> https://developer.chrome.com/docs/web-platform/webgpu/colab-headless if
> you haven't read it yet?
>
> On Mon, May 6, 2024 at 4:20 PM wenhan chong  wrote:
>
>> Hi All,
>>
>> I am trying to run WebGPU on an Amazon EC2 Windows instance but I am
>> unable to get the browser to detect WebGPU. I have nvidia drivers and
>> chrome v124 installed on the instance but requestAdapter still fails for
>> WebGPU. I can render WebGL2 just fine. Are there any additional flags or
>> libraries I need to install to be able to use WebGPU on EC2?
>>
>> Regards,
>> Wen Han
>>
>> --
>> 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/6084010a-6302-4c1d-937d-d2c65ad45663n%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/CAPpwU5JXf5jcCSMrz_eT4UMFmEyDE4GZ4RiXg0WxDoOk4LmN2Q%40mail.gmail.com.

Re: [blink-dev] Running WebGPU on Amazon EC2 Windows instance

['François Beaufort' via blink-dev]

Hello Wen Han,
May I recommend
https://developer.chrome.com/docs/web-platform/webgpu/colab-headless if you
haven't read it yet?

On Mon, May 6, 2024 at 4:20 PM wenhan chong  wrote:

> Hi All,
>
> I am trying to run WebGPU on an Amazon EC2 Windows instance but I am
> unable to get the browser to detect WebGPU. I have nvidia drivers and
> chrome v124 installed on the instance but requestAdapter still fails for
> WebGPU. I can render WebGL2 just fine. Are there any additional flags or
> libraries I need to install to be able to use WebGPU on EC2?
>
> Regards,
> Wen Han
>
> --
> 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/6084010a-6302-4c1d-937d-d2c65ad45663n%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/CAPpwU5J%2BgAa1te%2BjsOad1ncrHjtDRJw5pW-zwL%2BNAB8syAc3qw%40mail.gmail.com.

[blink-dev] SkImage from DrawImageRectOp with isPaintworklet=false

[Steven Whelan]

In paint_op_buffer_serializer 

 the 
drawImageRect op  has an if condition for PaintWorklet.
While rendering google.com, saw that most of the drawImageRect ops are not 
PaintWorklet.

To replay these operations remotely, I would need skImage for each 
drawImageRectOp.
How can I get the skImage from ops that are not PaintWorklets?

Where are they actually getting rendered ?

-- 
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/5f9ac801-813d-47f4-bb70-9659111f76b7n%40chromium.org.

Re: [blink-dev] Intent to Ship: Tabbed web apps

[Yoav Weiss (@Shopify)]

On Fri, May 3, 2024 at 7:28 PM Brett Wilson  wrote:

> Contact emailsbre...@chromium.org, alancut...@chromium.org,
> mgi...@chromium.org, loubr...@google.com
>
> Explainer
> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>
> Specificationhttps://wicg.github.io/manifest-incubations/#dfn-tabbed
>
> Summary
>
> Allow web app windows to have a tab strip. This adds a new display mode
> "tabbed" and a new manifest field to allow customizations to the tab strip.
>
>
> Blink componentBlink>AppManifest
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841
>
> TAG review statusIssues addressed
>
> Chromium Trial NameWebAppTabStrip
>
> Link to origin trial feedback summary
> https://github.com/WICG/manifest-incubations/issues
>
> Origin Trial documentation link
> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: Defer (https://github.com/mozilla/standards-positions/issues/811)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/195)
>
> *Web developers*: Positive (https://github.com/w3c/manifest/issues/737)
>
> *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?
>
> N/A
>
>
> Debuggability
>
> chrome://web-app-internals can be used for debugging, and the new manifest
> field could also be added to the DevTools Application pane.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?No
>
> The origin trial is available on ChromeOS only. Support for other desktop
> platforms is planned.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
>
> https://github.com/web-platform-tests/wpt/tree/master/appmanifest/display-override-member
>
>
> Flag name on chrome://flagschrome://flags/#enable-desktop-pwas-tab-strip
>
> Finch feature nameDesktopPWAsTabStrip
>
> Requires code in //chrome?True
>
> Tracking bughttps://issuetracker.google.com/issues/40598974
>
> Launch bughttps://launch.corp.google.com/launch/4253814
>
> MeasurementLaunch.WebAppDisplayMode: Tabbed
>
> Availability expectationFeature is available only on Chrome-on-ChromeOS
> for the foreseeable future.
>

This seems a bit contradictory with "Support for other desktop platforms is
planned" above. Are there plans for support beyond CrOS?


>
>
> Adoption expectationFeature is used by specific partner(s) to provide
> functionality within 12 months of launch in Chrome. May be of interest to a
> handful of PWA authors primarily in the productivity space.
>
> Adoption planWorking with a small number of partners directly.
>
> 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?
> N/A
>
> Sample links
> https://paint-rightful-patch.glitch.me
>
> Estimated milestones
> Shipping on desktop 126
> Origin trial desktop first 118
> Origin trial desktop last 126
> Origin trial extension 1 end milestone 126
>
> 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).
> Chromium implementation currently does not parse string-form URL patterns
> as required by the spec. Marked "at risk". (
> https://github.com/WICG/manifest-incubations/issues/97)
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5128143454076928?gate=6176288199409664
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/IvfIkjvQYuY/m/cixwOyEeAAAJ
>  Intent
> to Experiment:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/m16m2TEq-NM/m/0Bc10numCgAJ
> Intent to Extend Experiment 1:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/5aRDL-E9olQ/m/Pb7ECdcpAAAJ
> Intent to Ship:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/5aRDL-E9olQ/m/Pb7ECdcpAAAJ
>
>
> 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/CABiGVV9MstA8bLmUTLkkfTjeYK8bb7fkhyKL_OMt_d

Re: [blink-dev] Unable to write Serialized SkPicture into a File

[Steven Whelan]

Hi,
Also found out that through paint_op_helper's tostring method

, all the PaintOps related information can be printed. It includes all the
information- coordinates, paint info etc.
Wondering, can these be converted directly into SKIA commands to render the
page?
Please help me finalize the correct approach.


On Sun, May 5, 2024 at 3:49 AM Ken Russell  wrote:

> I'm not sure exactly how SkPicture recording works - please join
> https://groups.google.com/a/chromium.org/g/graphics-dev and email
> graphics-...@chromium.org .
>
> -Ken
>
>
>
> On Sat, May 4, 2024 at 6:21 AM Steven Whelan 
> wrote:
>
>> Hi I am able to write the serialized SKData (captured from Serialize
>> method of  paint_op_buffer_serializer
>> 
>>  as
>> shown in the first mail) to a file and was also able to use this file for
>> playback on canvas.
>> However, it only played back the text. How do I ensure that images also
>> get captured in my SKPicture recording? Do I have to have multiple
>> SKPictureRecording at multiple places?
>> Goal : To record everything being written on a canvas while loading  a
>> page so that it can be played back on another browser.
>>
>> Thanks
>>
>>
>>
>>
>> On Thursday, May 2, 2024 at 5:34:48 AM UTC+5:30 k...@chromium.org wrote:
>>
>>> Yes - you can confirm this yourself - but we strongly recommend against
>>> disabling the renderer sandbox.
>>>
>>>
>>> On Tue, Apr 30, 2024 at 10:46 PM Steven Whelan 
>>> wrote:
>>>
 Yes, trying to do this in renderer process. Would it work if I run
 Chromium with --nosandbox flag.

 On Tue, Apr 30, 2024, 21:58 Ken Russell  wrote:

> Are you trying to do this within Chrome's renderer or GPU processes?
> If so, the sandbox will prevent you from touching the local disk. You 
> would
> need to extend the sandbox policies to allow writing to a directory on 
> disk
> - some place that will not collide with other programs, so that if a bad
> actor causes data to be written to that directory, no harm will be caused.
> See
> https://source.chromium.org/chromium/chromium/src/+/main:sandbox/policy/mac/
> for the macOS sandbox policies.
>
> -Ken
>
>
>
> On Tue, Apr 30, 2024 at 8:59 AM Steven Whelan 
> wrote:
>
>> Hi
>> I have modified the Serialize
>> 
>>  method
>> to Record all PaintOp as SKPicture.
>> I want to replay this SKPicture on a remote browser. So, I am trying
>> to save this SKPicture to a file, but I am not able to do so, since
>> file.isOpen gives false.
>> Please help here
>>
>> void PaintOpBufferSerializer::Serialize(const PaintOpBuffer& buffer,
>> const std::vector*
>> offsets,
>> const Preamble& preamble) {
>>   DCHECK_EQ(serialized_op_count_, 0u);
>>
>>   std::unique_ptr canvas = MakeAnalysisCanvas(options_);
>>   // These PlaybackParams use the initial (identity) canvas matrix,
>> as they are
>>   // only used for serializing the preamble and the initial save /
>> final restore
>>   // SerializeBuffer will create its own PlaybackParams based on the
>>
>>  * SkPictureRecorder recorder;*
>>  * SkCanvas* recordingCanvas =
>> recorder.beginRecording(canvas->getLocalClipBounds()); *
>>   // post-preamble canvas.
>>   PlaybackParams params = MakeParams(canvas.get());
>>   int save_count = canvas->getSaveCount();
>>   Save(canvas.get(), params);
>>   SerializePreamble(canvas.get(), preamble, params);
>>   SerializeBuffer(canvas.get(), buffer, offsets);
>>   *SerializeBuffer(recordingCanvas, buffer, offsets);*
>>
>>
>> *sk_sp picture = recorder.finishRecordingAsPicture();
>> SkSerialProcs sProcs;  sk_sp readableData =
>> picture->serialize(&sProcs);*
>>   // Assuming the byte array is stored in the 'data' field of the
>> SkData object
>>   const void* data = readableData->data();
>>   size_t size = readableData->size();
>>
>> * *
>>   /*sk_sp receievedData = SkData::MakeWithoutCopy(data, size);
>>   sk_sp copy =
>>   SkPicture::MakeFromData(receievedData->data(),
>> receievedData->size());
>>   copy->playback(recordingCanvas);*/
>>   RestoreToCount(canvas.get(), save_count, params);
>> }
>>
>> --
>> You received this message because you are subscribed to the