PR State:
merged
PR:
#685
Commit:
f5399f4601c20f309d83a017f3dd985cf89ee066
[FIX] viin_brand_web: scope the navbar hover/active hook guard to the regular navbar
test_navbar_menu_entry_interactive_states_use_deep_chrome_rung asserted
that core never DECLARES --NavBar-entry-backgroundColor--hover/--active,
because the var() fallback those hooks read is what carries the brand's
deep chrome rung. It checked that with a substring scan over the whole
compiled web.assets_backend, so any declaration anywhere tripped it.
viin_customizer declares both hooks to theme its own dark top bar:
`.customizer_container .customizer_navbar .o_main_navbar { ... }`. That
rule never applies to the regular web client navbar, so the brand rung
there is untouched, yet the scan reported it as core re-declaring the
hook and the test went red as soon as viin_customizer was installed.
The guard now collects only the declarations whose selector can reach
the regular navbar entries - the entry itself or any ancestor on the
NAVBAR_ANCESTORS chain, including class-less subjects such as :root.
Custom properties inherit, so an ancestor-level declaration counts; a
declaration under a context the navbar is not in does not. The check
cannot be left to the cascade resolution further down: that walks only
the entry, so a `.o_main_navbar` declaration inherited from above would
stay invisible to it.
Verified on 19.0 with viin_brand_web and viin_customizer installed:
the old guard fails with "'--NavBar-entry-backgroundColor--hover:'
unexpectedly found", the new one passes, and temporarily adding
`.o_main_navbar { --NavBar-entry-backgroundColor--hover: #00bbce }` to
the brand bundle still makes it fail.
Signed-off-by: David Tran <david.tran@tvtmarine.com>
Branch:
19.0