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 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
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
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
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
Fixes two issues that were preventing template literals from being recovered properly if one of the interpolated expressions is broken:
1. We weren't updating the expected brace counter when an interpolation starts which in turn was throwing off the recovery logic in `skip`.
2. When producing tokens for template literals, we were treating the closing brace as an operator whereas other places treat it as a character. Even after fixing the first issue, this was preventing the recovery logic from working correctly.
Fixes#63940.
PR Close#64150
The new animations was not correctly looking for the `.` when parsing bindings. This resulted in arbitrary event bindings creating animate.leave instruction calls.
fixes: #63466
PR Close#63470
Similar fix as #63082, but for template attributes. The root cause is the same where we should be using `fullStart` instead of `start` in order to account for whitespaces being skipped.
Fixes#63157.
PR Close#63175
When parsing expressions inside a bound attribute, we offset all of its spans by an `absoluteOffset` in order to get the right spans in the source file. The offset was incorrect when parsing an attribute with leading spaces during the construction of the Ivy AST, because of the combination of:
1. We were setting the offset by looking at `valueSpan.start`.
2. The Ivy parser sets `leadingTriviaChars: [' ', '\n']` which means that spaces and new lines will be ignored in the `sourceSpan.start`.
These changes resolve the issue by using `valueSpan.fullStart` which includes the leading spaces.
Fixes#63069.
PR Close#63082
Currently the HTML parser will stop parsing as soon as it hits an end character in the name of an attribute (e.g. `/` or `>`). This ends up being problematic with some third-party packages like Tailwind which uses a wider range of characters for its class names. While the characters are fine when inside the `class` attribute, our current parser behavior prevents users from setting those classes conditionally through `[class.]` bindings.
These changes adjust the parser to handle such cases.
Fixes#61671.
PR Close#62742
