Closed Bug 1847072 Opened 1 year ago Closed 1 year ago

Home Assistant layouts are broken with :has selector enabled

Categories

(Core :: CSS Parsing and Computation, defect)

defect

Tracking

()

VERIFIED DUPLICATE of bug 1792501

People

(Reporter: dholbert, Unassigned)

References

()

Details

Attachments

(2 files)

STR:

  1. Toggle about:config pref layout.css.has-selector.enabled to true
  2. Visit https://demo.home-assistant.io/ in a browser window that's as wide as possible (at least 1000px wide, to get the layout with several columns of widgets)

ACTUAL RESULTS:
Broken layout; various components are awkwardly squashed/overlapping.

EXPECTED RESULTS:
Functional layout.

Notes:

  • this doesn't reproduce 100% of the time -- there's some sort of race condition involved -- but it's pretty reliable that I can trigger it within a few reloads, if not immediately. I haven't been able to reproduce it when I have the pref disabled.
  • If I open devtools inspector, then that usually fixes the bug immediately (i.e. the layout changes suddenly). In some cases I need to hover elements in the inspector's DOM view. So presumably this is an invalidation bug of some sort, and devtools Inspector forces some invalidation that gets us the expected result.
  • This may very well be a manifestation of some existing bug; I know dshin's working on various has-invalidation related things at the moment.

(This reproduces on my own local raspberry-pi-hosted Home Assistant instance, too.)

Severity: -- → S3

[ni=dshin to take a look when cycles are available, at least before enabling the about:config pref on Nightly. Maybe/hopefully this is just a version of a known issue & can be duped if so.]

Flags: needinfo?(dshin)

This reminds me of bug 1843019 weirdness. hmm.

Ok, maybe not that - Could be just that the card being added before/after any other restyle triggers. Since :has doesn't invalidate, it can't restyle on its own.

.column:has(> *) {
  flex-grow: 1;
}

It's not broken under 10+ reloads on local changeset for bug 1792501 on opt build, so pretty confident that this is a subset of invalidation.

(As an aside - Seems like :has(> *) is being used for something like :-moz-only-whitespace, which should eventually be identical to :empty).

Status: NEW → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1792501
Flags: needinfo?(dshin)
Resolution: --- → DUPLICATE
See Also: → 1106296

Verified dupe of bug 1792501.

I tested with Nightly before vs. after that bug landed (2023-09-14 vs 2023-09-15), with layout.css.has-selector.enabled set totrue. Broken in the "before" build, working in the "after" build.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: