| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Prevents the panel from going outside the viewport by adjusting the position. If developers want more control over how the panel gets repositioned, they can specify addition fallback positions via `addPanelPosition`. Related to angular#9641. Fixes angular#7878.
Prevents the panel from going outside the viewport by adjusting the position. If developers want more control over how the panel gets repositioned, they can specify addition fallback positions via `addPanelPosition`. Related to angular#9641. Fixes angular#7878.
Prevents the panel from going outside the viewport by adjusting the position. If developers want more control over how the panel gets repositioned, they can specify addition fallback positions via `addPanelPosition`. Related to angular#9641. Fixes angular#7878.
Prevents the panel from going outside the viewport by adjusting the position. If developers want more control over how the panel gets repositioned, they can specify addition fallback positions via `addPanelPosition`. Related to angular#9641. Fixes angular#7878.
| if (this._panelRef) { | ||
| // Bind the keydown handler to the body, in order to handle cases where the focused | ||
| // element gets removed from the DOM and stops propagating key events. | ||
| angular.element(document.body).on('keydown', boundKeyHandler); |
There was a problem hiding this comment.
This is my first time looking at the date picker code. Can you explain what edge case this helps to prevent? Do other components care about this or have similar functionality?
Sorry, something went wrong.
There was a problem hiding this comment.
The calendar currently focuses the active date's cell (I believe for accessibility reasons), which causes any keyboard events to be captured by the calendar. The issue is that the calendar uses mdVirtualRepeat which will remove the cell eventually, if you scroll long enough. This causes the browser to shift focus back to the body which stops the keyboard events from working.
Sorry, something went wrong.
|
|
||
| /** @type {boolean} Whether the date-picker's calendar pane is open. */ | ||
| /** @type {boolean} Whether the date-picker's calendar pane is open. Used internally. */ | ||
| this.isCalendarOpen = false; |
There was a problem hiding this comment.
Used internally, therefore should be marked private?
Sorry, something went wrong.
| this.isOpen = false; | ||
|
|
||
| /** @type {boolean} Used to prevent infinite loops when using mdOpenOnFocus. */ | ||
| this.preventInputFocus = false; |
There was a problem hiding this comment.
If you're using panels focusOnOpen, is this needed?
Sorry, something went wrong.
There was a problem hiding this comment.
Yes, this is also a private property. When the calendar closes, it restores focus to the element that triggered it to open. With mdOpenOnFocus that would cause the calendar to open up again since it refocuses the input. We use this flag to prevent such cases. It used to be possible to do this by delaying the close handler, but it got a little trickier with mdPanel since it's also async.
Sorry, something went wrong.
| clickOutsideToClose: true, | ||
| escapeToClose: true, | ||
| focusOnOpen: false, | ||
| scope: this.$scope.$new(), |
There was a problem hiding this comment.
I think this is the default, so you can remove it if you want. Being explicit is also fine though. Up to you.
Sorry, something went wrong.
There was a problem hiding this comment.
The default creates a scope that's a child of $rootScope, however we need it to be a child of the datepicker's scope.
Sorry, something went wrong.
| width: (elementRect.width - 1) + 'px', | ||
| height: (elementRect.height - 2) + 'px' | ||
| }); | ||
| var self = this; |
There was a problem hiding this comment.
So much code goes bye-bye. This is amazing!
Sorry, something went wrong.
| calendarPane.style.left = paneLeft + 'px'; | ||
| calendarPane.style.top = paneTop + 'px'; | ||
| document.body.appendChild(calendarPane); | ||
| // TODO(crisbeto): this should use getPanelYOffset once we ditch the units |
There was a problem hiding this comment.
Can this be done now?
Sorry, something went wrong.
There was a problem hiding this comment.
It's waiting on #9609 to be merged.
Sorry, something went wrong.
Prevents the panel from going outside the viewport by adjusting the position. If developers want more control over how the panel gets repositioned, they can specify addition fallback positions via `addPanelPosition`. Related to angular#9641. Fixes angular#7878.
| .addPanelPosition($mdPanel.xPosition.ALIGN_START, $mdPanel.yPosition.ALIGN_TOPS) | ||
| .withOffsetX(-this.leftMargin + 'px') | ||
| .withOffsetY(angular.bind(this, this.getPanelYOffset)); | ||
|
|
There was a problem hiding this comment.
The current version of the md-datepicker hides the popup when the window is re-sized. I noticed that the md-panel stays in the original position when the window is resized and using "relativeTo" (it stops being relativeTo the original element).
Can you confirm what the behavior is for the new implementation?
Sorry, something went wrong.
There was a problem hiding this comment.
It will still hide on resize (see https://github.com/angular/material/pull/9641/files#diff-31bf126782bc06608d149fe72237bf4eR702), although now it might be a little more practical to update the position instead. mdPanel has a convenient updatePosition method.
Sorry, something went wrong.
There was a problem hiding this comment.
Cool, I see it know... (window.addEventListener(this.windowEventName, this.windowEventHandler) ). Thank you.
Sorry, something went wrong.
Previously, if a panel had a position with an offset (e.g. `$mdPanel.newPanelPosition().center()`), the positioning would break any `transform` animations on the panel. This was due to the fact that `mdPanel` uses inline `transform` styles to do the offsetting. These changes introduce a wrapper around the panel (`.md-panel-inner-wrapper`), which will handle all of the positioning, allowing for any animations to be applied to the `.md-panel` itself. Relates to angular#9641. Fixes angular#9905.
Previously, if a panel had a position with an offset (e.g. `$mdPanel.newPanelPosition().center()`), the positioning would break any `transform` animations on the panel. This was due to the fact that `mdPanel` uses inline `transform` styles to do the offsetting. These changes introduce a wrapper around the panel (`.md-panel-inner-wrapper`), which will handle all of the positioning, allowing for any animations to be applied to the `.md-panel` itself. Relates to angular#9641. Fixes angular#9905.
Previously, if a panel had a position with an offset (e.g. `$mdPanel.newPanelPosition().center()`), the positioning would break any `transform` animations on the panel. This was due to the fact that `mdPanel` uses inline `transform` styles to do the offsetting. These changes introduce a wrapper around the panel (`.md-panel-inner-wrapper`), which will handle all of the positioning, allowing for any animations to be applied to the `.md-panel` itself. Relates to angular#9641. Fixes angular#9905.
Previously, if a panel had a position with an offset (e.g. `$mdPanel.newPanelPosition().center()`), the positioning would break any `transform` animations on the panel. This was due to the fact that `mdPanel` uses inline `transform` styles to do the offsetting. These changes introduce a wrapper around the panel (`.md-panel-inner-wrapper`), which will handle all of the positioning, allowing for any animations to be applied to the `.md-panel` itself. Relates to angular#9641. Fixes angular#9905.
Previously, if a panel had a position with an offset (e.g. `$mdPanel.newPanelPosition().center()`), the positioning would break any `transform` animations on the panel. This was due to the fact that `mdPanel` uses inline `transform` styles to do the offsetting. These changes introduce a wrapper around the panel (`.md-panel-inner-wrapper`), which will handle all of the positioning, allowing for any animations to be applied to the `.md-panel` itself. Relates to #9641. Fixes #9905.
Previously, if a panel had a position with an offset (e.g. `$mdPanel.newPanelPosition().center()`), the positioning would break any `transform` animations on the panel. This was due to the fact that `mdPanel` uses inline `transform` styles to do the offsetting. These changes introduce a wrapper around the panel (`.md-panel-inner-wrapper`), which will handle all of the positioning, allowing for any animations to be applied to the `.md-panel` itself. Relates to #9641. Fixes #9905.
Previously, if a panel had a position with an offset (e.g. `$mdPanel.newPanelPosition().center()`), the positioning would break any `transform` animations on the panel. This was due to the fact that `mdPanel` uses inline `transform` styles to do the offsetting. These changes introduce a wrapper around the panel (`.md-panel-inner-wrapper`), which will handle all of the positioning, allowing for any animations to be applied to the `.md-panel` itself. Relates to #9641. Fixes #9905.
Previously, if a panel had a position with an offset (e.g. `$mdPanel.newPanelPosition().center()`), the positioning would break any `transform` animations on the panel. This was due to the fact that `mdPanel` uses inline `transform` styles to do the offsetting. These changes introduce a wrapper around the panel (`.md-panel-inner-wrapper`), which will handle all of the positioning, allowing for any animations to be applied to the `.md-panel` itself. Relates to #9641. Fixes #9905.
| Back | FazBrowse Home | New Git URL |
Migrates the datepicker's positioning logic to mdPanel. All the functionality should work as before.
Fixes #9564.
Notes
This PR technically works and it is ready for code review, however in order to achieve feature parity with the current datepicker we need the following: