bisect: temporarily disable new chrome additions to diagnose blank pages

Reported: every page renders empty in the main body even after the
audit-log defensive-wrap commit (59c6d0f). Close button also doesn't
trigger shutdown — that page is blank too. Sidebar nav still renders,
so the chrome path that runs on every page is the suspect.

Three chrome additions land all at once and are temporarily turned
off so the user can see whether bare chrome restores rendering:

1. **Sticky footer (``render_sticky_footer``)**: short-circuited with
   ``return`` at the top of the function. The CSS-injection +
   components-html iframe mechanic is the highest-suspicion item —
   if the iframe script throws or the CSS interacts badly with the
   user's Streamlit / Python build, the side effects can be
   page-killing on theirs while invisible on ours. The original body
   is preserved as ``_render_sticky_footer_DISABLED`` so re-enabling
   is a one-line change.

2. **Diagnostics sidebar (``_render_diagnostics_sidebar``)**: call
   site in ``hide_streamlit_chrome`` is gated by ``if False:``.
   Wrapping in try/except (the previous commit) caught exceptions
   but didn't help — silent partial renders inside
   ``with st.sidebar: with st.expander: ...`` can still leave the
   render stack in a bad state on some Streamlit versions.

3. **Compact-spacing CSS layer**: the ``gap: 0.5rem !important;`` on
   ``stVerticalBlock`` / ``stHorizontalBlock``, the slim heading
   margins, the slim hr / caption / expander / button / metric
   rules — all stripped back to the pre-compact ``_HIDE_CHROME_CSS``.
   The ``gap`` rule in particular is a suspect: if the user's
   Streamlit version doesn't render stVerticalBlock as a flex
   container, the rule is harmless; if it does and interacts badly
   with overflow, content could be clipped.

What's deliberately KEPT enabled:

- The audit-log calls (already wrapped from 59c6d0f).
- ``log_page_open`` calls in tool pages (already wrapped internally).
- All UI changes pre-compact (the unified tool-page layout, the
  download-button helper, etc.).

If pages render after this commit, we know it's one of the three
disabled items above and can bisect further. If they still don't
render, the cause is in code that pre-dated the audit-log work and
the bisection has to keep going.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-05-17 02:09:23 +00:00
parent 59c6d0f914
commit c0bfd4dbc9

View File

@@ -60,83 +60,29 @@ header[data-testid="stHeader"] {
footer { footer {
display: none !important; display: none !important;
} }
/* Reclaim top padding lost from hidden header. Slim the bottom too — /* Reclaim top padding lost from hidden header. */
Streamlit's default leaves several rems below the last widget. */
.stAppViewBlockContainer, .stAppViewBlockContainer,
[data-testid="stAppViewBlockContainer"] { [data-testid="stAppViewBlockContainer"] {
padding-top: 0.5rem !important; padding-top: 1rem !important;
padding-bottom: 0.75rem !important;
} }
/* Scale content to fit app window */ /* Scale content to fit app window */
.stApp { .stApp {
zoom: 0.85; zoom: 0.85;
} }
/* ---------- Compact-spacing layer ---------- */
/* Streamlit ships generous vertical rhythm (~1rem gap between every
block, 1.5rem+ above each heading, 1rem on dividers). For a desktop
data app that's a lot of empty space. Tighten the gaps without
making the layout look cramped. */
/* Gap between stacked elements inside a vertical block (the default
container around most page content). */
[data-testid="stVerticalBlock"] {
gap: 0.5rem !important;
}
[data-testid="stHorizontalBlock"] {
gap: 0.5rem !important;
}
/* Headings — tighter top space + a hair less below. */
.stApp h1 { margin-top: 0.25rem !important; margin-bottom: 0.5rem !important; }
.stApp h2 { margin-top: 0.5rem !important; margin-bottom: 0.4rem !important; }
.stApp h3 { margin-top: 0.4rem !important; margin-bottom: 0.3rem !important; }
.stApp h4 { margin-top: 0.3rem !important; margin-bottom: 0.25rem !important; }
/* st.divider() — Streamlit's default hr has 1rem above and below. */
[data-testid="stMarkdownContainer"] hr,
hr {
margin-top: 0.4rem !important;
margin-bottom: 0.4rem !important;
}
/* Markdown paragraphs — slim trailing space. */
[data-testid="stMarkdownContainer"] p {
margin-bottom: 0.25rem;
}
/* Captions — slim trailing space. */
[data-testid="stCaption"],
[data-testid="stCaptionContainer"] {
margin-bottom: 0.25rem;
}
/* Expander header padding — Streamlit's default is roomy. */
[data-testid="stExpander"] details > summary {
padding-top: 0.35rem;
padding-bottom: 0.35rem;
}
/* Button row inside columns — tighter top space. */
[data-testid="stButton"],
[data-testid="stDownloadButton"] {
margin-top: 0;
margin-bottom: 0;
}
/* File-uploader internal spacing. */
[data-testid="stFileUploader"] {
margin-bottom: 0.25rem;
}
/* Metric tiles — Streamlit pads them generously inside a row. */
[data-testid="stMetric"] {
padding-top: 0.25rem;
padding-bottom: 0.25rem;
}
</style> </style>
""" """
# NOTE: The aggressive compact-spacing layer (gap reductions on
# stVerticalBlock / stHorizontalBlock, slim heading margins, slim hr,
# slim caption / expander / button / metric padding) is temporarily
# DISABLED while bisecting the "blank pages" report. The
# ``gap: 0.5rem !important;`` on ``stVerticalBlock`` in particular is
# a known suspect — if Streamlit's vertical container isn't a flex
# layout in the user's Streamlit version, the rule is no-op (harmless)
# but if it interacts badly with overflow rules content can clip.
# Toggle this back on once the user confirms the bare chrome restores
# page rendering.
def hide_streamlit_chrome(*, gate_license: bool = True) -> None: def hide_streamlit_chrome(*, gate_license: bool = True) -> None:
"""Inject CSS to hide Streamlit's default header, menu, and footer. """Inject CSS to hide Streamlit's default header, menu, and footer.
@@ -182,9 +128,15 @@ def hide_streamlit_chrome(*, gate_license: bool = True) -> None:
require_license_or_render_activation, require_license_or_render_activation,
) )
render_license_status_sidebar() render_license_status_sidebar()
# Wrapped — a broken audit-log or filesystem permission issue must # Diagnostics sidebar is temporarily disabled while bisecting the
# NOT kill the page-body render. Errors print to stderr so the # "blank pages" report. The chrome runs on every page, so anything
# developer can still see what went wrong. # that fails here drops every page's body. Wrapping it caught
# exceptions but a silent partial-render (e.g. an open ``with
# st.sidebar:`` context that never closes cleanly because of an
# internal Streamlit hiccup) could still poison subsequent
# rendering. Toggle this back on once the user confirms the bare
# chrome restores page rendering.
if False:
try: try:
_render_diagnostics_sidebar() _render_diagnostics_sidebar()
except Exception: except Exception:
@@ -539,7 +491,24 @@ html_download_button = local_download_button
def render_sticky_footer() -> None: def render_sticky_footer() -> None:
"""Render a slim fixed-position footer at the bottom of the viewport. """TEMPORARILY DISABLED while we bisect the "blank pages" report.
The sticky-footer mechanism (CSS-injection + a components-html
iframe that appends a div to ``window.parent.document.body``) is
the most likely culprit for content disappearing — if either the
CSS or the iframe interacts badly with the user's Streamlit /
Python build, the side effects could be invisible on the
developer machine but page-killing on theirs.
Re-enable by removing this early return once we've confirmed pages
render again with the footer off. The original body is preserved
below so the fix is a one-line revert.
"""
return # noqa: E501 — bisection short-circuit; see commit notes
def _render_sticky_footer_DISABLED() -> None:
"""Slim fixed-position footer at the bottom of the viewport.
Contains a "Back to Home" link that's always visible regardless of Contains a "Back to Home" link that's always visible regardless of
scroll position. The footer is mounted as a direct child of scroll position. The footer is mounted as a direct child of