In our application, there is a very complicated logic that creates a bunch of form fields based on some data. It's very complicated, we hate that logic; but it exists, it works, and it is being used in production.
Somewhere in that logic, under a very specific case, a datepicker form field is created, connected, and then immediately disconnected. Don't ask me why, I said it is complicated.
This commit fixes a bug in OverlayMixin. The `connectedCallback` calls `_setupOverlayCtrl()` asynchronously, after a `Promise.then()`. Thus, by the time this setup function is called, the component has already been disconnected (and `disconnectedCallback()` has already been called).
The fix is simple: don't try to setup the overlay if the component is no longer connected.
* fix(overlays): fix memory leaks of adopt-styles and OverlayMixin
* fix(overlays): support reconnecting the OverlayController to the OverlayManager
* chore: move unregister logic to OverlayController
---------
Co-authored-by: Thijs Louisse <Thijs.Louisse@ing.com>
* fix(overlays): skip local-positioning tests for Firefox, and added a todo to fix later
* Update packages/ui/components/overlays/test/local-positioning.test.js
Co-authored-by: Thijs Louisse <thijs.louisse@ing.com>
* feat(core): add Firefox to browserDetection
---------
Co-authored-by: Thijs Louisse <thijs.louisse@ing.com>
* fix(overlay-controller): do not scroll to invoker if it is visible on screen
When closing an overlay, srollIntoView forced the invoker element to be placed in the middle of the screen. This fix prevents the scroll if the invoker is already visible, but still scrolls it into view if needed.
* chore: changeset
* fix: possible fix for iOS focus issue WIP
* chore: added test for elementToFocusAfterHide WIP
* chore: dialog tests for elementToFocusAFterHide
* chore: added test to assert element specified in `elementToFocusAfterHide` config key of lion-dialog is scrolled into the viewport
* chore: - added test to assert that element specified in dialog config key `elementToFocusAfterHide` is not focused when the dialog is closed if the user deliberately moved focus to another element while the dialog was open
- added changeset
* chore: - removed unneeded button
- renamed this.__activeElement to this.__activeElementRightBeforeHide in OverlayController.js
- set this.__activeElementRightBeforeHide to this.contentNode.getRootNode().activeElement instead of document.activeElement
* chore: moved test to assert if element specified in dialog config key elementToFocusAfterHide is in viewport when dialog is closed to OverlayController.test.js
---------
Co-authored-by: Thijs Louisse <Thijs.Louisse@ing.com>
