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
This version fixes the DISCONNECTED errors (described in #17543) and removes the
need to the workaround (8af203c).
The relevant jasmine commit is jasmine/jasmine@c60d66994.
`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
The footer background (implemented via `footer:after`) had a higher `z-index`
than other footer elements and was obscuring the footer links on certain
browsers (Firefox, Edge, IE), which made them unclickable.
This commit lowers the index of `footer:after`, so that links are clickable on
these browsers.
Fixes#17460
You can now specify what environment you are building
by add it to the `yarn build` command. For example:
```
yarn build -- --env=stage
```
Moreover the `deploy-to-firebase.sh` script will automatically apply the
appropriate environment.
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
Using `<a>` inside a `<button>` is not syntactically valid HTML and breaks on
some browsers (e.g. Firefox). Furthermore, clicking the button doesn't do
anything unless you click on the link (e.g. clicking on the padding around the
link does nothing), which is inconvenient and confusing.
Fixes#17448
* 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
Chrome (v58+) often gets disconnected during unit tests (causing them to fail).
This has been happening locally (on Windows) and on Travis. The exact reasons
are not known, but it seems that some of the `AppComponent` tests are to blame.
Based on the discussion in https://github.com/jasmine/jasmine/issues/1327 (and
plenty of trial-and-error), using Jasmine's `done()` callback before each of
test (even calling it synchronously) fixes the issue.
Closes#17245 and #17253
When the user selects a doc item in the side nav:
1) expand folder(s) leading to the selected doc item
2) on a wide display, keep other already expanded folders open
3) on narrow (mobile) display, collapse other expanded folders
Used to do (3) when wide. Issue #17245 asks for (2).
That logic was bypassed for selected node when we allowed headers to have content
because that unintentionally expanded the header’s folder when selected.
Because the selected node is no longer a header with content, removing this exclusion
also means that folders are expanded/collapsed with above logic even for API pages.
