On Tue, Oct 28, 2025 at 9:23 AM Ane Diaz De Tuesta <[email protected]> wrote:
> 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. > Chrome://flags need to be explicitly added to the UI <https://developer.chrome.com/docs/web-platform/chrome-flags#chromeflags>, and are distinct from feature flags which you can control with command line arguments <https://developer.chrome.com/docs/web-platform/chrome-flags#command-line_flags>, and > Could anyone advise on how to proceed? > > - > > Do I need to enable a specific runtime flag or Finch experiment to > activate the feature? > > I would follow this guide <https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md#command_line-switches> for explicitly enabling this flag for yourself locally (Just use --enable-blink-features=). One note to be careful about: if you try to launch a Chrome process which is already open (i.e. your stable browser) it will merely open a new window with the same process and will NOT apply new flags from the command line. Ensure you are starting a new browser instance. I like to use Canary (or a custom build), but you can also pass a distinct --user-data-dir="<path_to_directory>" as an alternative. Regarding Finch-- this is a mechanism to enable the flag in the field for real users-- but as a public web platform api change (...albeit a minimal one), this should not roll out with the finch process. Instead you can go straight to launch after manual testing (sounds like we need more of this first). > > - > - > > 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? > > I would review this step <https://www.chromium.org/blink/launching-features/#widen-review> and then this step <https://www.chromium.org/blink/launching-features/#new-feature-prepare-to-ship> . You did discuss this with developers, but I might suggest signalling (Web Perf Slack?) that it is ready for testing, with instructions on how to try it. I would also confirm if the spec wording needs a change (maybe not, maybe the previous behaviour was not compliant and now is). Overall, I don't think there needs to be much more process before moving the feature forward. > > - > > 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/CAEeF2TcU4djjjJV8XgqdNRgogp3TsRp8NkaWwNhbA7Fo6s5W8g%40mail.gmail.com.
