DUPLICATE: Native WordPress image lightbox breaks position sticky sidebar

Bugs
1

Browser: Firefox 152.0.4
OS: Windows
URL:
Video:…

Bricks Version: 2.3.8
BricksUltimate Version: 2.4.2
WordPress Version: 7.0

I have a sticky element (Bricks native “Position: Sticky”, Style > Position)
inside a sidebar block named “Legenda” (Table of Contents), placed next to
the main post content column.

  • When a post has at least one image with the native WordPress lightbox
    active (Gutenberg “Link to Media File” / Enlarge on click), the sticky
    element does NOT stick — it scrolls away with the page on Chrome/Edge.
  • When no image in the post content has the native lightbox active, the
    same sticky element works correctly on all browsers.

Reproduction (both live, real content):

:cross_mark: Sticky NOT working (native lightbox active on the first image):

https://oltrecomics.it/impara-a-disegnare-i-mecha-risorse-valide-per-tutti/

:white_check_mark: Sticky working correctly (no native lightbox on any image):

https://oltrecomics.it/scream-halloween-special-2026-rebellion-eisner/

Both pages use the exact same Bricks template (Master Magazine Layout),
same sticky configuration, same sidebar structure (“Legenda” block). The
only variable that changes is the presence of the native lightbox.

I’ve already ruled out common sticky pitfalls on my end:

  • No overflow/transform/contain on any ancestor container (verified via
    DevTools Computed panel, full ancestor chain)
  • No flex-stretch issue (align-items: flex-start correctly applied on the
    parent row splitting content + sidebar)

Console error present ONLY on the page where the lightbox is active:

Uncaught TypeError: The specifier “@wordpress/interactivity” was a bare
specifier, but was not remapped to anything. Relative module specifiers
must start with “./”, “../” or “/”.

I also tried the community-documented WordPress core workaround for this
specific error (re-hooking print_import_map() at priority 8 on wp_head,
per importmap @wordpress/interactivity | WordPress.org ).
This removed the console error, but did NOT fix the sticky issue — so the
root cause appears to be something the lightbox does to ancestor elements
(inline styles/transform via Interactivity API directives?) independent of
whether the import map loads correctly.

Questions:

  1. Is this a known conflict between Bricks’ sticky positioning and
    WordPress’s native Interactivity API lightbox?
  2. As an alternative, is there a supported way to apply Bricks’ own
    lightbox (PhotoSwipe) to images inside dynamically rendered Post Content
    (Gutenberg-authored content), so we can drop the native WP lightbox
    entirely for post images?

Happy to provide the Bricks template export or any further detail needed.

2

Hi,

I found a working temporary CSS fix:

body:has(.wp-lightbox-overlay) #brx-content {
  overflow: unset !important;
}

This resets the overflow property that the WP lightbox overlay injects on #brx-content, which is what breaks position: sticky on descendants.

Questions for the Bricks team:

  1. Is this bug already tracked in the internal bug tracker?

  2. Is there an estimated timeline for an official fix in the core?

  3. Will the fix address the root cause (the overlay modifying #brx-content overflow) or just provide a better workaround?

Thanks for your work!

3

Hi,
Thanks so much for your report!

We have already received a report about this.
We’ll update the original thread once it’s fixed. Until then, your manual fix is valid. :v:

1 Like