> Robert, in your case could you use the permission policy to re-enable unload events on the frame until we come up with a better fix? Or are there scenarios where you lack the ability to add "allow=" attributes to the iframe elements?
If I understand correctly, this attribute has to be set before the frames load? On Friday, 28 July 2023 at 08:15:43 UTC+1 Robert Knight wrote: > Hi Fergal, > > In the general case the frames involved in communication may be cross > origin, though I think we could find workarounds for the most common use > cases, possibly using Web Locks. > > > Could you give us some more detail on the structure of this > communication? How do you end up with a document that has a different > life-cycle to the document in question? > > Is it a long-lived hypothesis window that reacts to sites > appearing/disappearing that support Hypothesis? > > Essentially, yes. The environment consists of a "host" frame where > Hypothesis is initially loaded, a long-lived "sidebar" frame that displays > the user's annotations, and shorter-lived "guest" frames that contain > content that can be annotated. In the simple case, there is one guest frame > which is also the host frame. The sidebar is always cross-origin. The host > and guest frames may be cross origin, though they are currently same origin > in the use cases we care about most. > > The typical use case would be an ebook reader that has a container frame > (the host) with book navigation controls, and a child frame (the guest) > that contains the content for the current chapter, which gets swapped out > each time the user navigates from one chapter to another. > > Kind Regards, > Robert. > On Friday, 28 July 2023 at 04:17:05 UTC+1 Fergal Daly wrote: > >> [CC: bfcache-dev, BCC: blink-dev and others we can discuss this and get >> back with a summary, let me know if you want a CC ] >> >> On Tue, 11 Jul 2023 at 16:44, Robert Knight <robert...@gmail.com> wrote: >> >>> Hello, >>> >>> Hypothesis (https://web.hypothes.is, a web page/PDF/ebook annotation >>> tool) uses the "unload" event to signal to one end of a message channel >>> when the other end is in a frame that is about to go away. This is a >>> workaround for the lack of a "close" event in the Channel Messaging API ( >>> https://github.com/whatwg/html/issues/1766). If unload events are going >>> to be removed from the web platform, it would be useful to have a proper >>> solution for detecting when a MessagePort becomes disconnected >>> ("disentangled"). >>> >> >> I've spent some time digging into that "close" event. It does seem like a >> clear hole in the platform but there are a lot of details to get right. >> Fixing it may be an option but I don't know how quickly that could be done. >> >> I would also point out that `unload` is already pretty broken on mobile >> (and desktop Safari). If the page can enter BFCache it will not fire >> unload. This is the currently specced behaviour and the current behaviour >> on everything except Chrome Desktop and Mozilla desktop (and derivatives). >> So even if we were not deprecating unload, I think you are in need of a >> work-around (but we are definitely making that need more intense). >> >> I see that some people are using web locks as an alternative. Does that >> work for you? It only works if communication is same-origin. Channels are >> intended to work cross-origin, so it's a poor work-around. >> >> Could you give us some more detail on the structure of this >> communication? How do you end up with a document that has a different >> life-cycle to the document in question? Is it a long-lived hypothesis >> window that reacts to sites appearing/disappearing that support Hypothesis? >> >> F >> >> >>> >>> Kind Regards, >>> Robert Knight >>> >>> On Monday, 10 July 2023 at 08:13:49 UTC+1 Yoav Weiss wrote: >>> >>> Thanks for chiming in, Brandon! >>> >>> I'm glad to hear that the Enterprise constituency is comfortable with >>> the plan. >>> I'm concerned that there may be a couple other constituencies that may >>> not be: >>> >>> - Third party widgets that currently use unload to send a single >>> "end of page" beacon. fetchLater() >>> <https://github.com/WICG/pending-beacon> is aiming to be that >>> replacement, but it's not ready just yet. >>> - Enterprise SAAS providers that don't have direct and immediate >>> control over their customers' application configuration, nor on their >>> users' Enterprise Policy. >>> >>> I think that a short-lived 3P deprecation trial may address these >>> constituencies as well. Would you consider adding that to your plans? >>> >>> On Sat, Jul 8, 2023 at 12:55 AM 'Brandon Heenan' via blink-dev < >>> blin...@chromium.org> wrote: >>> >>> Hello, I'm chiming in to provide some thoughts from the enterprise >>> perspective. >>> >>> Our goal is to not block forward progress to the web, but to improve the >>> web in an enterprise-friendly way. You shouldn't ever hear me say "you >>> can't do X because it's scary to the enterprise team." You should instead >>> hear "We expect X to be risky, but here are the things we know we can do to >>> make it much less risky." >>> >>> In this case, yes, this is risky for enterprises. We can say this with >>> confidence because we've seen escalations before when we've made changes to >>> unload events (crbug.com/933153, crbug.com/953228). >>> >>> Kenji and Daisuke have been working with us, and my understanding of the >>> plan is to: >>> >>> - >>> >>> Allow developers to opt-in early to the new behavior (unload event >>> ignored) with a permission policy >>> - >>> >>> Communicate the change on chromestatus and the enterprise release >>> notes (already happening >>> >>> <https://support.google.com/chrome/a/answer/7679408?sjid=15316582819754370342-NA#skpUnload114>). >>> >>> We will provide a bug link for customers for feedback in a future >>> release. >>> - >>> >>> Reach out to enterprises and developers we expect to be affected >>> - >>> >>> Introduce an enterprise policy to allow an IT admin to control >>> unload event behavior >>> - >>> >>> Introduce a flag in chrome://flags/deprecated to allow end users to >>> control unload event behavior >>> - >>> >>> As early as M117, change the default for the policy so that unload >>> events will be ignored. This is the breaking change, and there's likely >>> to >>> be friction here. The two escalations mentioned above both resulted in >>> respins the first time they reached this point. However, this time >>> around, >>> IT admins will be able to fix their environment immediately with the >>> enterprise policy, end users will be able to fix themselves with the >>> deprecation flag, and developers will be able to fix their app with the >>> permission policy. With those mitigations in place, the risk of >>> requiring a >>> respin (or Finch rollback) due to enterprise impact is dramatically >>> reduced, and this is how we eventually successfully shipped both of >>> those >>> above escalations. >>> - >>> >>> We expect a long transition period after that. By default, the >>> unload event is ignored, but different stakeholders are able to revert >>> to >>> legacy behavior. Within enterprise, we expect the enterprise policy to >>> be >>> the most useful mitigation, and the deprecation flag is the backup for >>> BYOD >>> or unmanaged devices. For the above escalations, this migration period >>> was >>> over a year, and I'm expecting something similar this time. >>> - >>> >>> At some point in the future, we expect to remove those mitigations >>> and remove support for the unload event completely. We don't have any >>> specific dates for that yet; we will be responsive to the needs of web >>> stakeholders, enterprise and otherwise. >>> >>> The two escalations I mentioned above were successfully resolved and the >>> changes to not allow popups on page unload and to not allow synchronous >>> XHRs on page unload were shipped. Both of those changes followed >>> essentially the same plan I just laid out above, and so I think it's >>> reasonable to do the same thing here. >>> >>> >>> On Thursday, June 29, 2023 at 7:02:06 AM UTC-7 Rick Byers wrote: >>> >>> On Thu, Jun 29, 2023 at 1:47 AM Kenji Baheux <kenji...@google.com> >>> wrote: >>> >>> >>> On Thu, Jun 29, 2023 at 1:48 PM Fergal Daly <fer...@google.com> wrote: >>> >>> On Thu, 29 Jun 2023 at 01:16, Rick Byers <rby...@chromium.org> wrote: >>> >>> Hi Fergal, >>> Thanks for pushing through this contentious and challenging deprecation. >>> We discussed this in the API owners meeting today and were worried that >>> this plan seemed likely to be seriously problematic for enterprises (policy >>> opt-out is helpful, but far from a silver bullet unfortunately). To what >>> extent have you engaged with them and worked to follow the enterprise >>> breaking change policy >>> <https://www.chromium.org/developers/enterprise-changes/>? Our hunch is >>> that at 1% or 5% we'd get escalations forcing us to abandon this plan. Of >>> course, if the enterprise team is OK with it, we could always try anyway >>> and see if our hunch is right. It's possible I'm over-indexing on past >>> experiences like deprecating sync XHR in unload handlers >>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/LnqwTCiT9Gs/m/tO0IBO4PAwAJ> >>> >>> and that the enterprise world is different now, but I doubt it :-). >>> >>> >>> In addition to Daisuke's response... are you concerned about enterprises >>> that are not using fleet management and so cannot use the opt-out? If you >>> think an enterprise policy will not be sufficient, a mitigation for those >>> enterprises would be for us to publish an extension that allows anyone to >>> re-enable unload (for all sites or for specific sites) by injecting the >>> PP:unload header. Are the escalations that can't be resolved by either a >>> policy or extension? >>> >>> >>> One extra comment on the extension option (great for desktop). >>> >>> If you wonder about the mobile BYOD scenarios, where extensions don't >>> exist, then we are a bit lucky here because unload is already unreliable on >>> mobile. So, it seems extremely unlikely that we'd see mobile enterprise/edu >>> products that rely on unload on mobile. >>> >>> *Rick:* are there specific scenarios / environments that we haven't >>> covered? >>> >>> >>> I'm glad to see the conversation with the enterprise team is further >>> along than I had realized. Having skip unload events in the release >>> notes >>> <https://support.google.com/chrome/a/answer/7679408?sjid=5091298988245423514-NA#skpUnloadEv113> >>> >>> since M113 is a significant mitigation, sorry I wasn't caught up on the >>> latest. And yes some sort of user opt-out for BYOD (extension or >>> chrome::/flags, etc.) seems like an essential mitigation. I defer to the >>> enterprise team's judgement here, so if they're OK with proceeding then we >>> shouldn't let my enterprise fears block us. I expect we do need some easy >>> way for an application to signal that it really does need unload handlers. >>> Setting a permission policy is likely orders of magnitude easier than >>> converting essential unload handlers to pagehide and ensuring they're safe >>> to invoke multiple times. >>> >>> The other major constituency potentially impacted are ad networks. >>> Perhaps the next step should be a 1% finch trial where we can measure >>> various ad-related metrics? I'd defer to the judgment of the Chrome Ads >>> team (@Josh Karlin). >>> >>> Anyway, I'm personally OK with 1% stable experiments (and whatever else >>> on dev/beta). But I think we should discussing learnings from such 1% >>> experiments here publicly before approving a plan to go beyond that. >>> >>> In general Yoav and I disagree with the WebKit and Gecko feedback here >>> and suspect that your original PP default-on proposal is far more likely to >>> be a successful deprecation path for Chrome (and, should they choose to >>> follow, Edge). I can understand why Firefox and WebKit don't have the same >>> constraints around enterprises and so would choose differently for >>> themselves. Yoav and I are happy to help in the standards discussions. I'm >>> about to go on vacation for 2 weeks but Yoav said he'd follow up with you >>> privately to brainstorm next steps. Sound good? >>> >>> >>> I would love to get moving on PP:unload ASAP no matter what. It's been >>> through OT and is sitting behind a flag with some sites eager to use it. >>> I'm happy to send an I2S for that while we discuss the harder problem. We >>> hope that getting that out there can clear out a large chunk of the 1st- >>> and 3rd-party unload usage, >>> >>> >>> +1, I'd suggest doing that regardless. >>> >>> There are a few large sites that have done some legwork on >>> unload handlers (theirs and third party partners), and are interested in >>> pushing the remaining unload handlers out with PP:unload. Having allies in >>> the ecosystem (i.e. extra incentives to migrate), will be helpful going >>> forward :) >>> >>> >>> Yep I think this was Yoav and my primary concern. For chrome to have a >>> pragmatic and reasonable deprecation path given our user base, we really >>> need sites adopting such an API. If we're not going to actually ship such >>> an API then I think we'd have to give up on deprecating unload. I'd support >>> shipping this API despite the lack of support from WebKit and Gecko. >>> >>> >>> F >>> >>> >>> >>> Rick >>> >>> >>> On Wed, Jun 28, 2023 at 4:07 AM Fergal Daly <fer...@google.com> wrote: >>> >>> Hi API-owners, >>> >>> >>> I am now asking for permission to go ahead with the following concrete >>> unload deprecation plan below. >>> >>> >>> >>> - >>> >>> Tools and outreach >>> - >>> >>> M115 Enable `Permission-Policy: unload` (PP:unload) with the >>> default being enabled. This allows sites to opt-in to unload >>> deprecation. >>> - >>> >>> Outreach to 1st/3rd parties, to migrate away from using unload >>> and to enforce this with PP:unload. >>> - >>> >>> Deprecation >>> - >>> >>> M117 change the default for PP:unload so that unload handlers are >>> skipped by default for 1% of page loads >>> - >>> >>> M118 increase to 5% of page loads >>> - >>> >>> M119 (last of 2023) increase to 10% of page loads >>> - >>> >>> Evaluate progress on reduction of the use of unload >>> - >>> >>> M120-128 increase +10% gradually to 100% of page loads >>> >>> >>> Enterprise policy would allow opt-out entirely. >>> >>> >>> Obviously, the deprecation timeline is contingent on unload usage coming >>> down in response to the earlier steps. >>> >>> We expect that 10% of page loads will provide a noticeable signal to >>> sites that use unload. Also, if we were to just follow the current spec and >>> not run unload when we can BFCache (as happens on Clank/Firefox mobile and >>> all WebKit) we expect that we would skip 30-40% of unload handlers when the >>> main frame navigates. >>> >>> Decisions: >>> >>> - >>> >>> Timeline >>> - >>> >>> All navigations vs main-frame navigations only >>> >>> >>> Standardising >>> >>> We have some new data and have had some further discussions with browser >>> vendors. There's no consensus. TL;DR WebKit are opposed to any >>> Permissions-Policy but support removing unload eventually. Mozilla are >>> still discussing. >>> >>> Both Mozilla <https://github.com/mozilla/standards-positions/issues/691> >>> and WebKit <https://github.com/WebKit/standards-positions/issues/127> >>> were opposed to standardising `Permissions-Policy: unload` (defaulting to >>> on) because they worried that a containing frame might selectively disable >>> unload handlers in a child frame for malicious purposes (no specific cases >>> were discussed). >>> >>> So we flipped to the idea of having PP:unload with the default being >>> disabled. We cannot suddenly do that. We need to roll it out gradually. >>> WebKit folks are opposed to this and have suggested >>> <https://github.com/WebKit/standards-positions/issues/200#issuecomment-1596385073> >>> >>> we do a reverse origin trial instead. If our plan works out, eventually we >>> would ROT as the final nail but ROT starting now has downsides for users >>> and sites and no upside for the implementer. >>> >>> Mozilla has so far not been negative >>> <https://github.com/mozilla/standards-positions/issues/691> on the >>> Permissions-Policy off-by-default approach but they are still discussing. >>> They are concerned that disabling unloads when subframes are navigating >>> could be a problem. We found that about 1/4 of subframe navigations involve >>> an `unload` handler (most seem to involve handlers in cross-site and >>> same-site site frames). We don't have examples of sites that rely on >>> `unload` handlers in this way, although they probably do exist. Migrating >>> to `pageshow` or using PP:unload for these sites should be trivial. >>> >>> We have the option to say that PP:unload only applies to main frame >>> navigations. This would mean these sites would be completely unaffected >>> however that has some downsides. It is harder to explain and does not end >>> with full removal of `unload`. We would prefer to have this apply to all >>> navigations unless we find a good reason not to. If we were to change >>> part-way, there would be no breakage. We hope that once we drive down usage >>> in 3rd-part iframes with PP:unload that the number of unload handlers >>> running in subframe navigations decreases significantly. >>> >>> Finally there was some discussion >>> <https://github.com/w3c/webappsec-permissions-policy/issues/513#issuecomment-1564361739> >>> >>> about how Permissions-Policy off-by-default should work. Our current >>> version requires every page to set the header and every parent to set the >>> iframe `allow` attribute. This is maximally conservative. If at some point >>> later on there is agreement to standardise on something less conservative, >>> it will not break pages that have already re-enabled `unload`. >>> >>> >>> Overall it seems hard to standardise in advance but if we succeed in >>> driving down `unload` usage, other browsers are on-board with removing >>> unload. The worst case scenario would be where we implement PP:unload >>> (which the others do not agree with) but make no noticeable progress on >>> `unload` usage. If that happens we can just go with the currently specced >>> behaviour (don't run `unload` if BFCaching is possible) and maybe revert >>> the PP:unload, >>> >>> F >>> >>> On Tue, 9 May 2023 at 16:01, Fergal Daly <fer...@google.com> wrote: >>> >>> On Mon, 8 May 2023 at 17:51, Rick Byers <rby...@chromium.org> wrote: >>> >>> Hi Fergal, >>> It's exciting to see this moving forward! Just to clarify, this is >>> effectively an I2S for the unload permissions-policy, is that right? Or are >>> you also requesting permission to stop firing unload events now too? The >>> latter is going to require some significant compat analysis, but could be >>> greatly informed by the experience of having some top-level sites opt-out >>> of unload for their frame tree. >>> >>> >>> Thanks. >>> >>> We're not requesting permission to stop firing at this point. It is the >>> far-away end-point. >>> >>> >>> >>> Any plan to trigger a deprecation warning / report for the installation >>> of unload handlers? It might be tricky to find a good balance of useful >>> warnings without being too spammy. >>> >>> >>> Permission policy will do this as is with a console warning and >>> Reporting-API if you attempt to install a handler that is disallowed by >>> policy. >>> >>> >>> >>> A couple more questions / comments inline: >>> >>> On Mon, May 8, 2023 at 7:43 AM Fergal Daly <fer...@chromium.org> wrote: >>> >>> Contact emails >>> >>> fer...@chromium.org, kenji...@chromium.org >>> >>> Explainer >>> >>> >>> https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md >>> >>> Specification >>> >>> https://github.com/whatwg/html/pull/7915 >>> >>> >>> This is still marked as draft. Can you get this ready for review? If >>> it's blocked only on having a 2nd implementor show support, then I'd be >>> fine shipping based on a PR. But we should at least do what we can to >>> solicit feedback on the spec change prior to shipping. >>> >>> >>> Yes. There's nothing in the spec change that isn't in the requests for >>> positions but since neither of those are supportive yet, I have not asked >>> for review of the PR. I'm hopeful that once we have data on use on unload >>> in subframe navigations as discussed here >>> <https://github.com/mozilla/standards-positions/issues/691#issuecomment-1484997320> >>> that >>> Mozilla will be supportive. Those metrics are in 113 but based on the data >>> from beta, we need to change how we record them. >>> >>> >>> Summary >>> >>> A Permission-Policy for creating unload event listeners will be added. >>> >>> Initially, the default policy will be set to allow. From there, Chrome >>> will gradually migrate the default policy to deny (i.e. increasingly >>> disallow the creation of unload event listeners, eventually reaching a >>> state where deny fully becomes the default policy). The ultimate goal >>> is to remove support for unload event. >>> >>> Blink component >>> >>> Blink>PermissionsAPI >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPermissionsAPI> >>> >>> Motivation >>> >>> The unload event is extremely unreliable. It is ignored in most cases by >>> all mobile browsers except Firefox on Android. Furthermore, in Safari, the >>> unload event is ignored on both desktop & mobile platforms. >>> >>> In the current state, unload is a major BFCache blocker (~18 percentage >>> points reduction of hit rate for Chrome). >>> >>> The change will unlock a large fraction of that hit-rate while >>> providing an opt-out for those who need more time to migrate. It also sends >>> a clear signal that unload should not be used in new development. >>> >>> Sidenote: the spec was changed to say that unload should only run if the >>> page cannot enter BFCache, which reflects Safari’s behavior, However >>> neither Chrome nor Mozilla have implemented this behavior. In Chrome's >>> case, we believe that this would suddenly break various sites and would >>> make it hard for developers to know if/when unload may run. >>> >>> >>> Initial public proposal >>> >>> None >>> >>> TAG review >>> >>> https://github.com/w3ctag/design-reviews/issues/738 >>> >>> TAG review status >>> >>> Pending >>> >>> Risks >>> >>> Interoperability and Compatibility >>> >>> If no other browsers implement this, there is a risk that devs continue >>> to use unload widely and pages malfunction on chrome. However given that >>> alternatives to unload exist it seems entirely possible for sites that are >>> actively maintained to move off unload. >>> >>> Gecko: ( >>> https://github.com/mozilla/standards-positions/issues/691#issuecomment-1484997320) >>> >>> It's possible that pages are depending on `unload` handlers in subframes >>> for functionality even without any main frame navigation. We should try to >>> understand how common this is before breaking it. It should be possible to >>> measure how often subframe unloads fire when the mainframe is not >>> navigating. This will give us an upper bound on the size of the problem, - >>> Chrome: we have landed code to measure the occurrence of unload in >>> different scenarios. We will report back the findings. >>> >>> WebKit: https://github.com/WebKit/standards-positions/issues/127 >>> >>> >>> From a quick skim, it sounds like WebKit is already happy with their >>> tradeoff of not firing unload and doesn't see a need for an API that >>> reduces unload further, is that about right? WebKit has mostly shipped >>> heuristics here without trying to spec them first, right? In general I'm >>> not too concerned >>> >>> >>> Yes, there's no great upside for them. I believe the situation as >>> specced where unload is unpredictable and likely biased is bad for devs and >>> is probably skewing data collected via WebKit (and Chrome/Mozilla mobile) >>> but nobody is complaining. >>> >>> I believe there was support expressed offline for the prospect of >>> killing off unload. >>> >>> >>> >>> Web developers: Positive ( >>> https://groups.google.com/a/chromium.org/g/bfcache-dev/c/zTIMx7u4uxo/m/-M4IS6LDBgAJ) >>> >>> The web communities we reached out had positive reactions to our proposal >>> and we have not heard about any concrete blockers. >>> >>> 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? >>> >>> On WebView, we will introduce the Permissions-Policy but not move the >>> default to "deny". BFCache does not work on WebView, so the benefit is >>> lower. Meanwhile the risk seems higher as we have far less visibility into >>> the HTML being run in WebViews. A roll-out to WebView should be done >>> independently and in consultation with the WebView team. >>> >>> >>> Sounds like the right strategy to me, thanks! >>> >>> >>> Debuggability >>> >>> None >>> >>> 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 >>> >>> None >>> >>> >>> Please put the new policy behind a RuntimeEnabledFeature >>> <https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md>. >>> >>> It's effectively a new API so is required >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#When-is-a-flag-required> >>> >>> to have a finch killswitch. It sounds to me like it should be unlikely that >>> simply adding the new policy could break things, but maybe some scenario is >>> possible where we decide breakage in 3p iframes is bad enough to warrant an >>> emergency fix? >>> >>> >>> Yes, there will be a flag, maybe more than one. The implementation >>> details of rolling this out gradually have not been worked out. See below. >>> >>> >>> >>> Requires code in //chrome? >>> >>> False >>> >>> Estimated milestones >>> >>> M115 for availability of Permissions-Policy >>> >>> M115 is the earliest we would start to disable unload, however >>> >>> >>> Is this a typo? Or are you considering disabling the event in the same >>> release we first make the permissions policy available? >>> >>> >>> The plan is to make the PP available with a default of enabled and then >>> gradually flip the default to disabled. The details are here >>> <https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md#logistics-of-deprecation>. >>> >>> It's not particularly nice. We have the option to just stop 100% but that >>> seems fairly disruptive, >>> >>> F >>> >>> >>> >>> Link to entry on the Chrome Platform Status >>> >>> https://chromestatus.com/feature/5579556305502208 >>> >>> -- >>> 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/CAAozHLm7CR6EeL2KmBFyFpYT%3DNPXmTg4roLKV%3D7dRcCE%2BOoGwg%40mail.gmail.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLm7CR6EeL2KmBFyFpYT%3DNPXmTg4roLKV%3D7dRcCE%2BOoGwg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> >>> -- >>> Kenji BAHEUX (my how-to <http://balance/kenjibaheux>) >>> Product Manager - Chrome >>> Google Japan >>> >>> -- >>> 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/d955dd04-7aac-462a-bd85-d69df8d7d86bn%40chromium.org >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d955dd04-7aac-462a-bd85-d69df8d7d86bn%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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c0ea455b-4a0e-429a-ab68-dec68cd92700n%40chromium.org.
