Copilot commented on code in PR #41351:
URL: https://github.com/apache/superset/pull/41351#discussion_r3476401731
##########
superset-frontend/packages/superset-ui-core/src/components/DropdownContainer/DropdownContainer.tsx:
##########
@@ -220,6 +325,59 @@ export const DropdownContainer = forwardRef(
}
}
+ // A "nothing overflows" verdict on the pass that consumed an item-set-
+ // change reset may reflect a transient mid-reflow measurement. When
that
+ // happens, do NOT settle immediately. Instead:
+ // • If the rAF hasn't been scheduled yet: schedule it (one-shot) and
+ // return without settling; recalculating stays true so the trigger
+ // remains mounted throughout the confirmation window.
+ // • If the rAF is already scheduled (a second layout effect run
+ // triggered by the setItemsWidth call above): also return without
+ // settling for the same reason.
+ // The rAF callback reads the DOM directly at a point where the browser
+ // has reflowed and calls the setters itself. It also resets the guard
+ // refs so subsequent effect runs (e.g. from a real resize) behave
+ // normally.
+ if (
+ newOverflowingIndex === -1 &&
+ pendingConfirmForLengthRef.current === items.length
+ ) {
+ if (!confirmationScheduledRef.current) {
+ confirmationScheduledRef.current = true;
+ const scheduledVersion = confirmVersionRef.current;
+ rafIdRef.current = requestAnimationFrame(() => {
+ rafIdRef.current = 0;
+ if (!mountedRef.current) return;
+ // A newer item-set change superseded this confirmation while the
+ // frame was queued; let the newer one's own confirmation settle.
+ if (confirmVersionRef.current !== scheduledVersion) return;
+ // Reset guard refs so future layout effect runs are unaffected.
+ pendingConfirmForLengthRef.current = -1;
+ confirmationScheduledRef.current = false;
+ hadContentAtLastChangeRef.current = false;
Review Comment:
The confirmation rAF callback can still run even if a subsequent layout
effect run already settled the correct overflowingIndex (e.g. when
`setItemsWidth(...)` triggers a rerun). In that case the queued rAF can clobber
the newer settled state. Add a guard in the rAF callback to no-op when the
pending confirmation was already cleared by a settling pass.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
