Hi Muhammad, I have filed this bug for the issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1481485. We would appreciate it if you could describe your set-up with more detail in this bug. Have you registered for the deprecation trial described here?: https://developer.chrome.com/en/blog/storage-partitioning-deprecation-trial/
Thanks, Kyra On Mon, Sep 11, 2023 at 10:48 PM Muhammad Ahmed Mallick <amall...@folio3.com> wrote: > Hi All, > I'm also facing challenges with the current situation. We're loading my > own website within the Chrome extension, and we manage the user's login > state (tokens) on my website. The extension's iframe is supposed to > retrieve the token from local storage, but it's currently broken. It's not > feasible to ask the user to log in twice just to access the extension's > content. > > Please let me know if there is any solution to get it fixed asap. > > Thanks > Ahmed > > On Wednesday, September 6, 2023 at 2:03:55 PM UTC+5 Kyra Seevers wrote: > >> Hi all, >> >> Another quick update: we began the rollout to 50% stable today. >> >> We will roll-out to 100% of Stable users on approximately Sept. 20th, >> 2023. >> >> Thanks, >> Kyra >> >> On Thu, Aug 24, 2023 at 3:48 PM Mike Taylor <mike...@chromium.org> wrote: >> >>> I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=1475667 >>> - it would be great if you both could give more context about your embedded >>> application, and how you deal with Safari and Firefox as comments in the >>> bug (same goes for anyone else facing this issue). >>> >>> thanks, >>> Mike >>> On 8/24/23 8:45 AM, Tim Williams wrote: >>> >>> We have the same situation as Junji here. >>> For us, it means that our solution would be broken across all websites >>> since the platforms are using our iframe URL and we have 0 ability to >>> inject code at their top Domain (nor do we want to). >>> On Wednesday, August 23, 2023 at 8:33:57 PM UTC+3 Junji Genesys wrote: >>> >>>> Our application has no access to the top-level context, so there is no >>>> way for us to include our third-party trial script in the top-level >>>> context. >>>> We basically provide Salesforce with our embedded client URL, and they >>>> use it to load and embed our client in their iframe. >>>> >>>> On Wed, Aug 23, 2023 at 11:30 AM Mike Taylor <mike...@chromium.org> >>>> wrote: >>>> >>>>> Yes, if you sign up for a 3rd party token and inject that into the >>>>> site embedding your iframe before your iframe is created, that will give >>>>> you access to unpartitioned storage (until the Deprecation Trial expires). >>>>> >>>>> Here's a demo that injects an 3P origin trial token then creates an >>>>> iframe: >>>>> >>>>> https://rogue-lace-join.glitch.me/ >>>>> >>>>> And the relevant source files: >>>>> >>>>> https://glitch.com/edit/#!/rogue-lace-join?path=index.html%3A9%3A8 >>>>> https://miketaylr.com/misc/3pspdt.js >>>>> >>>>> Feel free to reach out to me off-list to discuss more or if you have >>>>> any further questions. >>>>> On 8/22/23 11:40 PM, Yoav Weiss wrote: >>>>> >>>>> Is your application running script in the top level context? Since the >>>>> deprecation trial is implemented as a third-party origin trial, you may be >>>>> able to sign up as a third party. >>>>> >>>>> On Tue, Aug 22, 2023, 23:48 Junji Genesys <junji....@gmail.com> wrote: >>>>> >>>>>> Hello Kyra, >>>>>> >>>>>> Thank you for communicating about the rollout plan for the storage >>>>>> partitioning. >>>>>> >>>>>> We've found that the new storage partitioning behavior has impacted >>>>>> our product, which is a web client application embedded in an iframe >>>>>> inside >>>>>> Salesforce and provides call center agents functionality such as handling >>>>>> phone calls. We use browser-based phone (WebRTC phone) that can pop out >>>>>> as >>>>>> a separate window, which communicates with the embedded client frame via >>>>>> localStorage and BroadcastChannel. The new storage partitioning >>>>>> restriction >>>>>> blocks this communication as our application is running as an embedded >>>>>> iframe with a top-level domain that differs from our browser phone >>>>>> running >>>>>> in a popped out window. Our browser phone does not work properly in that >>>>>> scenario, and as a result, users are not able to answer their calls. Many >>>>>> of our customers have started reporting this issue, and it is currently >>>>>> our >>>>>> top priority to address this issue given its time-sensitive nature. >>>>>> >>>>>> We've also learned about an existence of the experimental flag, two >>>>>> relevant enterprise policies and the deprecation trial for disabling this >>>>>> new change as a temporary measure. We're especially interested in the >>>>>> deprecation trial, but that can be activated only by the top-level domain >>>>>> site and there is no way for the embedded content in an iframe to >>>>>> activate >>>>>> the deprecation trial. >>>>>> >>>>>> I've contacted Salesforce support to see if they can sign-up and >>>>>> activate the deprecation trial, but they asked me to reach out to Chrome >>>>>> team to see if Chrome team can create a ticket with Salesforce and help >>>>>> them with the deprecation trial for unpartitioned third-party storage. >>>>>> >>>>>> Would you be able to work with Salesforce for the deprecation trial >>>>>> in their environment? >>>>>> Also, since you might have dealt with other third-party vendors >>>>>> before, what suggestions do you have on how to approach a situation like >>>>>> this? >>>>>> I greatly appreciate your prompt response and help on this matter. >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Junji >>>>>> >>>>>> On Monday, August 14, 2023 at 1:50:24 PM UTC-4 Kyra Seevers wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Quick update: we began the rollout to 10% stable today. >>>>>>> >>>>>>> The new rollout schedule is approximately: >>>>>>> Stable 50%: Aug 28th >>>>>>> Stable 100%: Sept 11th >>>>>>> >>>>>>> On Wed, Aug 2, 2023 at 11:18 AM Tim Williams <tim.j.w...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hey Mike, >>>>>>>> Thanks for the update! >>>>>>>> I totally understand your timing, and it's on us to blame for >>>>>>>> missing this out (or at least we thought that it would be together >>>>>>>> with the >>>>>>>> cookie update which was postponed several times). >>>>>>>> >>>>>>>> Anyway, I encourage you to postpone the timing until the trial bug >>>>>>>> will be fixed to enable us, and other developers who would like to use >>>>>>>> the >>>>>>>> trial meta tag to be able to do so. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> On Monday, July 31, 2023 at 7:55:33 PM UTC+3 Mike Taylor wrote: >>>>>>>> >>>>>>>>> Thanks for the bug report! We'll triage it in our regular meeting >>>>>>>>> tomorrow. >>>>>>>>> >>>>>>>>> And yes, your understanding of the timing is correct (we've been >>>>>>>>> working >>>>>>>>> on this project for 2+ years >>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/WXNzM0WiQ-s/m/l10NGhaoAQAJ>, >>>>>>>>> and in dev-trial since September >>>>>>>>> <https://developer.chrome.com/en/blog/storage-partitioning-dev-trial/> >>>>>>>>> of last year). Note that advancing to a higher percentage will depend >>>>>>>>> on >>>>>>>>> the stability and web-compatibility of partitioned 3P storage. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Mike >>>>>>>>> On 7/30/23 12:04 PM, Tim Williams wrote: >>>>>>>>> >>>>>>>>> I've submitted the following bug: >>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1468811 >>>>>>>>> since the trial isn't working while I did everything right. >>>>>>>>> >>>>>>>>> On Saturday, July 29, 2023 at 2:52:22 AM UTC+3 Tim Williams wrote: >>>>>>>>> >>>>>>>>>> Hey There, >>>>>>>>>> I am truly struggling to understand the timing here. >>>>>>>>>> Currently, the partitioning is under a flag. >>>>>>>>>> Are you saying that the flag would be turned on to 100% of >>>>>>>>>> Desktop and Android users on Sept 8th THIS YEAR?? >>>>>>>>>> >>>>>>>>>> That's a huge and extremely fast change, wow. >>>>>>>>>> >>>>>>>>>> On Thursday, July 27, 2023 at 10:33:01 PM UTC+3 Kyra Seevers >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> M115 is now being served at 100% on Desktop and Android. We will >>>>>>>>>>> begin the rollout to Stable 1% shortly - the approximate rollout >>>>>>>>>>> schedule >>>>>>>>>>> is now as follows: >>>>>>>>>>> >>>>>>>>>>> Stable 1%: July 28th >>>>>>>>>>> Stable 10%: Aug 11th >>>>>>>>>>> Stable 50%: Aug 25th >>>>>>>>>>> Stable 100%: Sept 8th >>>>>>>>>>> >>>>>>>>>>> On Thu, Jul 27, 2023 at 11:52 AM Mike Taylor < >>>>>>>>>>> mike...@chromium.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> No, we don't know with certainty. >>>>>>>>>>>> >>>>>>>>>>>> You can watch >>>>>>>>>>>> https://chromiumdash.appspot.com/releases?platform=Windows to >>>>>>>>>>>> see when 115 is being served to 100% for all platforms. Today it's >>>>>>>>>>>> at 50% >>>>>>>>>>>> for Windows, for example. >>>>>>>>>>>> On 7/26/23 5:39 PM, Jagadeesha B Y wrote: >>>>>>>>>>>> >>>>>>>>>>>> Do we know when does M115 will hit 100%? Exact date would help >>>>>>>>>>>> us to communicate on the storage partition impact to our customers. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wednesday, July 26, 2023 at 2:12:10 PM UTC-7 >>>>>>>>>>>> mike...@chromium.org wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 7/26/23 4:01 PM, Vi S wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Kyra, >>>>>>>>>>>>> >>>>>>>>>>>>> Per your message here ( >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/tu0i5OmhCAAJ) >>>>>>>>>>>>> it sounds like as of 7/26/2023, the Storage Partitioning change >>>>>>>>>>>>> has not >>>>>>>>>>>>> been released yet since M115 is not served to 100% of users. Is >>>>>>>>>>>>> that >>>>>>>>>>>>> correct? My understanding of this message is that M115 is >>>>>>>>>>>>> currently served >>>>>>>>>>>>> to 12.5% of users and that once M115 is served to 100% of users >>>>>>>>>>>>> (which will >>>>>>>>>>>>> happen in the next ~4 weeks), only then will the storage >>>>>>>>>>>>> partition change >>>>>>>>>>>>> be rolled out in a gradual manner. Is this understanding accurate? >>>>>>>>>>>>> >>>>>>>>>>>>> That's correct. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Additionally, would you be able to provide an updated schedule >>>>>>>>>>>>> for the rollout of the storage partitioning change (similar to >>>>>>>>>>>>> the one >>>>>>>>>>>>> linked here: >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/Tts2gjrEBwAJ) >>>>>>>>>>>>> ? >>>>>>>>>>>>> >>>>>>>>>>>>> Once we begin the gradual roll-out, we'll provide a estimated >>>>>>>>>>>>> rollout schedule on this thread (I hesitate to do so now - it's >>>>>>>>>>>>> hard to >>>>>>>>>>>>> know when we will begin exactly). >>>>>>>>>>>>> >>>>>>>>>>>>> thanks, >>>>>>>>>>>>> Mike >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you >>>>>>>>>>>>> >>>>>>>>>>>>> On Monday, July 24, 2023 at 10:18:26 AM UTC-4 Kyra Seevers >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi there, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you for your email - as of today (Monday 7/24/23), the >>>>>>>>>>>>>> feature is not rolled-out to stable. >>>>>>>>>>>>>> >>>>>>>>>>>>>> However, I can confirm that the rollout schedule for this >>>>>>>>>>>>>> feature begins in M115 at Stable 1% (once M115 is served to 100% >>>>>>>>>>>>>> of users). >>>>>>>>>>>>>> M115 is currently served to 12.5% of users - you can track the >>>>>>>>>>>>>> status at >>>>>>>>>>>>>> https://chromiumdash.appspot.com/releases?platform=Windows. >>>>>>>>>>>>>> Two weeks after that, we'll go to 10%, assuming no large >>>>>>>>>>>>>> stability or >>>>>>>>>>>>>> compatibility regressions. Then 50 and 100% at additional 2 week >>>>>>>>>>>>>> increments. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> In the meantime, we have a deprecation trial ( >>>>>>>>>>>>>> https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials) >>>>>>>>>>>>>> running in M115+ that allows sites who opt-in to maintain >>>>>>>>>>>>>> unpartitioned >>>>>>>>>>>>>> storage for a few milestones while they develop a >>>>>>>>>>>>>> storage-partitioning-compatible solution. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Kyra >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sun, Jul 23, 2023 at 7:05 PM Jagadeesha B Y < >>>>>>>>>>>>>> jaga...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I see that Chrome 115 release notes - >>>>>>>>>>>>>>> https://chromestatus.com/feature/5723617717387264 >>>>>>>>>>>>>>> mentioning about storage partition being enabled by default. >>>>>>>>>>>>>>> Could someone >>>>>>>>>>>>>>> confirm how gradual this rollout is? do we know if storage >>>>>>>>>>>>>>> partition is >>>>>>>>>>>>>>> rolled out fully? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Our SASS product has a heavy reliance on Shared worker and >>>>>>>>>>>>>>> this would break our customer use cases. We use shared worker >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> co-ordinate Web RTC signalling and websocket management which >>>>>>>>>>>>>>> is critical >>>>>>>>>>>>>>> for the app. >>>>>>>>>>>>>>> On Wednesday, May 31, 2023 at 8:42:15 AM UTC-7 >>>>>>>>>>>>>>> mk...@chromium.org wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> LGTM3 with all the caveats about careful rollout discussed >>>>>>>>>>>>>>>> above. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -mike >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, May 30, 2023 at 5:39 PM Mike Taylor < >>>>>>>>>>>>>>>> mike...@chromium.org> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> OK - let's consider this I2S officially revived. Looking >>>>>>>>>>>>>>>>> for a 3rd LGTM to begin shipping in M115. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We have implemented 3rd party deprecation trial support >>>>>>>>>>>>>>>>> for M115+ (see >>>>>>>>>>>>>>>>> https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials), >>>>>>>>>>>>>>>>> and extended the deprecation trial's expiration date >>>>>>>>>>>>>>>>> accordingly to account >>>>>>>>>>>>>>>>> for the delay. And we have the Enterprise policy ready to go. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The rollout schedule will look something like the >>>>>>>>>>>>>>>>> following, pending metrics and compatibility stability: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> July 25th: 1% of Stable population (approximately 1 week >>>>>>>>>>>>>>>>> after M115 is released) >>>>>>>>>>>>>>>>> Aug 8th: 10% >>>>>>>>>>>>>>>>> Aug 22nd: 50% >>>>>>>>>>>>>>>>> Sep 5: 100% >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As always, if we discover significant user-facing breakage >>>>>>>>>>>>>>>>> we'll explore pausing or rolling back to address. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> thanks, >>>>>>>>>>>>>>>>> Mike >>>>>>>>>>>>>>>>> On 5/1/23 10:43 AM, Mike Taylor wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks Rick and Yoav. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We learned from two partners (one internal, one external) >>>>>>>>>>>>>>>>> late last week that a 3P deprecation trial would be needed >>>>>>>>>>>>>>>>> for them to >>>>>>>>>>>>>>>>> preserve widely-used functionality while they work on a >>>>>>>>>>>>>>>>> migration strategy. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We're tracking the work in crbug.com/1441411 and hope to >>>>>>>>>>>>>>>>> have that ready by M115. Once we land the fix, I'll circle >>>>>>>>>>>>>>>>> back and look >>>>>>>>>>>>>>>>> for a 3rd LGTM and have an updated rollout schedule. :) >>>>>>>>>>>>>>>>> On 5/1/23 12:21 AM, Yoav Weiss wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> LGTM2 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, Apr 27, 2023, 16:23 Rick Byers < >>>>>>>>>>>>>>>>> rby...@chromium.org> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wed, Apr 26, 2023 at 2:02 PM Mike Taylor < >>>>>>>>>>>>>>>>>> mike...@chromium.org> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 4/26/23 9:36 AM, Mike Taylor wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > On 4/25/23 12:00 PM, Rick Byers wrote: >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> >> In terms of the standards / process piece, it looks >>>>>>>>>>>>>>>>>>> as if the spec >>>>>>>>>>>>>>>>>>> >> PRs have all stalled for several months. What do you >>>>>>>>>>>>>>>>>>> think is >>>>>>>>>>>>>>>>>>> >> necessary to get these unblocked and landed? As the >>>>>>>>>>>>>>>>>>> last engine to >>>>>>>>>>>>>>>>>>> >> implement this behavior, perhaps we shouldn't feel >>>>>>>>>>>>>>>>>>> too compelled to >>>>>>>>>>>>>>>>>>> >> block shipping on PRs landing? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I was gently reminded offline that I didn't answer this >>>>>>>>>>>>>>>>>>> part of your >>>>>>>>>>>>>>>>>>> question - oops. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Right now it seems to me that the costs of landing these >>>>>>>>>>>>>>>>>>> spec PRs is >>>>>>>>>>>>>>>>>>> higher than we're willing to block on, given the >>>>>>>>>>>>>>>>>>> requested refactoring >>>>>>>>>>>>>>>>>>> (and yes, it's unfortunate that 3 engines would be >>>>>>>>>>>>>>>>>>> shipping essentially >>>>>>>>>>>>>>>>>>> unspecced behavior, but that's where we're at). That >>>>>>>>>>>>>>>>>>> said, I'm happy to >>>>>>>>>>>>>>>>>>> devote my few IC hours to pushing these along as a >>>>>>>>>>>>>>>>>>> personal project over >>>>>>>>>>>>>>>>>>> the coming months. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks Mike. I trust your and wanderview@'s judgement >>>>>>>>>>>>>>>>>> here - I know how hard y'all have been willing to work in >>>>>>>>>>>>>>>>>> the past to get >>>>>>>>>>>>>>>>>> the right thing done in specs. Thanks for being willing to >>>>>>>>>>>>>>>>>> keep pushing in >>>>>>>>>>>>>>>>>> parallel. But given two other implementations have already >>>>>>>>>>>>>>>>>> shipped this, it >>>>>>>>>>>>>>>>>> was clearly already a spec bug that the spec didn't reflect >>>>>>>>>>>>>>>>>> reality. I >>>>>>>>>>>>>>>>>> agree that we shouldn't block shipping a 3rd implementation >>>>>>>>>>>>>>>>>> on spec >>>>>>>>>>>>>>>>>> refactoring work. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> LGTM1 to ship from my perspective. Obviously this will >>>>>>>>>>>>>>>>>> need a very thoughtful and careful roll-out. But I trust >>>>>>>>>>>>>>>>>> Mike and his team >>>>>>>>>>>>>>>>>> to engage with impacted folks to make sure it goes smoothly, >>>>>>>>>>>>>>>>>> as they did >>>>>>>>>>>>>>>>>> with UA reduction. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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/bc52292b-9142-adad-d126-b93231468ed0%40chromium.org >>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc52292b-9142-adad-d126-b93231468ed0%40chromium.org?utm_medium=email&utm_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+...@chromium.org. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e6d131f-f6c7-4bbb-ad3e-bd68cd63ec0dn%40chromium.org >>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e6d131f-f6c7-4bbb-ad3e-bd68cd63ec0dn%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Kyra Seevers (she/her) | Software Engineer | >>>>>>>>>>>>>> kyras...@google.com | 859-537-9917 <(859)%20537-9917> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> Kyra Seevers (she/her) | Software Engineer | >>>>>>>>>>> kyras...@google.com | 859-537-9917 <(859)%20537-9917> >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>> 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/4cf940ed-3dd6-4c49-91af-e6b7c7d42ac4n%40chromium.org >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4cf940ed-3dd6-4c49-91af-e6b7c7d42ac4n%40chromium.org?utm_medium=email&utm_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+...@chromium.org. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/15914fe7-8e14-4580-b1f2-d038ddfba9d6n%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/15914fe7-8e14-4580-b1f2-d038ddfba9d6n%40chromium.org?utm_medium=email&utm_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+...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV9jqK7%2BA-W7A8tWK03vcaqS2onRymPzFxiVOPG1bGcSQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV9jqK7%2BA-W7A8tWK03vcaqS2onRymPzFxiVOPG1bGcSQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> -- Kyra Seevers (she/her) | Software Engineer | kyraseev...@google.com | kyraseev...@chromium.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/CANyVgfAeVoLLpzKfzwwezoT6Cbh4zuZ4mfmU01YHcYPedP2ZQQ%40mail.gmail.com.
