Thanks Ian. Let's continue this discussion off blink-dev to the blink-api-owners-discuss thread <https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/yYQgO0wdaaI/m/hGO6Wqz8AwAJ> .
On Mon, Feb 13, 2023 at 11:56 AM Ian Clelland <iclell...@chromium.org> wrote: > I've been working on the transition to dict, but failed to revert the > initial exposure, which we believed was unlikely to have any real compat > issues. > > That seems to be wrong, as > https://bugs.chromium.org/p/chromium/issues/detail?id=1414463 was filed > recently saying that it breaks an enterprise use case. I'm going to revert > the original change immediately, but unfortunately we did allow this to > ship in M110. > > I'd appreciate any guidance here from API owners for any > additional steps to take to mitigate this; my immediate plan is to revert > and merge back to M111, and propose a merge back to M110 for the next point > release. > > On Fri, Nov 25, 2022 at 1:51 PM Ian Clelland <iclell...@chromium.org> > wrote: > >> >> >> On Fri, Nov 25, 2022 at 12:03 PM Manuel Rego Casasnovas <r...@igalia.com> >> wrote: >> >>> WebKit has been doing some work implementing the Reporting API: >>> https://bugs.webkit.org/show_bug.cgi?id=189365 >>> >>> Do we know their plans regarding this topic? Should we ask for signals? >>> >> >> Thanks Rego -- >> >> The last time I heard, Chris Dumez had been working on an implementation, >> but it didn't include ReportingObserver. I'll reach out to see if that's >> changed, and I suppose it can't hurt to file for an official signal, now >> that they've implemented that as a repository. >> >> Ian >> >> >>> Cheers, >>> Rego >>> >>> On 25/11/2022 15:39, Rick Byers wrote: >>> > On Fri, Nov 25, 2022 at 9:27 AM Ian Clelland <iclell...@chromium.org >>> > <mailto:iclell...@chromium.org>> wrote: >>> > >>> > >>> > >>> > On Fri, Nov 25, 2022 at 1:54 AM Domenic Denicola >>> > <dome...@chromium.org <mailto:dome...@chromium.org>> wrote: >>> > >>> > >>> > >>> > On Fri, Nov 25, 2022, 14:53 Yoav Weiss <yoavwe...@chromium.org >>> > <mailto:yoavwe...@chromium.org>> wrote: >>> > >>> > >>> > On Fri, Nov 25, 2022 at 5:50 AM Domenic Denicola >>> > <dome...@chromium.org <mailto:dome...@chromium.org>> >>> wrote: >>> > >>> > Note that in the past I've suggested these not be >>> > interfaces at >>> > all: https://github.com/w3c/reporting/issues/216 >>> > <https://github.com/w3c/reporting/issues/216> . As far >>> > as I can tell that issue is still open, and it would >>> > have been better to resolve it by making everything use >>> > dictionaries (or even just non-dictionary objects, like >>> > several specs do today) instead of creating new >>> > interfaces against proposed W3C TAG Design Principles >>> > <https://github.com/w3ctag/design-principles/issues/11 >>> >. >>> > >>> > >>> > Thanks Domenic. Turning those into dictionaries does sound >>> > appealing. Let's wait to hear what Ian says. >>> > >>> > >>> > >>> > Also that there is no spec for several of these >>> > interfaces (at least CoopAccessViolationReportBody, >>> > possibly others). So I think there's considerable >>> > interop risk. >>> > >>> > >>> > That interop risk is orthogonal to whether we expose those >>> > interfaces or not, right? Not saying it shouldn't be fixed, >>> > just that the risk exists already. >>> > >>> > >>> > I don't think it's orthogonal. Once the interfaces are exposed, >>> > they're much easier to depend on the existence of, and given >>> > that there is no spec for their shape or behavior, such >>> > dependence seems like an Interop risk. >>> > >>> > >>> > Most of these are spec'd: >>> > Report: https://w3c.github.io/reporting/#ref-for-dom-report >>> > <https://w3c.github.io/reporting/#ref-for-dom-report> >>> > ReportBody: https://w3c.github.io/reporting/#reportbody >>> > <https://w3c.github.io/reporting/#reportbody> >>> > CSPViolationReportBody: >>> https://www.w3.org/TR/CSP3/#cspviolationreportbody < >>> https://www.w3.org/TR/CSP3/#cspviolationreportbody> >>> > DeprecationReportBody: >>> https://wicg.github.io/deprecation-reporting/#deprecationreportbody < >>> https://wicg.github.io/deprecation-reporting/#deprecationreportbody> >>> > InterventionReportBody: >>> https://wicg.github.io/intervention-reporting/#interventionreportbody < >>> https://wicg.github.io/intervention-reporting/#interventionreportbody> >>> > >>> > CoopAccessViolationReportBody and DocumentPolicyViolationReportBody >>> > are not. CrashReportBody *is*, though not usefully, as it's not >>> > observable. >>> > >>> > >>> > We definitely shouldn't be exposing interface objects that aren't >>> > spec'd. Thanks for catching this Domenic. >>> > >>> > I'm definitely not against turning these into WebIDL dictionaries, >>> > as they don't actually have any behaviour - they're just a >>> > collection of named data. They were originally defined as >>> > interfaces, I believe, in order to spec the constraints on the >>> names >>> > and types of their data members. Using plain objects at the time >>> > would have made that more difficult. As I understand it, WebIDL >>> > dictionaries do not expose any symbols on the global namespace, so >>> > that would remove the compatibility concern. >>> > >>> > I'd like the API Owners to reconsider their LGTMs in >>> > light of these unresolved discussions. At the very >>> > least, I think at TAG review is warranted for this, as >>> > there are architectural implications here. But fixing >>> > the spec situation would be even better. >>> > >>> > >>> > I'll revert the change for now, and take a pass at changing the >>> > specs involved. >>> > >>> > Thanks for weighing in, Domenic! >>> > >>> > >>> > Saying this intent is on hold >>> > until https://github.com/w3c/reporting/issues/216 >>> > <https://github.com/w3c/reporting/issues/216> is resolved one way or >>> the >>> > other makes sense to me. Let's take the design debate there. I have >>> some >>> > additional questions / concerns but blink-dev isn't the right forum for >>> > API design discussions. >>> > >>> > >>> > On Thursday, November 24, 2022 at 3:01:12 PM UTC+9 Yoav >>> > Weiss wrote: >>> > >>> > LGTM3 >>> > >>> > On Wed, Nov 23, 2022 at 11:28 PM Chris Harrelson >>> > <chris...@chromium.org >>> > <mailto:chris...@chromium.org>> wrote: >>> > >>> > LGTM2 >>> > >>> > On Wed, Nov 23, 2022, 4:14 PM Rick Byers >>> > <rby...@chromium.org >>> > <mailto:rby...@chromium.org>> wrote: >>> > >>> > Thanks for doing this analysis. According >>> to >>> > our guidelines >>> > < >>> https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.4k9u8ddizqrq> >>> this >>> is in the low risk range of <0.001% of pages in HTTP Archive. Personally I >>> think we should just go for it, but be prepared to revert (and rename the >>> interface instead) if we get even a single bug report in beta. LGTM1 >>> > >>> > On Wed, Nov 23, 2022 at 4:50 PM Ian >>> Clelland >>> > <iclell...@chromium.org >>> > <mailto:iclell...@chromium.org>> wrote: >>> > >>> > So I've run through HTTPArchive with >>> > these queries (shown for desktop, >>> mobile >>> > is analogous): >>> > >>> > SELECTAPPROX_COUNT_DISTINCT(pageid) >>> > FROM >>> > >>> `httparchive.summary_requests.2022_10_01_desktop` AS REQ >>> > JOIN >>> > >>> `httparchive.response_bodies.2022_10_01_desktop` AS RESP on REQ.url = >>> RESP.url >>> > WHERE ( >>> > REQ.resp_content_type = >>> > 'application/javascript' OR >>> > REQ.resp_content_type = >>> 'text/javascript' OR >>> > REQ.resp_content_type = >>> > 'application/html' OR >>> > REQ.resp_content_type = 'text/html') >>> > AND ( >>> > REGEXP_CONTAINS(RESP.body, >>> > r"\bwindow\.Reporting\b") OR >>> > REGEXP_CONTAINS(RESP.body, >>> > r"\bself\.Reporting\b")); >>> > >>> > >>> > And found 161 pages on desktop (out of >>> > ~10M pages), and 185 on mobile (of >>> > ~15M). (For comparison, replacing >>> > "Report" with "ReportingObserver", >>> > yields ~123k pages on desktop referring >>> > to that symbol) >>> > >>> > Coalescing distinct resource URLs in >>> > this case (as many may be from the same >>> > third-party library) yields just 110 >>> > URLs on mobile, including many clearly >>> > repeated resources hosted on different >>> > subdomains of kindful.com >>> > <http://kindful.com>, and >>> > several named simply '/js/common.js': >>> > >>> > >>> https://cookerevivals.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >>> < >>> https://cookerevivals.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >>> > >>> > >>> https://atlast.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >>> < >>> https://atlast.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >>> > >>> > >>> https://indushospitalca.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >>> < >>> https://indushospitalca.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >>> > >>> > >>> https://stridereducationfoundation-bloom.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >>> < >>> https://stridereducationfoundation-bloom.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >>> > >>> > (And many more; these ones >>> > unconditionally overwrite Report) >>> > >>> > >>> https://tesotunes.com/js/common.js?version=2.1.5.8-beta-22 < >>> https://tesotunes.com/js/common.js?version=2.1.5.8-beta-22> >>> > http://arabgramz.com/js/common.js?x=37 >>> > < >>> http://arabgramz.com/js/common.js?x=37> >>> > >>> https://www.yavedo.com/js/common.js?x=55 >>> > < >>> https://www.yavedo.com/js/common.js?x=55> >>> > https://shakulive.com/js/common.js?x44 >>> > < >>> https://shakulive.com/js/common.js?x44> >>> > (These ones do check for Report's >>> > existence, and use "window.Report || ( >>> > window.Report = {} );" before defining >>> > new methods. This will also continue to >>> > work, but will add new methods to the >>> > interface object, rather than the >>> > presumed empty dict.) >>> > >>> > On Wed, Nov 23, 2022 at 12:48 PM Rick >>> > Byers <rby...@chromium.org >>> > <mailto:rby...@chromium.org>> wrote: >>> > >>> > >>> > On Wed, Nov 23, 2022 at 12:22 PM >>> > Yoav Weiss <yoavwe...@chromium.org >>> > <mailto:yoavwe...@chromium.org>> >>> wrote: >>> > >>> > >>> > On Wed, Nov 23, 2022 at 6:13 PM >>> > Ian Clelland >>> > <iclell...@chromium.org >>> > <mailto:iclell...@chromium.org >>> >> >>> > wrote: >>> > >>> > Well, that is exactly the >>> > situation outlined as a >>> > risk. I'm still running >>> some >>> > HTTPArchive queries, but >>> > didn't immediately see much >>> > there. >>> > >>> > I expect that +Domenic >>> > Denicola >>> > <mailto:dome...@google.com> >>> > may >>> have more context on the changes here, but my understanding is that WebIDL >>> has been moving towards this for some time. >>> > >>> > The issues I'm aware of are >>> > on WebIDL: >>> > >>> https://github.com/whatwg/webidl/issues/350 < >>> https://github.com/whatwg/webidl/issues/350> renames >>> "NoInterfaceObject" to "LegacyNoInterfaceObject" >>> > >>> https://github.com/whatwg/webidl/issues/365 < >>> https://github.com/whatwg/webidl/issues/365> starts mandating the use >>> of "Exposed" in all interfaces >>> > >>> > Reporting specifically was >>> > updated in 2019, with >>> > >>> https://github.com/w3c/reporting/pull/173 < >>> https://github.com/w3c/reporting/pull/173>, after >>> https://github.com/whatwg/webidl/pull/423 < >>> https://github.com/whatwg/webidl/pull/423> made Exposed mandatory. >>> > >>> > >>> > Is it possible to rename these >>> > exposed interfaces to something >>> > less generic, that's less >>> likely >>> > to collide? >>> > >>> > >>> > Since it's not exposed today, >>> nobody >>> > should be depending on the name. So >>> > I'm sure we could. >>> > >>> > But I'd like to understand why we >>> > should expose it at all. I tried >>> > digging through the history of >>> > discussions on this topic and the >>> > contents of the WebIDL spec but >>> > couldn't get clarity on what the >>> > thinking has been. I >>> > filed >>> https://github.com/whatwg/webidl/issues/1236 < >>> https://github.com/whatwg/webidl/issues/1236> to hopefully have that >>> captured somewhere. >>> > >>> > On Wed, Nov 23, 2022 at >>> > 11:18 AM Rick Byers >>> > <rby...@chromium.org >>> > <mailto: >>> rby...@chromium.org>> wrote: >>> > >>> > I did a quick GitHub >>> > search and quickly >>> found >>> > this >>> > < >>> https://github.com/xuehuibo/MobileQueryPlatform/blob/master/MobileQueryPlatform/MobileQueryPlatform/Views/Home/ReportMenu.cshtml>: >>> :-( >>> > >>> > if (window.Report == >>> > undefined) { >>> > >>> > >>> Tools.Namespace.register("window.Report"); >>> > } >>> > >>> > And then a bunch of >>> > downstream code >>> > expecting to build >>> stuff >>> > up on window.Report. I >>> > didn't try to find out >>> > where or how much this >>> > is used, but it's >>> > certainly not >>> promising. >>> > >>> > Where is this decision >>> > to expose all interface >>> > objects by default >>> > coming from? Are we >>> sure >>> > it's the right thing >>> for >>> > the web when the global >>> > namespace is shared >>> > between the platform >>> and >>> > application code? >>> > >>> > Sorry Ian, I know I >>> said >>> > I thought this should >>> be >>> > a simple one :-). If we >>> > have data that it looks >>> > very rare, then I'm >>> > still happy to approve. >>> > I'm just wondering now >>> > about the bigger >>> picture >>> > of this class of >>> changes. >>> > >>> > Rick >>> > >>> > On Wed, Nov 23, 2022 at >>> > 9:52 AM Yoav Weiss >>> > < >>> yoavwe...@chromium.org >>> > <mailto: >>> yoavwe...@chromium.org>> wrote: >>> > >>> > As this is not >>> > actually a feature, >>> > but a spec >>> alignment >>> > effort, I think it >>> > makes sense to skip >>> > TAG reviews and >>> > vendor positions >>> for >>> > this. >>> > >>> > I'm slightly >>> > concerned about >>> > `Report` >>> collisions. >>> > Would you be able >>> to >>> > run a quick >>> > HTTPArchive scan >>> for >>> > "window.Report" and >>> > "self.Report" and >>> > see what that >>> gives? >>> > ("var Report" would >>> > just >>> unconditionally >>> > override it, so >>> > that's not an >>> issue) >>> > >>> > On Wed, Nov 23, >>> 2022 >>> > at 2:55 PM Ian >>> > Clelland >>> > < >>> iclell...@chromium.org <mailto:iclell...@chromium.org>> wrote: >>> > >>> > >>> > Contact >>> > emails >>> > >>> > >>> iclell...@chromium.org <mailto:iclell...@chromium.org> >>> > >>> > >>> > >>> Specification >>> > >>> > >>> https://w3c.github.io/reporting/#idl-index < >>> https://w3c.github.io/reporting/#idl-index> >>> > >>> > >>> > Summary >>> > >>> > Several >>> > interface >>> > objects used by >>> > the Reporting >>> > API were >>> > originally not >>> > exposed as >>> > symbols on the >>> > JavaScript >>> > global object. >>> > This includes >>> > Report, >>> > ReportBody, and >>> > the various >>> > specific report >>> > body types such >>> > as >>> > >>> CSPViolationReportBody and DeprecationReportBody. This change exposes >>> those objects on the window (or worker global), bringing the implementation >>> in line with the specification. >>> > >>> > >>> > >>> > Blink >>> > >>> component >>> > >>> > >>> Blink>ReportingObserver < >>> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EReportingObserver >>> > >>> > >>> > >>> > TAG >>> review >>> > >>> > >>> > >>> > TAG >>> > review >>> > status >>> > >>> > Not applicable >>> > >>> > >>> > Risks >>> > >>> > >>> > >>> > >>> Interoperability and Compatibility >>> > >>> > The main risk >>> > here is that >>> the >>> > newly-exposed >>> > symbols will >>> > collide with >>> > symbols defined >>> > in existing >>> > scripts. Most >>> of >>> > the names are >>> > quite specific, >>> > but "Report" >>> and >>> > "ReportBody" >>> may >>> > have some >>> > existing use. >>> > However, this >>> is >>> > unlikely to be >>> a >>> > problem in >>> > practice, as >>> > most code which >>> > uses these >>> names >>> > for its own >>> > variables will >>> > also continue >>> to >>> > work; >>> redefining >>> > them in a local >>> > script should >>> > not have any >>> > effect on >>> either >>> > the script or >>> > the Reporting >>> > API. One >>> > possibility for >>> > breakage would >>> > be a script >>> that >>> > defines, say, a >>> > "Report" >>> object, >>> > (unrelated to >>> > the Reporting >>> > API,) but does >>> > so only if it >>> > did not >>> > previously >>> > exist. In that >>> > case, the >>> > hypothetical >>> > script would >>> > *not* define >>> its >>> > own Report, and >>> > would >>> presumably >>> > attempt to use >>> > the >>> > newly-exposed >>> > interface >>> > object. In >>> order >>> > for this to be >>> a >>> > real issue, a >>> > script would >>> > have to: 1. Use >>> > one of these >>> > symbol names, >>> > down to >>> > capitalization. >>> > I suspect that >>> > "Report" is the >>> > most probable, >>> > with the >>> various >>> > ReportBody >>> types >>> > being far less >>> > likely >>> > candidates for >>> > collision 2. >>> > Specifically >>> > guard against >>> > re-defining the >>> > symbol, even >>> > though it's not >>> > currently >>> > >>> platform-exposed >>> > anywhere. This >>> > would likely >>> > only occur if >>> > some >>> > initialization >>> > code was >>> > expected to be >>> > run multiple >>> > times blindly. >>> > (Blink's web >>> > test result >>> > page, for >>> > instance, uses >>> > "Report" as an >>> > object name, >>> but >>> > defines it >>> > >>> unconditionally, >>> > so it will >>> > simply shadow >>> > the interface >>> > object.) >>> > >>> > >>> > >>> > /Gecko/: No >>> signal >>> > >>> > /WebKit/: No >>> signal >>> > >>> > /Web >>> > developers/: No >>> > signals >>> > >>> > /Other >>> signals/: >>> > >>> > >>> > >>> Ergonomics >>> > >>> > None >>> > >>> > >>> > >>> > >>> Activation >>> > >>> > None >>> > >>> > >>> > >>> > >>> Security >>> > >>> > None >>> > >>> > >>> > >>> > 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 >>> > >>> > >>> > >>> > Will >>> > this >>> > feature >>> > be >>> > >>> supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, >>> Android, and Android WebView)? >>> > >>> > Yes >>> > >>> > This is a >>> change >>> > to the IDL for >>> > these >>> > interfaces, and >>> > is >>> automatically >>> > supported by >>> all >>> > Blink >>> platforms. >>> > >>> > >>> > >>> > 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 >>> > >>> > >>> > >>> > >>> Requires >>> > code in >>> > >>> //chrome? >>> > >>> > False >>> > >>> > >>> > >>> Tracking bug >>> > >>> > >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1122656 < >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1122656> >>> > >>> > >>> > >>> Estimated milestones >>> > >>> > M110 >>> > >>> > >>> > >>> 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/5977883141472256 < >>> https://chromestatus.com/feature/5977883141472256> >>> > >>> > 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 <mailto: >>> blink-dev+unsubscr...@chromium.org>. >>> > To view this >>> > discussion on >>> > the web visit >>> > >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXKUf6wAHB-3EdgP04%2Bcmhgis3j3M54B%3DASXGtHVJcenDQ%40mail.gmail.com >>> < >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXKUf6wAHB-3EdgP04%2Bcmhgis3j3M54B%3DASXGtHVJcenDQ%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 <mailto: >>> blink-dev+unsubscr...@chromium.org>. >>> > To view this >>> > discussion on the >>> > web visit >>> > >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV3b3BnY26B6tuGtFFYRm-K5P0U6b5_giLgB1h6PeK7ag%40mail.gmail.com >>> < >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV3b3BnY26B6tuGtFFYRm-K5P0U6b5_giLgB1h6PeK7ag%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 >>> > <mailto:blink-dev+unsubscr...@chromium.org >>> >. >>> > To view this discussion on the web visit >>> > >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8pXY9nUDxRwXTheVUCf0A81cZyfJLE7WDA%2B4%3Dqf-DiJQ%40mail.gmail.com >>> < >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8pXY9nUDxRwXTheVUCf0A81cZyfJLE7WDA%2B4%3Dqf-DiJQ%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 >>> > <mailto:blink-dev+unsubscr...@chromium.org>. >>> > To view this discussion on the web visit >>> > >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9QQoXMpH8ex%3DYJW0-3YATGXQj%3DZSuYWNXP5Pi5ciCpMg%40mail.gmail.com >>> < >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9QQoXMpH8ex%3DYJW0-3YATGXQj%3DZSuYWNXP5Pi5ciCpMg%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/CAFUtAY8Rb4sr6RyOqNqFhmU3nK7BYzzEP2ST%3DWazD_qqBnxWgw%40mail.gmail.com.
