intersect-resources: Always schedule pass after build

[dreamofabear]

Related to #25428.

Minor bug fix: we always need to schedule a pass after building a resource because it won't be laid out in the same pass (Resource.build is async). Surveyed the remaining "skip pass in intersection mode" cases and they look good.

Also realized we're no longer using scheduleWhenBuilt parameter at all, so removed it. For some context on "why do we even have that button", the I think the last usage was removed in #12311.

[samouri]

@choumx: is there any guarantee that the elt will be built and laid out by the time the next pass happens?

[samouri]

I had one question (see above), but seeing as this code just removes an optimization, it should be pretty safe!

[dreamofabear]

This PR makes it so there will be a pass after the element is built, at which point it'll be laid out. It might not be the very next pass -- depends on how long it takes to build.

[samouri]

For the purposes of measuring, don't we care more about layout than build?

[dreamofabear]

Not sure if this answers your question, but layout must follow build in the element lifecycle.

[samouri]

Sorry for the confusion, I'll try to ask my question more clearly.
Right now we are scheduling a measure to occur during the next pass after the build completes.

Is building the element expected to change its bounding box? Even if it does, do we care? Isn't it likely to change yet again when layoutCallback is called (and we do measure after that). Why not only measure after layoutCallback?

tldr: why are we measuring after build and after layoutCallback instead of only after layoutCallback?

[dreamofabear]

Oh, we only call layoutCallback on elements who have entered the loading rectangle. We need to measure them to know if they're inside or outside that rectangle.

I think I get what you're saying though -- there are some other somewhat subtle operation ordering here. "Build" should not affect measurements, but they're ordered as such (phases) to avoid layout thrashes. I.e. mutate all resources (build), then measure all resources, then mutate again (layout), etc.

IntersectionObserver changes this flow slightly, since it effectively "measures" before elements are built. So elements that "illegally" change their size during buildCallback will be affected. I think in practice this only happens to hide the element (e.g.amp-social-share), which the observer will pick up.