CC @Cheney Tsai <cheneyt...@google.com>, @Una Kravets
<unakrav...@google.com>, @Kadir Topal <kadirto...@google.com>
>From a DevRel perspective, the three questions in my mind are:
- Are affected developers aware of the change?
- I understand they were notified via a console warning / deprecation
warning. It'd be great to get a sense of how effective the
communication was (ie: has usage significantly decreased since the
warnings?).
- Have we given them enough time for developers to react to the change?
- This is less about how complex a change is and more about ensuring
developers can fit the change into their planning cycle (eg: quarterly
OKRs) and avoiding generating unplanned/urgent work, if possible. It does
seem to me the timelines described are short.
- Are developers somehow blocked in implementing the change?
- The change seems quite straightforward, but sometimes developers
are blocked in surprising ways. Is there a channel developers can provide
feedback on?
Andre
On Mon, 12 Sept 2022 at 01:54, Mike Taylor <miketa...@chromium.org> wrote:
> LGTM2
>
> On 9/9/22 12:16 PM, Khushal Sagar wrote:
>
>
>
> On Fri, Sep 9, 2022 at 11:37 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
>
>> Thanks for meticulously gathering that data!!
>>
>> Just to give a rough idea - 5K pixels would be 50x100 pixels, which
>> is noticeable breakage but not necessarily an insurmountable one.
>> The numbers are a bit higher than I'd like, but at the same time, this
>> enables new capabilities and we're not walking this path alone
>> <https://github.com/mozilla/standards-positions/issues/659#issuecomment-1182596173>
>> .
>>
>> Given the above, *LGTM1* for a careful and monitored rollout,
>> accompanied with DevRel folks supporting y'all in communicating this change
>> to developers.
>> What are the timelines you have in mind? Is there some way to use
>> Deprecation Reporting to help us here?
>>
>
> I would target a gradual roll out: 1% -> 10% -> 25% -> 50% -> 100% with a
> week before each progression in M107. The release will go to stable
> ~October 25th (schedule <https://chromiumdash.appspot.com/schedule>).
>
> In terms of outreach a console warning
> <https://chromiumdash.appspot.com/commit/97b80f4e3b9b742a8c44fa5cb96b6c753b29f3d2>
> and a deprecation warning
> <https://chromiumdash.appspot.com/commit/0d0d8e0a1862e689690a702a5c5295531d9a3a27>
> was
> added in M105 for cases where the element's computed style can cause this
> behaviour change. I've also reached out to the dev rel folks for a targeted
> email to affected sites that came up through our CT analysis.
>
>
>>
>> On Fri, Sep 9, 2022 at 5:27 PM Khushal Sagar <khushalsa...@chromium.org>
>> wrote:
>>
>>> We have UseCounter data from M105 stable to quantify the large breakage
>>> for this feature. Large is a page load where any image, video or canvas
>>> drawn on the page paints over 5k CSS pixels outside its content-box. The
>>> precise numbers (with page load count) are here
>>> <https://docs.google.com/document/d/1GC2wanCPtoboSujQVr5xoCDlpzzhspr0PHA-OBgGbEY/edit>
>>> (sorry
>>> can't share the details externally).
>>>
>>> In terms of percentage, Windows/Mac had ~0.006% page loads fall in the
>>> large breakage category and Android had ~0.007%.
>>>
>>> On Tue, Aug 2, 2022 at 3:14 PM Khushal Sagar <khushalsa...@chromium.org>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Aug 1, 2022 at 12:11 PM Yoav Weiss <yoavwe...@chromium.org>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 25, 2022 at 7:44 PM Khushal Sagar <
>>>>> khushalsa...@chromium.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 20, 2022 at 5:17 AM Yoav Weiss <yoavwe...@chromium.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks Khushal! :)
>>>>>>>
>>>>>>> The breakage seems potentially significant (at worst, makes the site
>>>>>>> visually broken and unusable), and the percentage of breakage seems
>>>>>>> above
>>>>>>> the threshold we typically consider safe.
>>>>>>> At the same time this seems like a positive change, and our friends
>>>>>>> at Mozilla consider it "worth prototyping".
>>>>>>>
>>>>>>> Would it be possible to consider this as a deprecation of the old
>>>>>>> behavior, and run the console issue (+deprecation warnings and outreach
>>>>>>> to
>>>>>>> affected sites) for a few milestones, to try and drive the usage down
>>>>>>> before flipping this change to be on by default? Maybe also get some
>>>>>>> documentation out there and work with devrel folks to make sure folks
>>>>>>> are
>>>>>>> aware of this coming change?
>>>>>>>
>>>>>>> Does that sound reasonable?
>>>>>>>
>>>>>>
>>>>>> Thanks for the suggestion Yoav. This sounds reasonable. I've reached
>>>>>> out to the devrel folks to do more outreach about this change. I'll
>>>>>> update
>>>>>> this thread with the plan for it. The console issue and deprecation
>>>>>> warnings have been added in M105.
>>>>>>
>>>>>> I looked into adding a use counter for sites which have real
>>>>>> breakage, since the current metric tracks whether the computed style
>>>>>> *could* permit allow but not whether there is actual overflow at paint
>>>>>> time. And unfortunately computing potential overflow is not easy to add.
>>>>>> The CT analysis I ran earlier did this by turning the feature on and
>>>>>> tracking actual overflow generated by the element. So a couple of
>>>>>> questions
>>>>>> for moving forward:
>>>>>>
>>>>>> - Would it be okay to turn the feature on in beta and 1% stable (in
>>>>>> M105) to collect metrics for the sites with real breakage and the extent
>>>>>> of
>>>>>> this breakage (how many pixels of overflow do we see). This should be
>>>>>> lower
>>>>>> than the counter of 0.017%.
>>>>>>
>>>>>
>>>>> That sounds like a great way to gather data! (assuming the relevant
>>>>> Chrome processes are followed)
>>>>> Would be good to gather a histogram of overflowed pixels, to get a
>>>>> sense of "small breakage" vs. "large breakage".
>>>>>
>>>>>
>>>>>>
>>>>>> - What's the number (in terms of page loads affected) we should be
>>>>>> targeting before this would be safe?
>>>>>>
>>>>>
>>>>> From my perspective, I'd be comfortable shipping this if we're seeing
>>>>> less than 0.003% of page loads in the "large breakage" bucket (say more
>>>>> than ~5000 overflowing pixels, assuming that number makes sense).
>>>>>
>>>>> +Andre Bandarra <andre...@google.com> - for devrel opinions on this.
>>>>>
>>>>
>>>> Currently we're recording a UseCounter when any breakage would happen,
>>>> i.e, there is any pixel overflow. If it helps to have a UseCounter for
>>>> overflow above a threshold, I'm happy to add that too.
>>>>
>>>> We do have an UMA metric which measures the number of overflowing
>>>> pixels when there is overflow but it's for all images rendered. I can tie
>>>> it to the UseCounter so we can also know the number of affected page loads
>>>> with large breakage. I'll wait till the end of the week for more feedback,
>>>> otherwise assume 5k is a good threshold for large breakage.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Yoav
>>>>>>>
>>>>>>> On Thursday, July 14, 2022 at 5:03:54 PM UTC+2 Khushal Sagar wrote:
>>>>>>>
>>>>>>>> Hey folks,
>>>>>>>>
>>>>>>>> I'm summarizing the steps to mitigate the compat risk with this
>>>>>>>> feature based on the feedback:
>>>>>>>>
>>>>>>>> - Add a warning to the console when a developer style would
>>>>>>>> permit replaced elements to overflow. The patch to add that is
>>>>>>>> here
>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/3763640>
>>>>>>>> and
>>>>>>>> documentation to help developers debug, which is referenced in the
>>>>>>>> console
>>>>>>>> warning, is here
>>>>>>>> <https://github.com/WICG/shared-element-transitions/pull/166/files>.
>>>>>>>> We can pre-emptively add this warning to M105 and ship the feature
>>>>>>>> in M106
>>>>>>>> to have a one release window before the behaviour changes.
>>>>>>>>
>>>>>>>> - Send an email to the webmaster of sites surfaced in the CT
>>>>>>>> analysis which already have the styles that trigger the warning
>>>>>>>> above.
>>>>>>>>
>>>>>>>> In addition to the above, the feature can be turned off with a
>>>>>>>> server-side config using finch if there is any severe breakage.
>>>>>>>>
>>>>>>>> Please let me know if the above suffices.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> Khushal
>>>>>>>>
>>>>>>>> On Wed, Jul 13, 2022 at 4:11 PM Khushal Sagar <
>>>>>>>> khushalsa...@chromium.org> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jul 13, 2022 at 3:44 PM Mike Taylor <
>>>>>>>>> miketa...@chromium.org> wrote:
>>>>>>>>>
>>>>>>>>>> On 7/13/22 3:04 PM, Khushal Sagar wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 13, 2022 at 6:12 AM Yoav Weiss <
>>>>>>>>>> yoavwe...@chromium.org> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wednesday, July 13, 2022 at 3:54:28 AM UTC+2 Khushal Sagar
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jul 11, 2022 at 11:40 AM Yoav Weiss <
>>>>>>>>>>>> yoavwe...@chromium.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar <
>>>>>>>>>>>>> khushalsa...@chromium.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Contact emails khushalsa...@chromium.org, vmp...@chromium.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Explainer
>>>>>>>>>>>>>> https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
>>>>>>>>>>>>>> https://github.com/w3c/csswg-drafts/issues/7058
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Specification
>>>>>>>>>>>>>> https://drafts.csswg.org/css-overflow/#overflow-properties
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Summary
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This change allows developers to use the existing `overflow`
>>>>>>>>>>>>>> property with replaced elements that paint outside the
>>>>>>>>>>>>>> content-box. Paired
>>>>>>>>>>>>>> with `object-view-box` this can be used to create an image with
>>>>>>>>>>>>>> a custom
>>>>>>>>>>>>>> glow or shadow applied, with proper ink-overflow behavior like a
>>>>>>>>>>>>>> CSS shadow
>>>>>>>>>>>>>> would have.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Blink component Blink>CSS
>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> TAG review
>>>>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/750
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> TAG review status Pending
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Risks
>>>>>>>>>>>>>> Interoperability and Compatibility
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This feature changes the behaviour of the existing overflow
>>>>>>>>>>>>>> property on replaced elements (img, video, canvas). Currently
>>>>>>>>>>>>>> `overflow:visible` in a developer stylesheet on such elements is
>>>>>>>>>>>>>> ignored
>>>>>>>>>>>>>> during paint and the content is clipped to the element's
>>>>>>>>>>>>>> content-box. With
>>>>>>>>>>>>>> this feature, `overflow:visible` will result in content outside
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> element's content-box to paint as ink overflow. We've collected
>>>>>>>>>>>>>> use counter
>>>>>>>>>>>>>> data to measure the number of sites which could be affected by
>>>>>>>>>>>>>> this. The
>>>>>>>>>>>>>> use counter data collected over 1 week of a stable release
>>>>>>>>>>>>>> (M102) is as
>>>>>>>>>>>>>> follows. We collected 2 different counters explained below. *
>>>>>>>>>>>>>> The first
>>>>>>>>>>>>>> measures any instance where overflow is explicitly set from
>>>>>>>>>>>>>> developer
>>>>>>>>>>>>>> styles to visible. The percentage of page loads with this is
>>>>>>>>>>>>>> 2.16%. * The
>>>>>>>>>>>>>> second measures the above instances but only includes the cases
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> object-fit set to cover or none or object-position set to any
>>>>>>>>>>>>>> value other
>>>>>>>>>>>>>> than the default (50% 50%). The rationale behind this counter is
>>>>>>>>>>>>>> to exclude
>>>>>>>>>>>>>> cases which can not cause overflow (such as object-fit:contain),
>>>>>>>>>>>>>> even if
>>>>>>>>>>>>>> overflow is set to visible. The percentage of page loads with
>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>> 0.017%.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's not nothing. Any idea what breakage may look like?
>>>>>>>>>>>>> Can we maybe collect histograms on *how much* overflow would
>>>>>>>>>>>>> occur in those cases? (maybe with ClusterTelemetry initially, to
>>>>>>>>>>>>> get a
>>>>>>>>>>>>> rough idea in the lab)
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I ran an analysis on CT using top 100k sites for desktop and
>>>>>>>>>>>> top 10k sites on mobile. The raw numbers are here: desktop
>>>>>>>>>>>> <https://docs.google.com/spreadsheets/d/1kKWq8kqZOfCXqiHaiamYNDdTs5x1_YJfDTnAgXOIwaE/edit#gid=0>
>>>>>>>>>>>> and mobile
>>>>>>>>>>>> <https://docs.google.com/spreadsheets/d/1SrNyrEe4yzCOIxqNOlNgCk8O58NqqoBlBTd4Wn_gKCc/edit#gid=0>,
>>>>>>>>>>>> and the rough patch
>>>>>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/3749485>
>>>>>>>>>>>> to
>>>>>>>>>>>> collect this data. The highlights from the analysis are below:
>>>>>>>>>>>>
>>>>>>>>>>>> - The number of sites which override the default CSS to
>>>>>>>>>>>> allow overflow *and* also had overflow during painting was 13
>>>>>>>>>>>> out of 10k on
>>>>>>>>>>>> mobile and 39 out of 63k on desktop (only 63k sites yielded
>>>>>>>>>>>> results out of
>>>>>>>>>>>> 100k).
>>>>>>>>>>>>
>>>>>>>>>>>> - I measured the percentage of area painted outside the
>>>>>>>>>>>> content box out of the total painted area. The highest was 88%
>>>>>>>>>>>> on desktop
>>>>>>>>>>>> and 70% on mobile.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> I'm not sure what that means in practice. Can you elaborate?
>>>>>>>>>>> Have you looked at extreme cases to see the impact there?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sorry, I should've added more details. :) I was looking for
>>>>>>>>>> breakages with 2 numbers: sites with the largest number of
>>>>>>>>>> overflowing
>>>>>>>>>> pixels (such that other content could be occluded); sites with the
>>>>>>>>>> largest
>>>>>>>>>> percentage of image content outside the content box. But I realize
>>>>>>>>>> the
>>>>>>>>>> former is probably better to identify breakages.
>>>>>>>>>>
>>>>>>>>>> Looking at the top 10 sites, the worst affected is liveops.com.
>>>>>>>>>> This has cases which use object-fit:cover so the image scales to a
>>>>>>>>>> size
>>>>>>>>>> bigger than its content rect and developer CSS overrides overflow to
>>>>>>>>>> visible. Unfortunately, interacting more with this site, I did see
>>>>>>>>>> images
>>>>>>>>>> which are drawing above other content (screenshot attached) as you
>>>>>>>>>> scroll
>>>>>>>>>> down. This pattern showed up on the rest of the sites with high
>>>>>>>>>> overflow
>>>>>>>>>> numbers too (another example with screenshot attached).
>>>>>>>>>>
>>>>>>>>>> This kind of breakage is expected with this change. I'm not sure
>>>>>>>>>> where to put the cutoff to identify sites with significant breakage,
>>>>>>>>>> but
>>>>>>>>>> there are at least 30 sites (out of 63k) that have images with more
>>>>>>>>>> than
>>>>>>>>>> 100px of overflow. The fix for the developer is to trace down the
>>>>>>>>>> source of
>>>>>>>>>> the overflow override and remove it.
>>>>>>>>>>
>>>>>>>>>> I'm not sure what's the recommended way to progress with a
>>>>>>>>>> behaviour change like this given these numbers, the instances of
>>>>>>>>>> affected
>>>>>>>>>> sites seems low. Since the fix is simple, but hard to diagnose, one
>>>>>>>>>> option
>>>>>>>>>> could be to add a warning to the console: "overflow:visible now
>>>>>>>>>> causes
>>>>>>>>>> images to draw outside their bounds. Please make sure this style is
>>>>>>>>>> intentional" for a few releases (credits to @Vladimir Levin
>>>>>>>>>> <vmp...@chromium.org> for the idea). Would that suffice?
>>>>>>>>>>
>>>>>>>>>> This feels like a fairly challenging bug to diagnose out without
>>>>>>>>>> a DevTools issue
>>>>>>>>>> <https://developer.chrome.com/docs/devtools/issues/> (or similar
>>>>>>>>>> console message that links to some useful docs, as you proposed).
>>>>>>>>>> Would we
>>>>>>>>>> have the ability to conditionally create these for some overflow
>>>>>>>>>> threshold
>>>>>>>>>> value?
>>>>>>>>>>
>>>>>>>>> Sure, we can do this conditionally based on the area of overflow.
>>>>>>>>> I'd be inclined to always do it if the UA style is overridden to allow
>>>>>>>>> overflow for at least a few releases. Since it's likely that existing
>>>>>>>>> sites
>>>>>>>>> are not overriding this style intentionally (because currently it's a
>>>>>>>>> no-op). Just to catch cases which don't show up in local testing
>>>>>>>>> because
>>>>>>>>> scaling of the image (with properties like object-fit) can depend on
>>>>>>>>> the
>>>>>>>>> form factor of the device.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> I manually went through ~10 sites on both desktop and mobile.
>>>>>>>>>>>> For the ones which repro-ed, the breakage was losing rounded
>>>>>>>>>>>> corners
>>>>>>>>>>>> because border-radius doesn't clip the content if 'overflow' is
>>>>>>>>>>>> 'visible'.
>>>>>>>>>>>> In fact a few sites had the same code, likely coming from
>>>>>>>>>>>> customerly <https://www.customerly.io/> based on class names
>>>>>>>>>>>> and the UX. There was one case where an image (used in the
>>>>>>>>>>>> background) had
>>>>>>>>>>>> object-fit:cover and overflowed outside the content box now. I've
>>>>>>>>>>>> attached
>>>>>>>>>>>> screenshots for both of these.
>>>>>>>>>>>>
>>>>>>>>>>>> Overall I didn't see any case where the overflow occluded any
>>>>>>>>>>>> other content on the page.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That's reassuring! :)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Gecko*: No signal (
>>>>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/659)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *WebKit*: No signal (
>>>>>>>>>>>>>> https://lists.webkit.org/pipermail/webkit-dev/2022-June/032317.html
>>>>>>>>>>>>>> )
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *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?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Debuggability
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is a CSS property which can be debugged in the devtools
>>>>>>>>>>>>>> style panel similar to other CSS properties.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>>>>>>>>>>> ? Yes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Flag name CSSOverflowForReplacedElements
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Note: Because of the compat risk with this feature, this
>>>>>>>>>>>>>> flag can be controlled via Finch. This will allow us to rollback
>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>> server-side config change if needed.*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Requires code in //chrome? False
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tracking bug
>>>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1321217
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Estimated milestones
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> M105
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Anticipated spec changes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> N/A
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>>>>>>> https://chromestatus.com/feature/5137515594383360
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Links to previous Intent discussions Intent to prototype:
>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUykJWEAqVzcUy15fpBNdA68508Mny_1z--FCBKXRTZOFQ%40mail.gmail.com
>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/camluwuykjweaqvzcuy15fpbnda68508mny_1z--fcbkxrtz...@mail.gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This intent message was generated by Chrome Platform Status
>>>>>>>>>>>>>> <https://chromestatus.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/CAMLuWUze8JV6twLfhPBwkXj_UBMGApU048OdY33hYQn_KDj2rA%40mail.gmail.com
>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUze8JV6twLfhPBwkXj_UBMGApU048OdY33hYQn_KDj2rA%40mail.gmail.com?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+unsubscr...@chromium.org.
>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUz9cutp%2BinEc3%2B7sdv%2B2TPoBbEeFCZjZFExBHSOL1p47A%40mail.gmail.com
>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUz9cutp%2BinEc3%2B7sdv%2B2TPoBbEeFCZjZFExBHSOL1p47A%40mail.gmail.com?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+unsubscr...@chromium.org.
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUy5zyHePkt06pjbtAE_vu1VjbybK5VXURhuSETyR%2Bu54g%40mail.gmail.com
>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUy5zyHePkt06pjbtAE_vu1VjbybK5VXURhuSETyR%2Bu54g%40mail.gmail.com?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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFCDhBdANfpUrn6rGpXZKenynJ5VO3rzAWcjV3XQ6aYvqnSPQ%40mail.gmail.com.
