fix(core): css lost to a local value or a late attribute assignment - #11371

PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed the CLA.
• All existing tests are passing: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/DevelopmentWorkflow.md#running-unit-tests-application.
• Tests for the changes are included - https://github.com/NativeScript/NativeScript/blob/master/tools/notes/WritingUnitTests.md.

What is the current behavior?

Two regressions from #11361, both of which leave the wrong css applied in a real app. Each was confirmed by running the same scenario against the commit before that PR.

1. An attribute selector stops matching when the attribute is assigned after the view is inserted

AttributeSelector.mayMatch was narrowed to this.attribute in node, dropping the selector from the candidate set for a node that does not carry the attribute yet. Assigning a plain instance value raises no <attribute>Change event and does not invalidate the match, so the selector is never reconsidered and the rule never applies.

label[ngcontent] { color: red; }

const view = new Label();
root.addChild(view); // parent is loaded -> the css state is computed here
view.ngcontent = ''; // marker assigned after insertion

This is the shape Angular's emulated view encapsulation produces (.foo[_ngcontent-ng-c123]), so it can take out a component's styles wholesale. It also reproduces with the attribute on an ancestor (stacklayout[foo] label) and combined with a class (label.mid[foo]).

2. A local value permanently destroys the css value it shadows

CssProperty keeps a single value, so a local write both suppresses the css write and takes the slot: clearing it leaves the property at its default with the cascaded value gone. CssState recorded the value as applied either way, and the unchanged-value diff then skipped it for good — a full re-match included.

// label { margin: 4 }
view.style.marginTop = 20;         // local value wins, as designed
view.style.marginTop = unsetValue; // released
// -> marginTop is 0, and stays 0

Before #11361 the diff never fired (the delete ran ahead of the comparison), so css was re-asserted on every update and this was invisible. Verified for color, margin and padding (via the shorthand and via the longhand), for inherited properties, for a local value set before css ever ran, and for applyInlineStyle. Real triggers are Angular [style.x] / ngStyle bindings going null (the renderer calls removeStyle, which sets unsetValue), a style="..." attribute later cleared, and any code doing view.style.X = … then resetting it.

What is the new behavior?

1. AttributeSelector.mayMatch returns true again. The selector stays a candidate and match() decides at apply time, as it already does for pseudo classes.

The pruning is not salvageable: this.attribute in node is false only when the attribute is neither a prototype accessor nor an own value, which is exactly the ad-hoc, non-notifying attribute that can silently start matching later. It was only ever active in the case where it is wrong.

2. A value is recorded as applied only while the style still carries it. _isCssValueStillApplied reads the property's sourceKey — collected per CssProperty at registration — so the cascade writes the value again on the next update instead of skipping it. Values nothing disturbed are still skipped.

3. That check is gated on a local-write counter, so it costs nothing on the hot path. A local write is the only thing that can drop a value the cascade applied, so Style counts them and CssState records the count it applied against; the check runs only when the two differ, which for a view nothing writes to locally is never.

Performance

The css-state benchmarks, run on node 24 under --max-opt=0 — interpreter only, which is how iOS executes — against 9228826b4, the commit before #11361. Higher is better:

So #11361's win survives the fixes: every figure lands within noise of what that PR measured, and no path ends up slower than it was before it — the attribute-scoped one included, despite mayMatch no longer pruning.

Against main the two fixes cost very little, but only because the check is gated. Ungated it took back a third of the re-apply win:

Restoring mayMatch is what the attribute-scoped paths pay for (about 20% against main under the same conditions, nothing measurable with the optimizing compilers on). That is the price of those rules applying at all, and as the first table shows it still leaves them ahead of where they started.

This PR also adds VITEST_NO_OPT=1, which runs the vitest worker with --max-opt=0. That is what --jitless does to javascript without also disabling the WebAssembly vite needs; plain --no-opt only drops turbofan and measures almost nothing on current node.

Tests

css-attribute-match.spec.ts and css-state-recovery.spec.ts, 12 tests — 10 of them fail without these changes. They cover the attribute landing on the view, on an ancestor, and arriving before a dynamic update; and the local-value release for a longhand, for both shorthand and longhand margin/padding, for a local value set before css ran, for applyInlineStyle, and across a full re-match. One test pins that idle updates still write nothing, inherited values and shorthand-unset longhands included.

css-selector.spec.ts keeps its assertion that a node without the attribute is not styled, now against match() rather than the removed candidate pruning.

455 core unit tests pass and nx run core:build is clean.