This commit adds testcases in `URLS_TO_REDIRECT.txt` for all redirect
rules defined in `firebase.json`. This ensures that all rules are tested
and work as expected.
PR Close#42452
Previously, the `NotificationComponent` would be hidden by reducing its
height to `0`. This allowed for a smoother hide animation when closing
the notification, but left the component's interactive elements
focusable via keyboard navigation. This was confusing for users, because
the focused elements would not be visible on the page.
This commit fixes the issue be also setting the `display` CSS property
to `none` when the `NotificationComponent` is hidden, thus ensuring that
its contents are not focusable via keyboard navigation.
(This does not affect the hide animation, since the `display` style is
not animatable and is only applied at the end of the animation.)
PR Close#42584
Previously, we included a dummy `MatIcon` element in `AppComponent` in
order to ensure that the `Material Icons` font would be requested (and
thus cached by the ServiceWorker) on every navigation. However, #41129
introduced the `ThemeToggleComponent`, which will be present on all
pages (since it is located in the top-menu) and relies on the
`Material Icons` font. Therefore, the work-around for loading the
`Material Icons` font is no longer necessary.
This commit removes the now redundant `MatIcon` from `AppComponent`.
PR Close#42584
This commit changes the anchor elements used for external links to
`MatIconButton`s. While the appearance remains the same (with the
exception of hover/focus styles), this better aligns the styling of
external link icons with other nearby icon buttons (i.e. the theme
toggle) and alows as to simplify the CSS for external links (since much
of their styling is handled by Angular Material).
PR Close#42584
Since we now use SVG for external link icons, there are no `<img>`
elements inside the anchor elements. So, the CSS rule does not match any
element and can be removed.
PR Close#42584
Previously, we only tracked the sizes of the eagerly loaded JS bundles.
However, the CSS styles (which also have a non-negligible size) must
also be downloaded and parsed by the browser, thus affecting the initial
rendering time.
This commit starts tracking the CSS styles payload sizes.
(Originally discussed in
https://github.com/angular/angular/pull/42584#discussion_r653787961)
PR Close#42584
The addition of overloads to some of the number pipes caused
the documentation to lose the parameter descriptions.
This change fixes that by moving the JSDOC block in from of the
primary method signature, rather than the first overload.
Fixes#42590
PR Close#42593
This reverts commit 61ad68a586135a4d7b2b920fda0cb4238c6422fe, since there
are no longer any disambiguated paths that need special handling.
PR Close#42414
To avoid having content files that have the same file path on case-insensitive
file-systems, we now encode the paths to remove uppercase characters.
PR Close#42414
This is something I ran into while working on a fix for the `TestBed` module teardown behavior for #18831. In the `RouterInitializer.appInitializer` we have a callback to the `LOCATION_INITIALIZED` which has to do some DI lookups. The problem is that if the module is destroyed before the location promise resolves, the `Injector.get` calls will fail. This is unlikely to happen in a real app, but it'll show up in unit tests once the test module teardown behavior is fixed.
PR Close#42560
We currently have two long-standing issues related to how `TestBed` tests are torn down:
1. The dynamically-created test module isn't going to be destroyed, preventing the `ngOnDestroy` hooks on providers from running and keeping the component `style` nodes in the DOM.
2. The test root elements aren't going to be removed from the DOM. Instead, they will be removed whenever another test component is created.
By themselves, these issues are easy to resolve, but given how long they've been around, there are a lot of unit tests out there that depend on the broken behavior.
These changes address the issues by introducing APIs that allow users to opt into the correct test teardown behavior either at the application level via `TestBed.initTestEnvironment` or the test suite level via `TestBed.configureTestingModule`.
At the moment, the new teardown behavior is opt-in, but the idea is that we'll eventually make it opt-out before removing the configuration altogether.
Fixes#18831.
PR Close#42566
in order to have a consistent line-height between list items containing
text and list items containing links the anchors should inherit the list
item's line-height
PR Close#42572
make sure that the width of the sidenav chervon icon is 2.4rem
(this needs to be done using the flex property and not the
width one as that can change in flex containers)
also center chevron icon inside mat-icon container in order to maintain
the correct icon positioning at any font-size
PR Close#42561
Remove the fixed height set on the card elements present in angular.io,
allowing the cards to have a dynamic height derived from their content
and thus removing overflow issues related to the browser's font-size,
make other minor css related adjustments to allow the card to look good
on the different browser's font-size settings
PR Close#42533
This commit adds support for generating pages that document
special Angular elements, such as `ng-content` and `ng-template`,
which have special behavior in Angular but are not directives nor
components.
Resolves#41273
PR Close#41299
Removes the polyfills for `MutationObserver` and `setPrototypeOf` from our testing setup, because none of the browsers that we support require them. It also removes a bit of code and one external dependency.
PR Close#42567
Previously, the "go to definition" action did no account for the
possibility that something may actually be defined in a template. This
change updates the logic in the definition builder to convert any
results that are locations in template typecheck files to their
corresponding locations in the template.
PR Close#42559
Unclosed element tags are not assigned an `endSourceSpan` by the parser.
As a result, the visitor which determines the target node at a position
for the language service was unable to determine that a given position
was inside an unclosed parent. This happens because we update the
`endSourceSpan` of template/element nodes to be the end tag (and there
is not one for unclosed tags). Consequently, the visitor then cannot
match a position to any child node location.
This change updates the visitor logic to check if there are any
`children` of a template/element node and updates the end span to be the
end span of the last child. This allows our `isWithin` logic to identify
that a child position is within the unclosed parent.
Addresses one of the issues found during investigation of https://github.com/angular/vscode-ng-language-service/issues/1399
PR Close#42554
This commit updates the parser logic to continue to try to match an end
tag to an unclosed open tag on the stack. Previously, it would only
push an error to the list and stop looking at unclosed elements.
For example, the invalid HTML of `<li><div></li>`, has an unclosed
element stack of [`li`, `div`] when it encounters the close `li` tag.
We compare against the previously unclosed tag `div` and see that this is
unexpected. Instead of simply giving up here, we continue to move up the
unclosed tags until we find a match (if there is one).
PR Close#42554
Within Google, closure compiler is used for dealing with translations.
We generate a closure-compatible locale file that allows for
registration within Angular, so that Closure i18n works well together
with Angular applications. Closure compiler does not limit its
locales to BCP47-canonical locale identifiers. This commit updates
the generation logic so that we also support deprecated (but aliased)
locale identifiers, or other aliases which are likely used within
Closure. We use CLDR's alias supplemental data for this. It instructs
us to alias `iw` to `he` for example. `iw` is still supported in Closure.
Note that we do not manually extract all locales supported in Closure;
instead we only support the CLDR canonical locales (as done before) +
common aliases that CLDR provides data for. We are not aware of other
locale aliases within Closure that wouldn't be part of the CLDR aliases.
If there would be, then Angular/Closure would fail accordingly.
PR Close#42230
In the past, the closure file has been generated so that all individual
locale files were imported individually. This resulted in a huge
slow-down in g3 due to the large amount of imports.
With 90bd984ff7 this changed so that we
inline the locale data for the g3 closure locale file. Also the file
only contained data for locales being supported by Closure. For this a
list of locales has been extracted from Closure Compiler, as well as a
list of locale aliases.
This logic is prone to CLDR version updates, and also broke as part of
the Gulp -> Bazel migration where this logic has been slightly modified
but caused issues in G3. e.g. a locale `zh-Hant` was requested in g3,
but the locale data had the name of the alias locale that provided the
data at index zero (which represents the locale name). Note that the
locale names at index zero always could differentiate from the requested
`goog.LOCALE` due to the aliasing logic. This just didn't come up before.
We simplify this logic by generating a `goog.LOCALE` case for all
locales CLDR provides data for. We don't need to bother about aliasing
because with the refactorings to the CLDR generation tool, all locales
are built (which also captures the aliases), and we can generate the locale
file on the fly (which has not been done before).
PR Close#42230
The CLDR extraction tool has been reworked to run as part of Bazel.
This adds a initial readme explaining what the tool generates. It's
far from a detailed description but it can serve as foundation for more
detailed explanations.
PR Close#42230
Given that the locale files are now generated through
Bazel, the files are no longer checked-in and the
legacy TSC compilation fails due to imports resolving
to non-existent files. We fix this for the legacy
saucelabs job by copying the generated TS files into
the sources (which is acceptable for the isolated CI job)
PR Close#42230
Introduces a few Starlark macros for running the new Bazel
CLDR generation tool. Wires up the new tool so that locales
are generated properly. Also updates the existing
`closure-locale` file to match the new output generated by the Bazel tool.
This commit also re-adds a few locale files that aren't
generated by CLDR 37, but have been accidentally left in
the repository as the Gulp script never removed old locales
from previous CLDR versions. This problem is solved with the
Bazel generation of locale files, but for now we re-add these
old CLDR 33 locale files to not break developers relying on these
(even though the locale data indicies are incorrect; but there might
be users accessing the data directly)
PR Close#42230
Converts the CLDR locale extraction script to a Bazel tool.
This allows us to generate locale files within Bazel, so that
locales don't need to live as sources within the repo. Also
it allows us to get rid of the legacy Gulp tooling.
The migration of the Gulp script to a Bazel tool involved the
following things:
1. Basic conversion of the `extract.js` script to TypeScript.
This mostly was about adding explicit types. e.g. adding `locale:
string` or `localeData: CldrStatic`.
2. Split-up into separate files. Instead of keeping the large
`extract.js` file, the tool has been split into separate files.
The logic remains the same, just that code is more readable and
maintainable.
3. Introduction of a new `index.ts` file that is the entry-point
for the Bazel tool. Previously the Gulp tool just generated
all locale files, the default locale and base currency files
at once. The new entry-point accepts a mode to be passed as
first process argument. based on that argument, either locales
are generated into a specified directory, or the default locale,
base currencies or closure file is generated.
This allows us to generate files with a Bazel genrule where
we simply run the tool and specify the outputs. Note: It's
necessary to have multiple modes because files live in separate
locations. e.g. the default locale in `@angular/core`, but the
rest in `@angular/common`.
4. Removal of the `cldr-data-downloader` and custom CLDR resolution
logic. Within Bazel we cannot run a downloader using network.
We switch this to something more Bazel idiomatic with better
caching. For this a new repository rule is introduced that
downloads the CLDR JSON repository and extracts it. Within
that rule we determine the supported locales so that they
can be used to pre-declare outputs (for the locales) within
Bazel analysis phase. This allows us to add the generated locale
files to a `ts_library` (which we want to have for better testing,
and consistent JS transpilation).
Note that the removal of `cldr-data-downloader` also requires us to
add logic for detecting locales without data. The CLDR data
downloader overwrote the `availableLocales.json` file with a file
that only lists locales that CLDR provides data for. We use the
official `availableLocales` file CLDR provides, but filter out
locales for which no data is available. This is needed until we
update to CLDR 39 where data is available for all such locales
listed in `availableLocales.json`.
PR Close#42230
This is a pre-refactor commit allowing us to move
the CLDR locale generation to Bazel where files would
no longer be checked-in, except for the `closure-locale`
file that is synced into Google3.
PR Close#42230
When a FormControl, FormArray, or FormGroup is first constructed, if an async validator is attached, the `statusChanges` observable should receive a message when the validator complete (i.e. pending -> valid/invalid). If the validator was provided as part of the constructor options, it was not fired at construction time, which is fixed in this PR.
Fixes#35309.
PR Close#42553
Previously, due to a bug in Firebase hosting, requests to
`/index.html?<query>` would lead to an infinite redirect and eventually
a failure. This affected, for example, cache-busting requests from the
ServiceWorker, which look like: `/index.html?ngsw-cache-bust=...`
For more details see
https://github.com/angular/angular/issues/42518#issuecomment-858545483
This commit temporarily works around the bug by explicitly redirecting
`/index.html?<query>` to `/?<query>`.
Fixes#42518
PR Close#42547
This commit adds a popup to angular.io to inform the user about the use
of cookies. Once the user confirms having read the info, the popup will
not be shown on subsequent visits.
This commit is partly based on angular/material.angular.io#988.
Fixes#42209
PR Close#42259
Previously, we had the same logic in a couple of places to safely access
the `Window`'s `local-/sessionStorage` and provide a no-op fallback if
necessary. Soon, we will need the same logic for the cookies popup
(see #42209).
This commit reduces code duplication by providing
`local-/sessionStorage` as injectables and sharing the logic for
accessing them safely. This also makes it easier to mock the storage in
tests without having to mess with the actual `Window` object.
NOTE:
This commit actually decreases the payload size in the `main` bundle by
40B.
PR Close#42259
due to unknown `<mat-icon>` element
This commit fixes some warnings in the unit tests of the
`ThemeToggleComponent`, which were caused by the following:
- The `<mat-icon>` element used in `ToggleThemeComponent`'s template was
not declared in tests.
- The `dark-theme.css` and `light-theme.css` files requested by
`ToggleThemeComponent` were not available.
PR Close#42259
George Kalpakas
Pete Bacon Darwin
Kristiyan Kostadinov
Renovate Bot
Alex Rickabaugh
dario-piotrowicz
Marius Bethge
Daniel Trevino
Andrew Scott
Paul Gschwendtner
Ankit Choudhary
Dylan Hunn