Thanks for the update Casey! Your understanding of how the change to using scroll-margin instead of root-margin for lazy loaded images is correct. The MRE provided is working as expected. Given that images near the viewport will be loaded, changing the menu implementation seems like the right path forward to me.
Regards, Traian On Tue, Dec 12, 2023 at 3:08 PM Casey Carroll <aiy...@gmail.com> wrote: > I'd like to correct my original post. I assumed lazy images did not > download until their visibility toggled from hidden to visible. It turns > out our implementation actually places those images in a child of a parent > with a hidden x-axis overflow. The images are placed outside the parent > element box and are clipped. When the lazy load's IO init dictionary uses > rootMargin, these images do not download until they are moved into the > parent's element box. Now that scrollMargin is used, they are downloaded as > soon as the page loads because they are near the viewport. > > Here is a MRE of the behavior: > https://statuesque-sheer-innocent.glitch.me/ > > On chrome v120 the lazy image does not download until you open menu level > 2. On Chrome 121+, the image will download on page load. > > At the end of the day, we should probably change our mega menu > implementation. We know Safari downloads all of these off-screen lazy > images on page load anyway. > > On Monday, December 11, 2023 at 3:52:38 PM UTC-8 Chris Harrelson wrote: > >> On Mon, Dec 11, 2023 at 3:58 AM 'Mateusz Krzeszowiak' via blink-dev < >> blin...@chromium.org> wrote: >> >>> Hi all! >>> >>> We were considering removing the lazy-loading inside the slider on shop.app >>> product pages >>> <https://shop.app/products/1592892555351?variantId=15817397174359> because >>> the images appeared too late when scrolling, even on fast connections. >>> I tested the new behaviour in Chrome Canary and it works perfectly, we >>> won't have to change anything! Also, I'm not sure how the margin is >>> configured, but in our case only the next image is loaded. This seems like >>> a really good balance between performance and saving data. >>> >> >> This is great feedback, thank you! Glad it worked for you. >> >> >>> >>> Thanks! >>> >>> On Saturday, December 9, 2023 at 6:49:24 PM UTC+1 Casey Carroll wrote: >>> >>>> Hi all! >>>> >>>> This sounds like a great addition to lazy loading behavior. I'm >>>> wondering if this change had an effect on a lazy loading strategy >>>> implemented on REI.com. >>>> >>>> Prior to 121, images with loading="lazy" tucked away in our hamburger >>>> menu did not download until the hamburger menu's visibility changed from >>>> hidden to visible. In v121 and 122 the images now download on initial >>>> render, ignoring visibility: hidden. >>>> >>>> I can achieve the old behavior by using display: none rather than >>>> visibility: hidden. However, I wonder if there are other similar >>>> implementations in the wild and if their lazy loading behavior will change >>>> as people upgrade to v121. >>>> >>>> Expected behavior (v120 and older): >>>> (Mobile viewports): >>>> 1. With the network panel open and filters set to images and >>>> "merch-zones", visit www.rei.com >>>> 2. Notice empty network panel >>>> 3. Click the hamburger menu >>>> 4. Notice all merch-zones images download >>>> >>>> (Desktop viewports): >>>> 1. With the network panel open and filters set to images and >>>> "merch-zones", visit www.rei.com >>>> 2. Notice empty network panel >>>> 3. Click on "Gifts" >>>> 4. Notice merch-zones/gifts/live.jpg image downloads >>>> >>>> I have also attached videos to explain the change. >>>> >>>> Thank you! >>>> >>>> On Tuesday, December 5, 2023 at 12:23:51 PM UTC-8 PhistucK wrote: >>>> >>>>> Well, that is debatable... Because the image is 0x0 before it is >>>>> loaded and centered, it is technically not in the viewport, but I am not >>>>> sure why it would be 0x0. I am changing the original snippet to this >>>>> (untested, just more like what I have) - >>>>> <div style="width: 100px; display: flex; justify-content: center;"> >>>>> <div><img style="width: 100%;" loading="lazy" >>>>> src="some-image.jpg"></div> >>>>> </div> >>>>> That extraneous <div> seems to cause this... I need to look into it. >>>>> I got confusing results. >>>>> >>>>> ☆*PhistucK* >>>>> >>>>> >>>>> On Tue, Dec 5, 2023 at 12:57 AM Traian Captan <tca...@chromium.org> >>>>> wrote: >>>>> >>>>>> Thanks for the update! >>>>>> >>>>>> Since this involves a lazy loaded image, and you mentioned this is a >>>>>> reduced test case, I wanted to check if the image is in viewport or out >>>>>> of >>>>>> viewport in your test page? >>>>>> >>>>>> Regards, >>>>>> Traian >>>>>> >>>>>> >>>>>> On Sun, Dec 3, 2023 at 10:01 AM PhistucK <phis...@gmail.com> wrote: >>>>>> >>>>>>> When trying to generate a reduced test case, I found the underlying >>>>>>> issue that explains the issue I was having - >>>>>>> The image is centered and has a container with a fixed width with >>>>>>> the image itself having a 100% width. >>>>>>> This is just a snippet for illustrating the structure - >>>>>>> <div style="width: 100px; display: flex; justify-content: center;"> >>>>>>> <img style="width: 100%;" loading="lazy" src="some-image.jpg"> >>>>>>> </div> >>>>>>> >>>>>>> Issue - the image does not actually use the fixed width of the >>>>>>> container (= 100%) until it is loaded. >>>>>>> As a result, a 0x0 image is centered and it is not within the >>>>>>> viewport, therefore not loaded. >>>>>>> >>>>>>> Chrome as well as Safari exhibit this behaviour, while Firefox gets >>>>>>> it right. >>>>>>> >>>>>>> I will file an issue with the reduced test case for the >>>>>>> no-dimensions-until-loaded issue. >>>>>>> >>>>>>> >>>>>>> >>>>>>> ☆*PhistucK* >>>>>>> >>>>>>> >>>>>>> On Thu, Nov 30, 2023 at 5:33 PM Traian Captan <tca...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> Will do. >>>>>>>> Would you mind sharing an example of the case you encountered so >>>>>>>> that I can test it locally? >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Nov 30, 2023 at 2:34 AM PhistucK <phis...@gmail.com> wrote: >>>>>>>> >>>>>>>>> I hit a case where even when 5 - 10 pixels of the image is in the >>>>>>>>> scrolling viewport, it is still not loaded, so hopefully it will take >>>>>>>>> care >>>>>>>>> of it as well. Let me know when this is in canary and I can try and >>>>>>>>> test it >>>>>>>>> out (at the moment I am not using lazy loading as a result). :) >>>>>>>>> >>>>>>>>> ☆*PhistucK* >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Nov 30, 2023 at 10:27 AM Traian Captan < >>>>>>>>> tca...@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> Hi Rick, >>>>>>>>>> >>>>>>>>>> Yes. I uploaded a CL that increases the spacer size by 30px: >>>>>>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/5075126 >>>>>>>>>> >>>>>>>>>> The tests are now failing as expected on Safari: >>>>>>>>>> >>>>>>>>>> https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=pr_head&max-count=1&pr=43446 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Nov 30, 2023 at 12:14 AM Rick Byers <rby...@chromium.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Interesting. Could you try to improve the tests to capture the >>>>>>>>>>> interop difference and ensure passing reflects full conformance to >>>>>>>>>>> the >>>>>>>>>>> spec? We rely on WPTs as our quantifiable measure of >>>>>>>>>>> interoperability... >>>>>>>>>>> >>>>>>>>>>> Rick >>>>>>>>>>> >>>>>>>>>>> On Thu, Nov 30, 2023 at 5:07 PM Traian Captan < >>>>>>>>>>> tca...@chromium.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Thank you Rick! >>>>>>>>>>>> >>>>>>>>>>>> I did some investigating into why WebKit is passing some of the >>>>>>>>>>>> new WPTs for lazy loaded images. >>>>>>>>>>>> I think it might be because WebKit is considering the edge as >>>>>>>>>>>> inclusive, while Blink and Gecko do not. >>>>>>>>>>>> In the following example if the spacer height is 100px Safari >>>>>>>>>>>> will report intersecting as true while Chrome and FireFox would >>>>>>>>>>>> report it >>>>>>>>>>>> as false. >>>>>>>>>>>> If the height is increased to 101px, all 3 browsers will >>>>>>>>>>>> report the intersection as false. >>>>>>>>>>>> <!DOCTYPE html> >>>>>>>>>>>> <style> >>>>>>>>>>>> #scroller { width: 100px; height: 100px; overflow: scroll; >>>>>>>>>>>> background-color: gray; } >>>>>>>>>>>> #spacer { width: 50px; height: 100px; } >>>>>>>>>>>> #target { width: 50px; height: 50px; background-color: green; } >>>>>>>>>>>> </style> >>>>>>>>>>>> >>>>>>>>>>>> <div id=scroller> >>>>>>>>>>>> <div id=spacer></div> >>>>>>>>>>>> <div id=target></div> >>>>>>>>>>>> </div> >>>>>>>>>>>> >>>>>>>>>>>> <script> >>>>>>>>>>>> let entries = []; >>>>>>>>>>>> >>>>>>>>>>>> window.onload = function() { >>>>>>>>>>>> const observer = new IntersectionObserver( >>>>>>>>>>>> callback, >>>>>>>>>>>> { >>>>>>>>>>>> rootMargin: "0px" >>>>>>>>>>>> } >>>>>>>>>>>> ); >>>>>>>>>>>> observer.observe(target); >>>>>>>>>>>> }; >>>>>>>>>>>> >>>>>>>>>>>> function callback(entries) { >>>>>>>>>>>> console.log(`isIntersecting = ${entries[0].isIntersecting}`); >>>>>>>>>>>> } >>>>>>>>>>>> </script> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Nov 27, 2023 at 11:40 PM Rick Byers < >>>>>>>>>>>> rby...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Nov 22, 2023 at 2:37 PM Yoav Weiss < >>>>>>>>>>>>> yoav...@chromium.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, that sounds like a strict improvement. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Nov 22, 2023 at 6:25 AM Traian Captan < >>>>>>>>>>>>>> tca...@chromium.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, that's correct. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Nov 21, 2023 at 9:18 PM Yoav Weiss < >>>>>>>>>>>>>>> yoav...@chromium.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Do I understand correctly that currently lazy-loaded images >>>>>>>>>>>>>>>> in CSS scrollers have suboptimal behavior and this would >>>>>>>>>>>>>>>> improve that >>>>>>>>>>>>>>>> without potentially harming other cases? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Nov 22, 2023 at 1:55 AM Traian Captan < >>>>>>>>>>>>>>>> tca...@chromium.org> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Contact emailstca...@chromium.org >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ExplainerNone >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> A short (inline) explainer would help reviewers to understand >>>>>>>>>>>>>> e.g. if this involves changes to the API surface that developers >>>>>>>>>>>>>> need to >>>>>>>>>>>>>> care about. >>>>>>>>>>>>>> Can you write a few words on the impact on developers? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Specification >>>>>>>>>>>>>>>>> https://html.spec.whatwg.org/#lazy-load-root-margin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> The spec doesn't mention anything specific around root >>>>>>>>>>>>>> margins or scroll margins (other than the algorithm name). >>>>>>>>>>>>>> Are these concepts interoperable? >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I dug around a little to try to better understand this. The >>>>>>>>>>>>> HTML spec does mention >>>>>>>>>>>>> <https://html.spec.whatwg.org/#start-intersection-observing-a-lazy-loading-element> >>>>>>>>>>>>> setting >>>>>>>>>>>>> the "scrollMargin" on the IntersectionObserver, a new property we >>>>>>>>>>>>> recently >>>>>>>>>>>>> shipped (I2S >>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Ax8rTBusZ4s/m/nogj-s-eGQAJ?utm_medium=email&utm_source=footer> >>>>>>>>>>>>> ). >>>>>>>>>>>>> While WebKit and Gecko aren't yet passing the WPT tests >>>>>>>>>>>>> <https://wpt.fyi/results/intersection-observer?label=master&label=experimental&aligned&q=scroll-margin> >>>>>>>>>>>>> for this yet, interestingly WebKit is already passing >>>>>>>>>>>>> <https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=master&label=experimental&aligned&q=image-loading-lazy-in-> >>>>>>>>>>>>> most of the newly added >>>>>>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/5023396> >>>>>>>>>>>>> WPTs for lazy loaded images in particular. So perhaps their >>>>>>>>>>>>> implementation >>>>>>>>>>>>> already handled this? >>>>>>>>>>>>> >>>>>>>>>>>>> Seems reasonable to me - LGTM1 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Summary >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Changes the lazy load intersection observer's init >>>>>>>>>>>>>>>>> dictionary to use a scrollMargin instead of a rootMargin. >>>>>>>>>>>>>>>>> This allows lazy >>>>>>>>>>>>>>>>> loading images contained inside CSS scrollers, like >>>>>>>>>>>>>>>>> carousels, to load as >>>>>>>>>>>>>>>>> expected when near the viewport instead of the current >>>>>>>>>>>>>>>>> behavior where these >>>>>>>>>>>>>>>>> images load when at least one pixel is intersecting the >>>>>>>>>>>>>>>>> viewport. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Blink componentBlink>Image >>>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EImage> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Search tagslazyload >>>>>>>>>>>>>>>>> <https://chromestatus.com/features#tags:lazyload>, >>>>>>>>>>>>>>>>> scrollmargin >>>>>>>>>>>>>>>>> <https://chromestatus.com/features#tags:scrollmargin> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> TAG reviewNone >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> TAG review statusNot applicable >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Risks >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Overall low as scroll margin also applies to the root >>>>>>>>>>>>>>>>> element thus not affecting lazy loading images that are >>>>>>>>>>>>>>>>> currently loading >>>>>>>>>>>>>>>>> with just a root margin. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *Gecko*: Positive ( >>>>>>>>>>>>>>>>> https://github.com/w3c/IntersectionObserver/issues/431) >>>>>>>>>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1864794 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *WebKit*: Positive ( >>>>>>>>>>>>>>>>> https://github.com/w3c/IntersectionObserver/issues/431#issuecomment-930602435 >>>>>>>>>>>>>>>>> ) https://bugs.webkit.org/show_bug.cgi?id=264864 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *Web developers*: Positive ( >>>>>>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1391989 >>>>>>>>>>>>>>>>> ) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *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? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> None >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Debuggability >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> None >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=master&label=experimental&aligned&q=image-loading-lazy-in- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Flag name on chrome://flagsLazyLoadScrollMargin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Finch feature nameNone >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Non-finch justification >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This feature is behind an enabled-by-default flag that can >>>>>>>>>>>>>>>>> be disabled if needed. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Requires code in //chrome?False >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Tracking bug >>>>>>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1391989 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Estimated milestones >>>>>>>>>>>>>>>>> Shipping on desktop 121 >>>>>>>>>>>>>>>>> DevTrial on desktop 121 >>>>>>>>>>>>>>>>> Shipping on Android 121 >>>>>>>>>>>>>>>>> DevTrial on Android 121 >>>>>>>>>>>>>>>>> Shipping on WebView 121 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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). >>>>>>>>>>>>>>>>> None >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>>>>> https://chromestatus.com/feature/5106926245642240 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Links to previous Intent discussionsIntent to prototype: >>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvtrmHkoOpTuD2eZYVOyFuAhP8ZFVoTuNBS8zYTVY%3DTaaQ%40mail.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+...@chromium.org. >>>>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvsUb0GEG9WNWRN7Akkowjm03gLj%2Biiq5rG8%2BzdAWMBTNA%40mail.gmail.com >>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvsUb0GEG9WNWRN7Akkowjm03gLj%2Biiq5rG8%2BzdAWMBTNA%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+...@chromium.org. >>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVhH_QxckxRLbR05jrN0CY48aQ-Ag3BypusnsyKoDTc0A%40mail.gmail.com >>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVhH_QxckxRLbR05jrN0CY48aQ-Ag3BypusnsyKoDTc0A%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+...@chromium.org. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvvCQF36A34oECY-0tpJVjTk%3D2gD_8WcwMWWAyc5_O3JFg%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvvCQF36A34oECY-0tpJVjTk%3D2gD_8WcwMWWAyc5_O3JFg%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+...@chromium.org. >>> >> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e31d74cb-ac07-4fd6-b5cd-c40e2360748en%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e31d74cb-ac07-4fd6-b5cd-c40e2360748en%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/CAFxahvv14WKtN68Dp7YXaiNwfhs9mCG5bpCy%3DH5LY3hJ2Qh8WQ%40mail.gmail.com.