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/d12c3d15-1d6d-403f-b7e2-28519cd4c608n%40chromium.org.
