Router/common: Refactors and fixes the BrowserViewportScroller's scrolling behavior #40241
Conversation
The `BrowserViewportScroller` injects but does not use the `ErrorHandler`. This commit removes the `ErrorHandler` from the constructor.
The current tests in the router scroller are [change-detector tests](https://testing.googleblog.com/2015/01/testing-on-toilet-change-detector-tests.html) and do not ensure the correct behavior of the scroller. This commit updates the tests to assert actual scrolling behavior of the browser.
atscott
force-pushed
the
routerscroller
branch
2 times, most recently
from
be21305
to
bf363b4
atscott
changed the title
petebacondarwin
reviewed
Dec 28, 2020
According to the [spec](https://html.spec.whatwg.org/#scroll-to-fragid), we should attempt to set the browser focus after scrolling to a fragment. Note that this change does not exactly follow the robust steps outlined in the spec by finding a fallback target if the original is not focusable. Instead, we simply attempt to focus the element by calling `focus` on it, which will do nothing if the element is not focusable. fixes angular#30067
alfaproject
reviewed
Dec 28, 2020
petebacondarwin
approved these changes
Dec 29, 2020
josephperrott
added a commit
that referenced
this issue
Jan 5, 2021
The current tests in the router scroller are [change-detector tests](https://testing.googleblog.com/2015/01/testing-on-toilet-change-detector-tests.html) and do not ensure the correct behavior of the scroller. This commit updates the tests to assert actual scrolling behavior of the browser. PR Close #40241
josephperrott
added a commit
that referenced
this issue
Jan 5, 2021
According to the [spec](https://html.spec.whatwg.org/#scroll-to-fragid), we should attempt to set the browser focus after scrolling to a fragment. Note that this change does not exactly follow the robust steps outlined in the spec by finding a fallback target if the original is not focusable. Instead, we simply attempt to focus the element by calling `focus` on it, which will do nothing if the element is not focusable. fixes #30067 PR Close #40241
josephperrott
added a commit
that referenced
this issue
Jan 5, 2021
The current tests in the router scroller are [change-detector tests](https://testing.googleblog.com/2015/01/testing-on-toilet-change-detector-tests.html) and do not ensure the correct behavior of the scroller. This commit updates the tests to assert actual scrolling behavior of the browser. PR Close #40241
josephperrott
added a commit
that referenced
this issue
Jan 5, 2021
According to the [spec](https://html.spec.whatwg.org/#scroll-to-fragid), we should attempt to set the browser focus after scrolling to a fragment. Note that this change does not exactly follow the robust steps outlined in the spec by finding a fallback target if the original is not focusable. Instead, we simply attempt to focus the element by calling `focus` on it, which will do nothing if the element is not focusable. fixes #30067 PR Close #40241
twerske
added a commit
to twerske/angular
that referenced
this issue
Jan 5, 2021
…angular#40241) The `BrowserViewportScroller` injects but does not use the `ErrorHandler`. This commit removes the `ErrorHandler` from the constructor. PR Close angular#40241
twerske
added a commit
to twerske/angular
that referenced
this issue
Jan 5, 2021
The current tests in the router scroller are [change-detector tests](https://testing.googleblog.com/2015/01/testing-on-toilet-change-detector-tests.html) and do not ensure the correct behavior of the scroller. This commit updates the tests to assert actual scrolling behavior of the browser. PR Close angular#40241
twerske
added a commit
to twerske/angular
that referenced
this issue
Jan 5, 2021
According to the [spec](https://html.spec.whatwg.org/#scroll-to-fragid), we should attempt to set the browser focus after scrolling to a fragment. Note that this change does not exactly follow the robust steps outlined in the spec by finding a fallback target if the original is not focusable. Instead, we simply attempt to focus the element by calling `focus` on it, which will do nothing if the element is not focusable. fixes angular#30067 PR Close angular#40241
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Refactors and fixes the
BrowserViewportScroller's scrolling behavior.Commit 1:
The
BrowserViewportScrollerinjects but does not use theErrorHandler.This commit removes the
ErrorHandlerfrom the constructor.Commit 2:
The current tests in the router scroller are
change-detector tests
and do not ensure the correct behavior of the scroller.
This commit updates the tests to assert actual scrolling behavior of the
browser.
Commit 3:
According to the spec,
we should attempt to set the browser focus after scrolling to a
fragment. Note that this change does not exactly follow the robust steps
outlined in the spec by finding a fallback target if the original is not
focusable. Instead, we simply attempt to focus the element by calling
focuson it, which will do nothing if the element is not focusable.fixes #30067
The text was updated successfully, but these errors were encountered: