Hi everyone,
I recently merged the patch for *Layout Instability Attribution in CSS Pixels* (merged on Oct 8) and would now like to begin the first “Intent to Ship” step, testing the feature locally. I’ve installed *Chrome Dev 143.x*, where the patch should already be included (confirmed via the “Included in” tags on Gerrit). However, I’m currently unable to find the new flag I added — ReportLayoutShiftRectsInCssPixels — under chrome://flags. This flag is required to test the expected behavior locally. Could anyone advise on how to proceed? - Do I need to enable a specific runtime flag or Finch experiment to activate the feature? - Is there a build configuration or command-line flag I should use to ensure the patch is active for local testing? - Are there additional steps I should take before starting the “Intent to Ship” verification phase? Any guidance or pointers would be greatly appreciated. Thanks, Ane Le mardi 7 octobre 2025 à 16:31:27 UTC+2, Ane Diaz De Tuesta a écrit : > Hello, > I addressed last feedback and all try-jobs are now passing 🎉 > > As mentioned in my last comment in the CL, I attempted to add tests for > the null widget case, but it turned out to be quite tricky to simulate. > I’d prefer to keep the current changes as-is and move forward with merging > this CL. > > Do you think it’s reasonable to proceed with landing this patchset? > > On a related note, regarding the Element Timing issue we discussed > earlier, what would you recommend as the best next step? > Should I file a bug first, or go ahead and send a CL with the fix directly? > > Thanks again :-) > Ane > Le mardi 2 septembre 2025 à 12:19:57 UTC+2, Ane Diaz De Tuesta a écrit : > >> Hello, >> >> I’ve addressed the comments on my review. As mentioned in one of them, >> I’ve had some difficulties running tests locally due to issues with my >> machine. >> >> I think it would be best to run try jobs to identify any remaining >> modifications needed before the CL can be merged. Could you please run them >> for me, since I don’t have the rights to do so? >> >> >> Thanks again for your help! >> >> Le vendredi 8 août 2025 à 20:00:05 UTC+2, Michal Mocny a écrit : >> >>> Absolutely-- fantastic of you to put in the effort to contribute! Enjoy >>> your time off. >>> >>> -Michal >>> >>> On Fri, Aug 8, 2025 at 1:43 PM Ane Diaz De Tuesta <[email protected]> >>> wrote: >>> >>>> Hello, >>>> Thanks for your code review and your feedback! >>>> >>>> I am currently on PTO until the last week of August, and I'll address >>>> your comments once I'm back. >>>> Many of the issues in my patch stem from my lack of familiarity with >>>> the codebase, the libraries and the language, I really appreciate your >>>> guidance and the opportunity to learn so much. >>>> >>>> I'll follow up with you in a few weeks :-) >>>> >>>> Best regards, >>>> Ane >>>> >>>> On Fri 8 Aug 2025 at 19:21, Michal Mocny <[email protected]> wrote: >>>> >>>>> (Sorry, was OOO last week) >>>>> >>>>> I think the CL is ready for landing (~few more small review comments >>>>> and potential test updates). >>>>> >>>>> The feature flag right now is marked for Origin Trial, but I don't >>>>> think OT is a good fit for this change. Instead we can set the feature >>>>> as >>>>> experimental, publicize the proposed change, clarify the spec (if >>>>> needed), >>>>> and then start a finch rollout process while watching for surprise >>>>> feedback. I can help walk through that process once this lands! >>>>> >>>>> -Michal >>>>> >>>>> On Mon, Aug 4, 2025 at 7:56 AM Ane Diaz De Tuesta <[email protected]> >>>>> wrote: >>>>> >>>>>> Thanks a lot for the clarifications! >>>>>> >>>>>> Sounds good, I’ll wait for Michal’s input here, and if he’s >>>>>> unavailable, I’ll look for another code OWNER to approve the CL. By the >>>>>> way, in that case, what’s the recommended way to assign someone else as >>>>>> a >>>>>> reviewer? >>>>>> >>>>>> I’m also aligned with the idea of being transparent and publicly >>>>>> surfacing the change. Just to double-check: you’re suggesting the need >>>>>> (or >>>>>> not) for an I2S really depends on whether the metrics team considers it >>>>>> to >>>>>> be a compat-affecting change that warrants mention in the changelog, >>>>>> right? >>>>>> That makes sense to me. >>>>>> >>>>>> I like the proposal of enabling the flag by default starting with a >>>>>> specific Chrome version while keeping it as a kill-switch, just in case. >>>>>> For what it’s worth, my team will be impacted by this change in >>>>>> production >>>>>> — we currently use the layout-shift attribution data (previous + current >>>>>> rects) together with the DPR of the screen where the CLS was recorded to >>>>>> transform those rects into CSS pixels and overlay them on the DOM. >>>>>> Having a >>>>>> way to control when the new behavior kicks in will indeed be extremely >>>>>> helpful for us to roll out our internal changes safely. >>>>>> >>>>>> Thanks again for your guidance and quick responses!☀️ >>>>>> >>>>>> Best regards, >>>>>> Ane :-) >>>>>> >>>>>> >>>>>> On Fri 1 Aug 2025 at 18:00, Rick Byers <[email protected]> wrote: >>>>>> >>>>>>> In terms of the process, yes we do just land CLs behind flags (off >>>>>>> by default, potentially turned on by the >>>>>>> enable-experimental-web-platform-features flag). No approval is needed >>>>>>> here >>>>>>> for that, just from code OWNERS reviewing the CL (probably Michal in >>>>>>> this >>>>>>> case, but could be others too if he's busy - should be low risk as long >>>>>>> as >>>>>>> the flag isn't on by default). >>>>>>> >>>>>>> In fact I think there's an argument that you don't need an I2S at >>>>>>> all for this as a bug fix. But the compat risk is non-trivial enough >>>>>>> that >>>>>>> perhaps biasing in favor of the transparency and public discussion >>>>>>> seems is >>>>>>> a good idea. Michal, I don't think you've historically done an I2S for >>>>>>> other metrics semantics tweaks in the changelog >>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/speed/metrics_changelog/README.md>, >>>>>>> >>>>>>> right? Is this case any different and so worth doing an I2S for you >>>>>>> think? >>>>>>> I'm happy to defer to the metrics team judgement on this as the chance >>>>>>> of >>>>>>> any user-visible breaking change is IMHO near zero (close to that of >>>>>>> any >>>>>>> other blink bugfix). >>>>>>> >>>>>>> In terms of 'progressively enabling the flag', it's really a >>>>>>> judgement call on how best to do that per feature. In this case I think >>>>>>> I'd >>>>>>> personally bias towards just deciding whether we think it's safe to >>>>>>> turn on >>>>>>> and then just enabling it 100% for a certain Chromium release. That way >>>>>>> developers can at least compare the values to the Chrome version number >>>>>>> if >>>>>>> needed to determine the precise semantics. But we'd leave the flag >>>>>>> there as >>>>>>> a 'kill switch' we could flip if needed in the event of any serious >>>>>>> breakage (and thereby end up breaking the correlation between version >>>>>>> number and semantics unfortunately). Since this really does feel like a >>>>>>> bug >>>>>>> fix that shouldn't impact user-visible functionality, I think any >>>>>>> process >>>>>>> involving A/B testing is overkill (and also risks causing more >>>>>>> confusion >>>>>>> with developers than benefit). >>>>>>> >>>>>>> Thanks, have a great vacation! >>>>>>> Rick >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Aug 1, 2025 at 2:43 AM Ane Diaz De Tuesta <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Thanks, I completely agree, the more we can highlight >>>>>>>> interoperability and cross-browser compatibility, the better, >>>>>>>> especially as >>>>>>>> we move toward the *Intent to Ship* stage. >>>>>>>> >>>>>>>> My plan is to go step by step: first land the fix, then >>>>>>>> progressively enable the flag, assuming that’s aligned with how we >>>>>>>> usually >>>>>>>> handle this in the Blink Intent process (this is my first time going >>>>>>>> through it, so I really appreciate the guidance). >>>>>>>> >>>>>>>> Regarding compatibility bugs for Mozilla and WebKit, I can take a >>>>>>>> look at filing those after I return from vacation (I’ll be off for the >>>>>>>> next >>>>>>>> 3 weeks starting today). I’m not entirely sure how to approach that >>>>>>>> part, >>>>>>>> so any help on that front would be appreciated. >>>>>>>> >>>>>>>> >>>>>>>> Excited to hear your thoughts, Michal Mocny. >>>>>>>> >>>>>>>> /Ane >>>>>>>> >>>>>>>> Le jeudi 31 juillet 2025 à 13:33:16 UTC+2, Daniel Bratell a écrit : >>>>>>>> >>>>>>>>> I agree that it seems like a good idea, and the only concern would >>>>>>>>> be whether it will break things. It sounds like Michal Mocny has been >>>>>>>>> on >>>>>>>>> top of things, but what were his findings? >>>>>>>>> >>>>>>>>> Once it comes to the shipping decision, the more you can say about >>>>>>>>> interoperability and compatibility, the better. >>>>>>>>> >>>>>>>>> For compatibility between browsers, are there bug issues in the >>>>>>>>> Mozilla and WebKit databases already? If not, it would be great if >>>>>>>>> you >>>>>>>>> could file some so that they end up making the same fix. >>>>>>>>> >>>>>>>>> /Daniel >>>>>>>>> On 2025-07-31 08:17, Ane Diaz De Tuesta wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> It’s been about 10 days since I shared the Intent to Prototype >>>>>>>>> proposal, and from what I gather, it has been generally well received. >>>>>>>>> >>>>>>>>> As I’m not entirely familiar with the process, I’d like to suggest >>>>>>>>> the following next steps—unless there are any objections: >>>>>>>>> >>>>>>>>> - >>>>>>>>> >>>>>>>>> Merge the CL >>>>>>>>> - >>>>>>>>> >>>>>>>>> Update the feature status to *“Prepare to ship”* on >>>>>>>>> ChromeStatus >>>>>>>>> - >>>>>>>>> >>>>>>>>> Begin drafting the *Intent to Ship* email >>>>>>>>> >>>>>>>>> Please let me know if you agree with this approach, or if there’s >>>>>>>>> anything else I should address before moving forward. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Le mercredi 23 juillet 2025 à 14:03:28 UTC+2, Michal Mocny a >>>>>>>>> écrit : >>>>>>>>> >>>>>>>>>> I do suspect this was more of an oversight than a specific >>>>>>>>>> decision, and feedback from developers seems to align with Ane Diaz: >>>>>>>>>> most >>>>>>>>>> are having to work around this. >>>>>>>>>> >>>>>>>>>> However, there are clients out there who now depend on this and >>>>>>>>>> we are reaching out to see if it's less of a total headache to fix >>>>>>>>>> in place >>>>>>>>>> or provide some pathway for compat. Because this is mostly used for >>>>>>>>>> logging / tooling and not for real time user experience, so far the >>>>>>>>>> feedback has been mostly that this would be fine to break and easy >>>>>>>>>> to fix >>>>>>>>>> -- but there are a few other consumers we want to get feedback from. >>>>>>>>>> >>>>>>>>>> On Tue, Jul 22, 2025 at 5:45 PM Rick Byers <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Sounds like a valuable improvement, thank you! >>>>>>>>>>> >>>>>>>>>>> I see you're talking with @mmocny on the CL >>>>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/6624567>, >>>>>>>>>>> >>>>>>>>>>> that's great. I wonder if this was just an oversight in our initial >>>>>>>>>>> design? Seems like a bug to me. Think we can just switch it (and >>>>>>>>>>> put the >>>>>>>>>>> change on the changelog >>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/speed/metrics_changelog/cls.md>) >>>>>>>>>>> >>>>>>>>>>> without causing compat issues? Or might we need to give devs a way >>>>>>>>>>> to >>>>>>>>>>> opt-in to the new semantics? mmocny@ is the expert here though, so >>>>>>>>>>> I'm >>>>>>>>>>> happy with whatever he wants to do. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Rick >>>>>>>>>>> >>>>>>>>>>> On Tue, Jul 22, 2025 at 5:00 PM Ane Diaz De Tuesta < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> I'd like to announce an Intent to Prototype for: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - *Feature name:* Layout Instability Attribution in CSS >>>>>>>>>>>> Pixels >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - *Contact:* anediaz@gmail >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - *Explainer:* >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/anediaz/layout-shift-attribution-in-css-pixels/blob/main/Explainer.md >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - *Summary:* The Layout Instability API currently reports >>>>>>>>>>>> attribution rectangles (`prevRect` and `currentRect`) in device >>>>>>>>>>>> pixels, >>>>>>>>>>>> which vary based on resolution and `devicePixelRatio`. This >>>>>>>>>>>> change proposes >>>>>>>>>>>> reporting them in CSS pixels for consistency with other layout >>>>>>>>>>>> and >>>>>>>>>>>> performance APIs. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - *Motivation:* This will align attribution with other Web >>>>>>>>>>>> APIs, such as `getBoundingClientRect()` and make layout shift >>>>>>>>>>>> data easier >>>>>>>>>>>> to visualize, debug, and combine across devices and tools. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - *Initial public proposal:* >>>>>>>>>>>> https://issues.chromium.org/issues/399058544 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - *TAG review:* Not yet requested >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - *Risks:* None known. This change only affects how >>>>>>>>>>>> attribution data is reported, and is gated behind a runtime >>>>>>>>>>>> flag. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - *Interoperability:* >>>>>>>>>>>> - Mozilla: No signal >>>>>>>>>>>> - WebKit: No signal >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - *Estimated milestones:* N/A (this is a prototype only) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - *Footprint:* This will be implemented behind a runtime >>>>>>>>>>>> flag. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - *Link to entry on Chrome Platform Status: * >>>>>>>>>>>> https://chromestatus.com/feature/5155103518228480 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This Intent is to begin prototyping the feature and gather >>>>>>>>>>>> feedback. >>>>>>>>>>>> >>>>>>>>>>>> Thank you for your help and time. >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Ane Diaz de Tuesta >>>>>>>>>>>> -- >>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>> To view this discussion visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACBGQem%2BV6_UiLktmqwDCSXC3RJaMpmNm%3DSxv%2BH6%3DY4yCk5Msg%40mail.gmail.com >>>>>>>>>>>> >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACBGQem%2BV6_UiLktmqwDCSXC3RJaMpmNm%3DSxv%2BH6%3DY4yCk5Msg%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 [email protected]. >>>>>>>>> >>>>>>>>> To view this discussion visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/15ac55eb-46bc-44d4-b50b-517d21fb27een%40chromium.org >>>>>>>>> >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/15ac55eb-46bc-44d4-b50b-517d21fb27een%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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0f73b353-45bc-4a20-bf49-eea21870ad27n%40chromium.org.
