Explainer for style invalidation reasons…?

[Harry Roberts]

When tracking invalidations, does anyone have anything more insightful than ’Control for…’ etc.? The only thing Google has found is this. I know Invalidation Tracking is still experimental, but any clarity on what some of the reasons are would be incredibly helpful.

Each of the below divs is shadow DOM for form inputs that are entirely unrelated to the part of the page being manipulated, so I’m keen to know what Control is and why opening a nav is triggering it.

TIA!

Harry

[Paul Irish]

It's a great question and something I've wondered as well, but never bothered to investigate.

Harry also asked this in the webperformance slack.... so I'll expand on the answer I gave there. Perhaps folks on this list have edits or thoughts...

---------------------------------

CSS Style Invalidation in Blink describes the basics of style invalidation (layout invalidation being distinct). It doesn't answer your question though..

> The only thing Google has found is this.

Unfortunately, Google search doesn't do a great job in indexing recent Chromium stuff. :/ That commit is 6 years old.  But, not a huge deal because you can usually find older code from 6years ago in today's sourcebase. Just gotta poke around https://cs.chromium.org 

It wasn't obvious to find, but this was my approach with search terms:

• `invalidation control f:blink -f:test -f:out`   --- limiting to just blink, but still 226 results and nothing stood out
  
• `invalidation \"Control f:blink -f:test -f:out` --- Hoping the opening quote will find a string, but it's a bust.
• ... some other attempts that didn't work... 
• `trace invalidation f:style control f:blink -f:test -f:out` --- Hoping some trace event instrumentation would be colocated, plus `style` in the filepath... And we finally got a promising hit:
• third_party/blink/renderer/core/css/style_engine.cc:3759
        StyleChangeReasonForTracing::Create(style_change_reason::kControl));

Clicking through and we get to https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/style_change_reason.cc;l=18;drc=8a27797c643fb0f2d9ae835f8d8b509e027c97e9

Click on it and you'll see the 5 references where it gets used..

Based on a scan of those.. it seems to be short for "form control".

My interpretation of those references.

1. <select> elems getting restyled cuz of new attributes added.. 
2. text input fields getting restyled because they were focused/unfocused. 
3. <input type=datetime> getting layout
4. <input type=password> restyled because the password was revealed. (via policy that adds revealer buttons?) 
5. The last (layout_text_control) suggests that when an <input>'s style is invalidated. Its innerEditor (which I believe is ~= the useragent shadow DOM) will be invalidated with this 'Control' reason. 

• 

As you said, the DIVs in your screenshots are these (useragent) shadow DOM elements..

I'm guessing their parent input field had focus (perhaps via autofocus?) and then focus was sent elsewhere. If it's not focus.. it's tough. I'd probably try logging all DOM mutations to spot what's happening.

Let us know if you find something out. I definitely think there's room to improve the clarity of the invalidation tracking details.

Paul

--
You received this message because you are subscribed to the Google Groups "devtools-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devtools-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/devtools-dev/634c8e96-ee8f-4902-991b-b0176fd2c27bn%40chromium.org.

[Benedikt Meurer]

+chang...@chromium.org +Rune Lillesveen +Ergün Erdoğmuş 

Thanks Paul for the detailed response. We had a side conversation with Blink/DevTools folks about this, and weren't sure what's going on here.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/devtools-dev/CAK-PPf2tMPdPaOBk1%2B70Y6oH2hCKHR7uCJhJDGOFS-ryHM7pMg%40mail.gmail.com.

--

Benedikt Meurer

Chromium DevTools Lead

bme...@chromium.org

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.