bug(sidenav): margins are reversed when contained in a dialog #11262
Assignees
Labels
P3
An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
Comments
mmalerba
added
the
P3
|
The workaround for this is to explicitly set |
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
May 11, 2018
…n is set * Currently the dialog and bottom sheet always provide the `Directionality` in order to allow for any components placed inside of them to pick up their direction. This is problematic if the consumer didn't set a direction, because the `value` of the provided `Directionality` will be set to `undefined`. These changes switch to only providing the direction if it is defined in the config, otherwise the components will fall back to the global `Directionality`. * Flips around some logic in the drawer so an undefined direction is consider `ltr`, rather than `rtl`. Fixes angular#11262.
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
May 12, 2018
…n is set * Currently the dialog and bottom sheet always provide the `Directionality` in order to allow for any components placed inside of them to pick up their direction. This is problematic if the consumer didn't set a direction, because the `value` of the provided `Directionality` will be set to `undefined`. These changes switch to only providing the direction if it is defined in the config, otherwise the components will fall back to the global `Directionality`. * Flips around some logic in the drawer so an undefined direction is consider `ltr`, rather than `rtl`. Fixes angular#11262.
tinayuangao
pushed a commit
that referenced
this issue
May 15, 2018
…n is set (#11285) * Currently the dialog and bottom sheet always provide the `Directionality` in order to allow for any components placed inside of them to pick up their direction. This is problematic if the consumer didn't set a direction, because the `value` of the provided `Directionality` will be set to `undefined`. These changes switch to only providing the direction if it is defined in the config, otherwise the components will fall back to the global `Directionality`. * Flips around some logic in the drawer so an undefined direction is consider `ltr`, rather than `rtl`. Fixes #11262.
tinayuangao
pushed a commit
that referenced
this issue
May 15, 2018
…n is set (#11285) * Currently the dialog and bottom sheet always provide the `Directionality` in order to allow for any components placed inside of them to pick up their direction. This is problematic if the consumer didn't set a direction, because the `value` of the provided `Directionality` will be set to `undefined`. These changes switch to only providing the direction if it is defined in the config, otherwise the components will fall back to the global `Directionality`. * Flips around some logic in the drawer so an undefined direction is consider `ltr`, rather than `rtl`. Fixes #11262.
|
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.
Bug, feature request, or proposal:
Bug
What is the expected behavior?
Margins for left and right sidenavs should be applied correctly
What is the current behavior?
The left sidenav applies margin-right to mat-sidenav-content instead of margin-left, and the same for the right sidenav. This is also the same behavior if only one sidenav is used. Also note, for probably obvious reasons, this only occurs in side or push mode.
What are the steps to reproduce?
Providing a StackBlitz reproduction is the best way to share your issue.
https://stackblitz.com/edit/angular-7kuc9x?file=app/sidenav-position-example.ts
What is the use-case or motivation for changing an existing behavior?
Sidenavs should present correctly in any situation.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Angular v6, Material and CDK v6, Max OS X, TS 2.7, Chrome
Is there anything else we should know?
At some point in the past, this was working.
The text was updated successfully, but these errors were encountered: