Repository navigation
Conversation
|
Thanks for the PR! 🎉 We've deployed an automatic preview for this PR - you can see your changes here:
Note The build needs to finish before your changes are deployed. |
| } | ||
|
|
||
| this.position(e.detail, { updateLocation: this.#initializingHeight }); | ||
| this.position(undefined, { updateLocation: this.#initializingHeight }); |
There was a problem hiding this comment.
The handler was using the menu content rect to calculate positioning. This changes it so it uses the whole filter dropdown instead.
There was a problem hiding this comment.
I see. I think the original assumption, before filter and a header was introduced, was that d2l-dropdown-menu size === d2l-menu size. This e.detail was meant to be an optimization so that the positioning logic would not have to measure it.
| this._closeRadio = false; | ||
|
|
||
| const menu = this.#getMenuElement(); | ||
| menu.resize(); |
There was a problem hiding this comment.
Curious why this is no longer needed... ?
| * Whether the dropdown opens above the opener | ||
| * @type {boolean} | ||
| */ | ||
| openAbove: { type: Boolean, attribute: 'open-above' }, |
There was a problem hiding this comment.
This is meant to give consumers the ability to force it to open upwards, even if there's enough space below? Is this needed to address the issue - given the fix to the calculation, wouldn't the dropdown now open upwards if there isn't enough space below?
There was a problem hiding this comment.
Yeah I'm hesitant to force open-above, since there could be cases where there's less space above than below.
GAUD-10527