-rw-r--r-- 1 iminar eng 14942 Oct 13 13:35 dist/0.b19e913fbdd6507d346b.chunk.js
-rw-r--r-- 1 iminar eng 1535 Oct 13 13:35 dist/inline.f005f1bd6803b72f5961.bundle.js
-rw-r--r-- 1 iminar eng 582527 Oct 13 13:35 dist/main.b9ef1abb785be8de15b8.bundle.js
-rw-r--r-- 1 iminar eng 37402 Oct 13 13:35 dist/polyfills.f8409a9eb69060ac1aa6.bundle.js
PR Close#19702
all the non-npm changes were made by the angular-material-prefix-updater tool.
the tool missed a few things, which I'll fix in a separate commit to preserve the diff.
-rw-r--r-- 1 iminar eng 14942 Oct 13 13:09 dist/0.b19e913fbdd6507d346b.chunk.js
-rw-r--r-- 1 iminar eng 1535 Oct 13 13:09 dist/inline.0592c25ceb544d6aca3d.bundle.js
-rw-r--r-- 1 iminar eng 578250 Oct 13 13:09 dist/main.45d4edca3facc6d621e7.bundle.js
-rw-r--r-- 1 iminar eng 37402 Oct 13 13:09 dist/polyfills.f8409a9eb69060ac1aa6.bundle.js
PR Close#19702
The GaService and the E2E specs were unnecessarily complicated and had
arbitrary async timeouts to ensure that the interplay between the GA
library code and the rest of the app worked correctly. This resulted
in potential flaky tests if the timeouts were not adequate; this was
experienced when Travis upgraded to Chrome 62.
The new approach is to block loading of the Analytics library altogether
if there is a `__e2e__` flag set in the `SessionStorage` of the browser.
It doesn't appear to be enough just to set the flag directly on the
window. I think this is because the window gets cleaned when navigation
occurs (but I am not certain).
The downside of this is that we had to add a small piece of extra logic
to the GA snippet in index.html; and we also had to switch from using
`<script async ...>` to a programmatic approach to loading the GA library
which prevents the browser from eagerly fetching the library. This may
be mitigated by adding it to the HTTP/2 push configuration of the Firebase
hosting.
Re-enables the test that was disabled in https://github.com/angular/angular/pull/19784Closes#19785
By adding a more relaxed search on the title
of docs, we are more likely to catch API docs.
The additional search terms match anything
with a word in the title that starts with the
characters of the first term in the search.
E.g. if the search is "ngCont guide" then
search for "ngCont guide titleWords:ngCont*"
The fixed test expected there to be a doc version without a URL. This used to be
the case but not any more. As a result, an error was logged in the test output
(but no failure).
This commit fixes it by ensuring that a version without a URL exists.
PR Close#18659
In our attempt to remove the material ripple effect from tab labels, we were
killing all `transform`-based animations on other `md-tab-group` elements, such
as animating the content when entering/leaving. (This wasn't an issue on Chrome,
because it didn't respect our `!important` flag.)
This commit fixes it by properly hiding the ripple effect (using a feature
introduced in angular/material2@e4789c7b8) and allowing other animations to
execute normally.
Fixes#17998
Now that we have upgraded to the latest lunr search engine, the results
from the standard `search` method are more appropriate.
So we do not need to create our own special queries to get good results.
Previouly, whenever a new ServiceWorker update was detected the user was
prompted to update (with a notification). This turned out to be more distracting
than helpful. Also, one would get notifications on all open browser tabs/windows
and had to manually reload each one in order for the whole content (including
the app) to be updated.
This commit changes the update strategy as follows:
- Whenever a new update is detected, it is immediately activated (and all
tabs/windows will be notified).
- Once an update is activated (regardless of whether the activation was
initiated by the current tab/window or not), a flag will be set to do a
"full page navigation" the next time the user navigates to a document.
Benefits:
- All tabs/windows are updated asap.
- The updates are applied authomatically, without the user's needing to do
anything.
- The updates are applied in a way that:
a. Ensures that the app and content versions are always compatible.
b. Does not distract the user from their usual workflow.
NOTE:
The "full page navigation" may cause a flash (while the page is loading from
scratch), but this is expected to be minimal, since at that point almost all
necessary resources are cached by and served from the ServiceWorker.
Fixes#17539
closes#17665
Restores keyboard focus that was removed by commit b8b91d3.
Raises the right-TOC by 20px (96px->76px) because was too far down.
To prevent keyboard focus on hidden child nodes,
also collapses inner expanded nodes when parent node is collapsed.
The implicit parent node of top nodes is always expanded.
The window title is derived based on the current document's `<h1>` heading. Such
headings may contain hidden/non-visible content (e.g. textual name of font
ligatures: `<i class="material-icons">link</i>`) that should not be included in
the title.
This commit fixes this by using `innerText` (instead of `textContent`) to
extract the visible text from the `<h1>` heading. It will still fall back to
`textContent` on browsers that do not support `innerText` (e.g. Firefox 44).
Fixes#17732
Before 4f37f8643, we were using `innerText` to retrieved the code content for
copying. This preserved the text layout (including newlines), but suffered from
other issues (browser support, performance). With 4f37f8643 we switched to
`textContent`, which works well except in the following case:
When `prettify` formats the code to have line numbers, it removes the newlines
and uses `<li>` elements instead. This affects `textContent`.
This commit fixes this by keeping a reference of the code as text and using that
for copying.
Fixes#17659
`innerText` is not supported in Firefox prior to v45. In most cases (at least
the ones we are interested in), `innerText` and `textContent` work equally well,
but `textContent` is more performant (as it doesn't require a reflow).
From [MDN][1] on the differences of `innerText` vs `textContent`:
> - [...]
> - `innerText` is aware of style and will not return the text of hidden
> elements, whereas `textContent` will.
> - As `innerText` is aware of CSS styling, it will trigger a reflow, whereas
> `textContent` will not.
> - [...]
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent#Differences_from_innerTextFixes#17585
Previously, we always assumed that elements would be scrolled to the top of the
page, when calling `element.scrollIntoView()`. This is not true for elements
that cannot be scrolled to the top, e.g. when the viewport height is larger than
the height of the content after the element (common for small sections near the
end of the page).
In such cases, we would unnecessarily scroll up to account for the static
toolbar, which was unnecessary (since the element was not behind the toolbar
anyway) and caused ScrollSpy to fail to identify the scrolled-to section as
active.
This commit fixes it by ensuring that we do not scroll more than necessary in
order to align the top of the element with the bottom of the toolbar.
Fixes#17452
* update to latest version of lunr search
* add trailing wildcard to search terms to increase matches
* fix unwanted error when escape was pressed
Closes#17417
* Remove the "info-banner" styling from the filters.
* Fix alignment of the search box on a narrow screen (closes#17395)
* Remove unnecessary whitespace before section headers
Peter Bacon Darwin
Igor Minar
Georgios Kalpakas
Ward Bell
Jules Kremer