about ui.popup docs

[SHDocter]

I'm not sure, but it seems like the demonstration code in the document isn't working? There's just a label, and clicking on it doesn't trigger any response.

[evnchn]

Drafted by Claude Code on evnchn's behalf.

Not broken — the label text itself is the button. ui.popup opens whatever element it's nested inside, and in this demo that's the bare ui.label(): click directly on the words "NiceGUI User" and it opens (the input that appears is bound to the same value, which is the point of the demo). It just has no pointer cursor or hover state, so it reads as static text — #6207 gives it a cursor-pointer so the next reader isn't caught out.

Evidence

Clicked with Playwright on https://nicegui.io/documentation/popup, unmodified:

viewport	opens as	inputs after click	console errors
1280 px	.q-menu	1	none
400 px	.q-dialog	1	none
iPhone 15 / Pixel 7 (tap)	.q-dialog	1	none

Menu above the breakpoint, dialog below it — as documented. Also verified on a local nicegui==3.15.0, demo code verbatim, both inside @ui.page and copy-pasted at module level.

Why it reads as inert — measured on the anchor:

box            : 82.5 x 23.8 px
cursor         : auto          <- no pointer
classes        : (none)
aria-haspopup  : None

--- click 30px below the label (inside demo panel, outside anchor) ---
opened? False
--- click the label text itself ---
opened? True

So it's binary on hitting an unmarked ~83x24 px region that looks like prose. ui.menu's demo anchors on a ui.button and ui.context_menu's on a ui.image; ui.popup's is the only one of the three with no affordance.

The PR's A/B, booting the real website entrypoint and reading getComputedStyle(anchor).cursor:

tree	classes	cursor	still opens
upstream/main	''	auto	yes
with the change	'cursor-pointer'	pointer	yes

Opens in both, so it's purely the affordance — no behaviour change.

Ruled out along the way: deployed-site breakage, version mismatch (an older release would raise AttributeError, not render a silent label), app.storage.client needing a page context (it's a plain context.client.storage, no guard), touch-only failure, and the anchor's empty class attribute (normal — ui.label ships _default_classes == []).

[SHDocter]

I tried it again, and it seems to have an unknown issue in Firefox, but everything is normal in Chrome and Edge.

• click label
• check devtool
• you can see <div id="q-portal--menu--2">...</div>
• click label again
• "q-portal--menu--2" will be destroy

But in the browser, users won't see any changes, and no input box will appear.

[evnchn]

Drafted by Claude Code on evnchn's behalf.

Not reproducing on Firefox 150 — and your DOM evidence is the useful clue: the portal mounts and unmounts correctly, so Quasar is working and only the paint is missing, which usually means something environment-side.

Could you retry in Troubleshoot Mode (☰ → Help → Troubleshoot Mode…, which disables extensions and hardware acceleration at once) and post your Firefox version + OS? If it works there, a page-restyling extension (Dark Reader is the usual suspect for invisible overlays) or GPU compositing is the cause.

What I checked, and what it doesn't prove

Playwright Firefox 150.0.2 on macOS, against the live https://nicegui.io/documentation/popup, unmodified. Every variant opened and painted:

variant	overlay	painted?
headless, 1280 px	.q-menu 166×56, position: fixed, visibility: visible, opacity: 1	yes — elementFromPoint at its centre returns the INPUT, focused, value NiceGUI User
headed, 1280 px	.q-menu 193×56	yes
headed + headless, 400 px	.q-dialog 400×900	yes (dialog mode, below the 450 px breakpoint)
prefers-reduced-motion: reduce	.q-menu 193×56	yes
dark colour scheme	.q-menu 193×56	yes
5 consecutive loads, different Fly machines	.q-menu 193×56 each	yes, input present every run

Ruled out along the way:

• Blocked or wrong-MIME assets — recorded every response across the 5 loads: no 4xx/5xx, no .css served as anything but text/css, no .js with a non-JS type. The one Firefox console warning (fuse.js served as application/octet-stream) is non-blocking; Firefox loads it anyway.
• Quasar's CSS not applying — injecting a bare .q-menu div computes position: fixed, so the stylesheet is live.
• A bad edge server — all 5 loads hit the site fresh and agreed.

What this does not prove: it's Playwright's Firefox build, on macOS. A stock-Firefox-only, profile-specific, or GPU/driver-specific paint failure wouldn't surface here — which is exactly why Troubleshoot Mode is the discriminating datapoint rather than more runs on my side.

If it still fails in Troubleshoot Mode, the most useful thing you could grab from devtools: select the .q-menu inside q-portal--menu--N and paste its getBoundingClientRect() plus computed visibility, opacity, position, transform and z-index. That separates "painted offscreen" from "painted transparent" from "collapsed to zero size", and each points at a different cause.

[SHDocter]

firefox version: 153.0
windows version: windows 11 25H2

in Troubleshoot Mode:

[evnchn]

Drafted by Claude Code on evnchn's behalf.

Found it — this is a Firefox 153 regression, not your machine. Nothing is wrong with your setup, and my extensions/GPU guess was wrong; thanks for the Troubleshoot Mode run that killed it.

Firefox 152 renders the demo fine; 153 fails, on the unmodified page, with no extensions and no config changes. Your dump matches mine field for field.

Workaround until it's fixed upstream — one line, at module scope:

ui.add_css('.q-menu { min-width: 1px }', shared=True)

(inside a @ui.page function, drop the shared=True). Verified on Firefox 153.0.1 against a real app. Note it applies app-wide to every Quasar menu — narrow the selector if you have menus that rely on being zero-width. The 1px is enough because it only has to get past a zero-size check; once the popup is positioned, its content determines the real width.

Root cause, version A/B, and the fix

Why it breaks. Quasar hides every popup with .q-position-engine { visibility: collapse } and only clears it once setPosition() has measured and placed the element. visibility is inherited, so the collapse reaches the menu's contents — and NiceGUI's input renders as label.q-field.row, where Quasar's row is display: flex; flex-direction: row.

Firefox is the only engine that implements visibility: collapse on flex items (since Firefox 29, bug 783470); Chromium and WebKit treat it as hidden, which is why Chrome and Edge are unaffected. A collapsed flex item is zeroed along the container's main axis — horizontal here. (In the reduced test case below that axis behaviour is directly visible. On the live page the surviving 56 px is weaker evidence than it looks, since Quasar hardcodes .q-field__control { height: 56px } — the height was never content-derived.)

What appears to have changed in 153 — this is my inference from the observed behaviour, not something I bisected to a Gecko commit: previously the collapsed item was 0-wide but that zero did not propagate to the flex container's intrinsic width; now it does. Either way the measured outcome is that the shrink-to-fit position: fixed menu computes to width 0 — and setPosition() refuses to position an element whose offsetWidth is 0, retrying six times over ~50 ms before giving up permanently. The visibility: visible and the inline top/left are written only after that guard, so they are never written at all. The collapse causes the zero width, and the zero width prevents the collapse from ever being cleared. That is also why clicking again doesn't help.

Version A/B, real Mozilla builds via geckodriver, https://nicegui.io/documentation/popup unmodified, no CSS injected, no prefs changed. I ran the first two rows myself, twice:

Firefox	.q-menu
152.0 (20260610172436)	visible, 193×56, positioned
153.0.1 (20260727124451)	collapse, 0×56, never positioned

A wider automated sweep (same harness, not individually re-run by me) extends it: 151.0 and 152.0.6 also fine; 154.0 and 155.0a1 also broken; Chromium 149 fine at 166×56. So the boundary sits between 152 and 153 and every later build I tried stays broken.

Yours vs. mine on 153.0.1 — identical, y differing only because the portal sits at the document bottom and your page is shorter:

you : visibility "collapse" opacity "1" position "fixed" transform "none" zIndex "6000"
      rect {x:0, y:1279,  width:0, height:56}
mine: visibility "collapse" opacity "1" position "fixed" transform "none" zIndex "6000"
      rect {x:0, y:10803, width:0, height:56}

Isolated mechanism test — a shrink-to-fit position: fixed box with visibility: collapse around one 193×56 child:

inner container	FF 151/152	FF 153/154/155	Chromium	WebKit
flex-direction: row	193×56	0×56	193×56	193×56
flex-direction: column	193×0	0×0	193×56	193×56
display: block	193×56	193×56	193×56	193×56

Ruled out, all measured on the real page and all still working: 26 Firefox configurations including browser.zoom.full=false (Zoom Text Only), layout.css.devPixelsPerPx 0.8/1.5/2.0, minimum font size 24/32/48, privacy.resistFingerprinting, privacy.fingerprintingProtection, forced colours / browser.display.document_color_use=2, browser.display.use_document_fonts=0, non-native scrollbars, reduced motion, 600 px and 1280 px viewports, and combinations. A larger minimum font size only made the menu wider. I could not reproduce any configuration-based cause; in my tests the version boundary is the controlling factor.

Workarounds, tested on Firefox 153.0.1 against the real page:

CSS	Result
none	broken, 0×56
.q-menu { min-width: 1px }	fixed, 193×56 positioned
.q-position-engine { visibility: hidden }	fixed, 193×56 positioned
.q-menu .q-field.row { flex-wrap: wrap }	still broken
.q-menu { width: max-content }	still broken
.q-menu { display: block }	still broken

It has to come from a stylesheet, not ui.popup().style(...) — setPosition() does Object.assign(targetEl.style, { minWidth: null, ... }) and wipes an inline value.

Upstream. This is Quasar's positioning engine, not NiceGUI's popup logic, and it is already reported: quasarframework/quasar#16167 — open since 2023, Firefox-only, triggered there by a flex-direction: column div, which zeroes the vertical axis and trips the same guard on offsetHeight. Same bug, rotated 90°, which is why every previous report talks about height and yours is width. Firefox 153 widened the blast radius from "menus containing a flex column" to "any menu containing a flex row" — which is every ui.input in a popup.

I confirmed both axes on stock Quasar 2.18.5 with no NiceGUI involved — a menu containing a bare div.row vs div.column: on Firefox 152 the column case is broken and the row case works; on Firefox 153 both break; the one-line change below repairs all of them, and is a no-op where they already worked.

The visibility: hidden line above is a candidate fix to evaluate upstream, not a proven one: it hides identically and has no layout effect in any engine, whereas collapse does in Gecko — but collapse may have been chosen for something the source comment doesn't spell out. I'll raise it there rather than assume.

[evnchn]

Drafted by Claude Code on evnchn's behalf.

Fix is filed upstream: quasarframework/quasar#18468 — one line in Quasar's position engine, resolving their quasarframework/quasar#16167 (open since 2023).

Until it lands and NiceGUI ships a Quasar release containing it, the min-width workaround above remains the fix.

What was verified before filing

.q-position-engine switches from visibility: collapse to visibility: hidden — same intent, but without the layout semantics only Gecko implements.

Checked across 9 popup content shapes (plain, flex row, flex column, q-list, <table>, long scrolling menu, fit, QTooltip, QSelect), measuring popup geometry before vs after:

• Chromium and WebKit — all 9 byte-identical. A measured no-op, as expected since those engines already treat collapse as hidden.
• Firefox — every case that already worked is byte-identical; only the broken ones change. After the fix, Firefox 153 geometry equals Firefox 152 geometry exactly, so it restores pre-regression behaviour rather than introducing new behaviour.
• No paint-before-positioned flash: sampled every animation frame for 400 ms after opening, zero frames where the popup was visible while unpositioned.
• Quasar's suite: 1348/1348 passing on both the baseline and patched builds, compiled CSS confirmed, lint and git diff --check clean.

Honest caveat carried into the PR: Quasar's test suite is jsdom-only and never renders .q-position-engine, so that green result proves no unrelated logic broke but is weak evidence for this specific change — the browser matrix is the real evidence. Cordova and Electron were not tested.

[evnchn]

Merged quasarframework/quasar#18468

@falkoschindler age old question again: fix hot patch in NiceGUI, or get to do a bump?

[falkoschindler]

Great work, @evnchn! 🎉

Since bumping Quasar means jumping from 2.18.5 to 2.23.4+, that's something we can only do in NiceGUI 4.0. So let's hot-patch: Would you like to open a PR adding the one-line override .q-position-engine { visibility: hidden; } to our nicegui.css? Please mark it with a DEPRECATED comment pointing to quasarframework/quasar#18468 — that's the marker we grep for when preparing a major release, so it will get cleaned up with the Quasar bump.