//! Publishing layout's scroll containers into the [`ScrollManager`].

//!

//! This ran in the dll, AFTER `layout_and_generate_display_list` returned, and

//! the e2e runner carried a hand-maintained port of it. So there were three

//! answers to "which nodes are scrollable and how big are they": the dll's,

//! the runner's, and whatever each `layout/tests` test hand-seeded — and a

//! test could seed a scroll state production would never produce, which is

//! exactly the divergence that let scroll bugs hide from the suite.

//!

//! It lives here now and all three call it.

use azul_core::{

    dom::{DomId, NodeId},

    task::Instant,

};

use crate::{solver3::layout_tree::LayoutNodeId, window::LayoutWindow};

        // What the VirtualView callbacks published for this DOM, read the way

        // `display_list::paint_scrollbars` reads it — same producer, same

        // `children_rect.size`, so the two cannot disagree about the extent.

        // Snapshotted before the registration loop mutates the manager;

        // registration never touches `virtual_scroll_size`.

            };

            // CSS spec: scrolling occurs within the padding box, so the

            // viewport for scroll clamp must be padding-box, not content-box.

            // This must match compute_scrollbar_geometry() which also uses

            // padding-box (inner_rect = paint_rect - borders).

            // STATIC (unscrolled) layout coordinates, NOT window coordinates —

            // the comment here used to claim otherwise. `scroll_selection_into_view`

            // depends on static, because it compares against a caret rect measured

            // the same way. A consumer that needs where the container APPEARS must

            // subtract the scroll of its ancestors itself.

            else {

            };

            // A VirtualView's scrollable extent does not exist during layout —

            // it is whatever its callback just published. Amend the flags here,

            // where both the tree and the ScrollManager are in reach, and store

            // the answer back so every later consumer (the GPU thumb updater

            // `update_scrollbar_transforms`, the registration below, the

            // hit-test scrollbar states) reads one decision rather than

            // re-deriving it. `paint_scrollbars` calls the same function while

            // building the display list, which is why the numbers agree.

                );

            // Use the layout-computed scrollbar width, not the

            // hardcoded default. On macOS with overlay scrollbars,

            // scrollbar_width is 0.0 (no layout space reserved).

            // The scroll_manager falls back to DEFAULT_SCROLLBAR_WIDTH_PX

            // when thickness is 0 for hit-test geometry.

            );

        }

    }