The `thisArg` in pure functions isn't used so we can drop it. We still need to keep it on the underlying implementation, because pipe instructions rely on it.
This will replace the `[field]` directive, since `[field]` is a very
generic name for signal forms to commandeer
refactor(forms): hook up `formField` directive in compiler
Hooks up the `formField` direcive to get the same treatment as the
`field` directive in the compiler.
apply updated formatting
This commit updates the DOM security schema and sanitization logic to properly recognize and sanitize `href` and `xlink:href` attributes on SVG `<script>` elements.
We had `any` types for `LiteralArray.expressions`, `Chain.expressions`, `BindingPipe.args`, `LiteralPrimitive.value` and `LiteralMap.values`. These changes add proper types to them.
Back in #39323, I added a new `ThisReceiver` node to represent accesses done through `this` and I ended up making it inherit from `ImplicitReceiver`. The logic was that in most cases accessing through `this` was the same as the implicit access.
Over the years this has proven to not be a great idea, because no other AST nodes do this and one has to keep it in mind whenever dealing with `ImplicitReceiver`.
These changes remove the inheritance and update all of the usage sites accordingly.
This is necessary to exclude a race condition where the MutationObserver initialized by the instruction fired before the inputs are binded.
fixes#65678
This commit implements a security fix to prevent XSS vulnerabilities where SVG animation elements (`<animate>`, `<set>`, etc.) could be used to modify the `href` or `xlink:href` attributes of other elements to `javascript:` URLs.
Following https://github.com/angular/angular/pull/64509 we started
choking on unbalanced closing parentheses in declaration blocks,
specifically in quoted background-image urls. This was reported in
https://github.com/angular/angular/issues/65137.
This occured because we previously (and now again) traverse the entire
declaration block when selecting for :host-context() selectors to shim.
This is an oddity of how we parse styles today, and is likely something
we'd want to remove if we parsed selectors properly.
This change adds a new flag to _splitOnTopLevelCommas which allows it to
continue past unbalanced closing parentheses in the declaration block,
returning _convertColonHostContext to its previous behavior while
keeping support for the extra nesting in :host-context().
:nth-child() (and its siblings) support complex expressions, e.g.
`:nth-child(2n of :is(.foo, .bar))`. Previously we'd choke because of
the `:is()`. Now, we reuse the `_parenSuffix` subexpression to match
nested parentheses the same way we do for :host() and :host-context().
Note that we only support 3 levels of nesting, so a selector like
`:nth-child(n of :is(:has(:not(.foo))))` will still break.
I'll say yet again that we really should add a proper parser so we stop
getting bug reports like this :)
Fixes#64913
The `fullInheritane` flag from the metadata and the `CopyDefinitionFeature` that it controls appear to no longer be used since `fullInheritance` is always false. The feature appears to have been there to support ngcc which was removed some time ago.
I took a quick look at my recent changes to see if I had inadvertently
fixed this bug, but I couldn't seem to reproduce it even before my
changes. Seems like it's working, though.
Closes#58436
This change adds support for commas in :host() arguments (e.g.
`:host(:not(.foo, .bar))` as well as in nested parens when the argument
is applied without parens (e.g. `:host:not(:has(.foo, .bar))`).
Previously these selectors would receive an extra `[nghost]` attr, e.g.
`[nghost]:not(.foo, [nghost].bar)`.
I didn't file a bug for this one, but it's also blocking on an internal
LSC. Like the other CSS changes, I'll run a TGP to confirm this isn't
breaking.
Previously we supported one level of nested parentheses inside of a
`:host()` selector, e.g. `:host(:not(p))`. This caused a breakage in g3
when I migrated a selector from `:host:not(:has(p))` to
`:host(:not(:has(p)))`. This change adds support for just one more level
of nesting.
It'd be nice to move everything to a real CSS parser (or even update it
to count parentheses like I did with :host-context()), but I wasn't able
to get that to work in ~20 minutes and I'm focusing on other things at
the moment.
This change punts the problem until somebody tries to use just one more
level of nesting in a selector.
Fixes#64830
For each field state property, check if it has changed since the last
time it was checked before writing it the corresponding form control
property.
The `pattern` and `required` properties of the field state now return a
default value rather than `undefined` if not defined by metadata.
Previously we supported one level of nested pseudo-element selectors
inside :host-context(), e.g. :host-context(:is(.foo, .bar)). This was
based on a regex-based approach. We could support deeper levels of
nesting by updating the regex, but using a regex approach prohibits us
from supporting arbitrary nesting.
Rather than just adding one more level to the existing expression, I've
added a new generator function which splits selectors on commas in a
parenthesis-aware way. This allows us to support arbitrary nesting.
It's likely we'll want to reuse this in other places where we're not as
careful today. We'll probably do this on a request-based basis, though.
Fixes#59176
Renames the control directive and the input that users set to bind a
field to a UI control.
Previously users would do:
```
<input [control]="someField">
```
Now users will do:
```
<input [filed]="someField">
```
PR Close#64300
Currently we produce the string value of a defer `on` trigger by concatenating the string values of all of its tokens. This ends up ignoring whitespaces which in turn throws off source spans.
These changes switch to producing the string by taking the text between the start and end tokens, as well as tracking the start index.
PR Close#64130
I've updated the test to assert what I believe it was trying to assert
before. Without this change, the CSS is invalid so it's unclear what
behavior we're demonstrating.
PR Close#64036
Move most of the implementation of the `Control` directive into core
framework instructions. This allows field state changes to be propagated
to their corresponding UI controls directly during execution of a
template update block, instead of relying on `effect()`s to synchronize
each change later during the update (and too late in the case of
required inputs).
* Define a private API in `@angular/core` for signal forms to implement:
* `ɵControl` for the `Control` directive.
* `ɵFieldState` for the control's associated `FieldState`.
* Emit specialized instructions when compiling a `[control]` binding:
* `ɵɵcontrolCreate` sets up the `ɵControl` directive if present,
determines whether it's bound to a native control element or a
custom control component, and adds the appropriate event listeners
to notify the `ɵFieldState` of UI changes.
* `ɵɵcontrol` propagates changes from `ɵFieldState` properties to their
corresponding UI control properties (in additional to binding the `control`
property itself).
PR Close#63773
