Issue number: Internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
As part of FW-2832, the team would like to swap out usages of the any
type for stronger types.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
c529bc23f1
- `scrollToTop` doesn't return anything, so I added the `void` return
type
a96971ad28
- `animation.effect` is a type of
[AnimationEffect](https://developer.mozilla.org/en-US/docs/Web/API/Animation/effect).
One of the more common types of effects is a `KeyframeEffect`. However,
TypeScript doesn't know which specific type of AnimationEffect we are
using, so I cast `animation.effect` as KeyframeEffect where appropriate.
- I also added `!` to places where we know the effect and other
properties are always defined (since they run after the web animation
has been constructed)
- Added stronger types to the internal to/from/fromTo functions (the
public facing type improvements are in
https://github.com/ionic-team/ionic-framework/pull/28334)
fdaf550059
- `getRootNode` can return multiple types of objects, so I cast it to
the specific types that we work with in `isFocused`.
46a6efa510
- Added the "Animation" type and resolved related errors once we had
stronger types
a7cb9a5685
- Made heavier use of the `T` generic
- Once we know `node` is an Element (`nodeType === 1`) we manually cast
the element as `T`
6a9d1f095d
- The focus visible utility is an internal utility, but it was lacking
an interface, so I added one.
90b64c2de5
- Removed unneeded HTMLElement casting
- Added `!` since we can assume the selected elements are defined with
the refresher
- Added documentation as to why casting `referencEl.style` as `any` is
something we need to keep.
3a084caf83
- Avoided the Event naming collision by using globalThis
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Note: This PR contains only type changes. Changes the required updates
to the implementation of Ionic are pulled out into separate PRs and
target a minor release branch to minimize risk.
---------
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
This project has several unused Sass variables still in the code base.
The team would like to remove these.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed unused Sass variables
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
The original scope of this ticket was for checkbox only, but many other
components had unused sass variables, so I decided to tackle everything
all at once.
Since these variables are not used anywhere:
1. The build should pass
2. There should be no screenshot diffs
Issue number: resolves#18683, resolves#15538, resolves#22341
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Menus in a split pane are hidden when a second split pane is
mounted/made visible. This is because the `onSplitPaneChanged` callback
does not take into account whether the it is a child of the split pane
that emitted `ionSplitPaneVisible`.
When split pane 2 is shown, that causes the menu is split pane 1 to
hide. When split pane 1 is shown, the menu inside of it _is_ shown.
However, since split pane 2 is then hidden that component also emits
`ionSplitPaneVisible`, causing the menu inside of split pane 1 to hide.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Menus are only hidden when its parent split pane changes visibility
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.5.1-dev.11697568647.1ac87d08`
---------
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
Issue number: resolves#28337
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Duplicate instances of `menuController` are being created in
`@ionic/angular`. `ion-menu` registers itself in the `menuController`
from `@ionic/core`, but the `MenuController` from `@ionic/angular` uses
the `menuController` from `@ionic/core/components`. This is how the
overlay providers work too. Normally, this is not a problem. However,
`menuController` caches references to registered menus in each
controller instances:
dcbf45101f/core/src/utils/menu-controller/index.ts (L14)
This means that since there are two different controllers,
`menuController` B does not know about the menus in `menuController` A.
The end result is that the menu controller used in developer
applications did not have references to the registered menus, which gave
the impression that the menu controller did not work.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updated the architecture of `MenuController` in Ionic Angular to
accept a `menuController` instance. This allows `@ionic/angular` to pass
the `menuController` from `@ionic/core` and for
`@ionic/angular/standalone` to pass the `menuController` from
`@ionic/core/components`.
Note: Overlay controllers don't **need** this change per-se since they
don't cache references to overlays internally (they just query the DOM).
However, I think it would be good to have a consistent architecture
here, so I'll put up a separate PR that makes this change for overlays
too.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
Dev build: `7.5.1-dev.11697123035.1ee6b4a2`
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: resolves#18974
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
When multiple menus on the same `side` are registered, all but the most
recent menu are disabled. For example, if a user starts on PageA with a
`start` menu and then navigates to PageB which also has a `start` menu,
then the menu on PageA will be disabled. The problem is that if users
navigates back to PageA they will be unable to open the menu on that
view because it is still disabled. This behavior impacts any Ionic
developer trying to open a menu whether by calling the `open` method on
the menu itself or on the `menuController`.
After discussing with the team, we believe the original intent of this
behavior was to prevent users from accidentally opening the wrong menu
when calling `menuController.open('start')`. This API allows developers
to reference a menu by side, and since it's possible to have multiple
menus on the same side it's also possible to open the wrong menu when
referencing by side only.
However, this API starts to break down pretty quickly in a navigation
scenario.
Sample Repo: https://github.com/liamdebeasi/multiple-menu-bug-repro
## Scenario 1: Referencing Menu by Side
1. On the "home" route click "Open 'start' menu". Observe that the home
page menu opens.
2. Close the menu and click "Go to Page Two".
3. On the "page-two" route click "Open 'start' menu". Observe that the
page two menu opens.
4. Go back to "home".
5. Click "Open 'start' menu". Observe that nothing happens.
6. Click "Enable and Open 'start'" Menu". Observe that the home menu
opens.
## Scenario 2: Referencing Menu by ID
1. On the "home" route click "Open '#menu1' menu". Observe that the home
page menu opens.
2. Close the menu and click "Go to Page Two".
3. On the "page-two" route click "Open '#menu2' menu". Observe that the
page two menu opens.
4. Go back to "home".
5. Click "Open '#menu1' menu". Observe that nothing happens.
6. Click "Enable and Open '#menu1'" Menu". Observe that the home menu
opens.
## Scenario 3: Using 3 or more menus even when enabling menus
1. On the "home" route click "Open 'start' menu". Observe that the home
page menu opens.
2. Close the menu and click "Go to Page Two".
3. On the "page-two" route click "Open 'start' menu". Observe that the
page two menu opens.
4. Close the menu and click "Go to Page Three"
5. On the "page-three" route click "Open 'start' menu". Observe that the
page three menu opens.
6. Go back to "page-two".
8. Click "Open 'start' menu". Observe that nothing happens.
9. Click "Enable and Open 'start' Menu". Observe that nothing happens.
The menu controller attempts to find an enabled menu on the specified
side:
a04a11be35/core/src/utils/menu-controller/index.ts (L79C12-L79C12)
Step 6 is where this breaks down. In this scenario, the menus on "home"
and "page-two" are disabled. This leads menu controller to use its
fallback which tries to get the first menu registered on the specified
side:
a04a11be35/core/src/utils/menu-controller/index.ts (L86)
This means that the menu controller would attempt to open the "home"
menu even though the user is on "page-two" (because the start menu on
"home" was the first to be registered).
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Menus are no longer automatically disabled when a new menu on the same
side is registered
- Referencing menus by side when multiple menus with that side exist in
the DOM will cause a warning to be logged
This change has a couple implications:
1. Developers no longer need to manually enable a menu as noted in
https://ionicframework.com/docs/api/menu#multiple-menus. Note that
continuing to manually enable the menus will not cause any adverse side
effects and will effectively be a no-op.
2. Developers using the menuController to open a menu based on "side"
may end up having the wrong menu get opened.
Example before to this change:
1. Start on PageA with a `start` menu. Calling
`menuController.open('start')` opens the menu on PageA.
2. Go to PageB with a `start` menu. Calling
`menuController.open('start')` opens the menu on PageB because the menu
on PageA is disabled.
Example after to this change:
1. Start on PageA with a `start` menu. Calling
`menuController.open('start')` opens the menu on PageA.
2. Go to PageB with a `start` menu. Calling
`menuController.open('start')` attempts to opens the menu on PageA
because both menus are enabled. However, since PageA is hidden nothing
will appear to happen.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
I manually verified that removing the Angular Universal code does not
regress the behavior fixed in
https://github.com/ionic-team/ionic-framework/pull/27814. The menu is
never automatically disabled, so the bug does not happen.
This is a partial fix for
https://github.com/ionic-team/ionic-framework/issues/18683. Properly
fixing this requires another change which is out of scope for this work.
Issue number: resolves#20092, resolves#19676, resolves#19000
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Menu is currently throwing errors because it expects no animations to be
running when any state changes happen (such as changing `disabled` or
`swipeGesture`).
For example, if you set `swipeGesture="false"` mid-gesture then the menu
will error. Alternatively, if you set `disabled="true"` mid-open
animation then the menu will error also. This is undesirable because it
can cause visual flickering and other undesirable behaviors as noted in
the linked threads.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Any in-progress animation is cancelled if the state updates such that
the animation is no longer relevant (i.e. `disabled` is set to `true`
while the menu is opening)
- Removed relevant assertions
- Added tests
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.4.3-dev.11696264821.1755dd6a`
Issue number: resolves#28180
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
When presenting an overlay, we remove the root (usually
`ion-router-outlet`) from the accessibility tree. This makes it so you
cannot accidentally focus elements behind the overlay. When dismissing
an overlay we re-add the root to the accessibility tree. However, we
fail to consider if there are multiple presented overlays. For example,
if you present a modal, then an alert, then dismiss the alert, then the
root is re-added to the accessibility tree even though the modal is
still presented.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The root is now re-added to the accessibility tree only if it is the
last presented overlay.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.4.1-dev.11694783260.13da477f`
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
- There are no tests for menu when safe area is applied.
- The safe area variables on menu weren't being reset properly to allow
easy local customization.
Currently, some of the variables are being set to `env()`. This is the
same structure that is being used in core. However, this doesn't
prevents users from mocking the safe area when using
`--ion-safe-area-left: 50px` on `html`. It makes it hard to create tests
to validate that padding is being applied to the safe area.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Tests have been added.
- The safe area variables on menu are now being reset to use the values
from `:root`.
The variables are being `unset` in order for the variables to [default
to parent styles](https://stackoverflow.com/a/69491310/5374225). Since
core styles has already declared the variables, then developers can use
`--ion-safe-area-left: 50px` on `html`.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
N/A
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The `--ion-safe-area-left` and `--ion-safe-area-right` variables in
`ion-menu` are being set as if they use the app's direction. It's been
determined that safe area is not logical and uses the device's
direction. The current implementation is adding padding in the wrong
sides for `ion-toolbar` and `ion-content` within a `ion-menu`.
Additionally, `ion-menu` does not use the entire screen so the safe area
only needs to be applied to the side that is touching the device screen.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Set the `--ion-safe-area-left` and `--ion-safe-area-right` variables
to the correct values based on the device's direction.
- Padding is only added to the side that is not in the safe area.
- `ion-toolbar` is adding `--ion-safe-area-left` and
`--ion-safe-area-right` based on the device's direction.
- `ion-toolbar` can now inherit the correct values from
`--ion-safe-area-left` and `--ion-safe-area-right`.
- `ion-content` can now inherit the correct values from
`--ion-safe-area-left` and `--ion-safe-area-right`.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: 7.3.4-dev.11694015543.18bc484f
Issue number: resolves#28030
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
`ion-menu` registers itself with the menu controller when
`connectedCallback` fires and then unregisters itself when
`disconnectedCallback` fires. When the menu was removed from the DOM,
`disconnectedCallback` was not always being fired due to
https://github.com/ionic-team/stencil/issues/4070.
`ion-menu-button` checks to see if it should be visible by grabbing the
current menu in
314055cf7a/core/src/components/menu-button/menu-button.tsx (L74).
Since `disconnectedCallback` was not being fired, `ion-menu-button`
would still find the menu even when it was no longer in the DOM. In this
case, the menu was not being unregistered due to `disconnectedCallback`
not firing.
When the linked Stencil bug was resolved in Stencil 4.0.3, the menu
button started to disappear. This is happening because
`disconnectedCallback` is now correctly called when the menu is removed
from the DOM. Since `disconnectedCallback` is called, the menu is
un-registered from the menu controller, and the menu button can no
longer find it.
However, this revealed a long-standing bug where re-adding the menu
would not fire `ionMenuChange` again. As a result, the menu button
remained hidden.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The menu now fires `ionMenuChange` on `connectedCallback` as long as
`componentDidLoad` has already been run.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.3.2-dev.11692803611.15c1bc87`
---------
Co-authored-by: Sean Perkins <sean@ionic.io>
Issue number: Resolves#27524#22206
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
After destructive hydration from an Angular Universal build, the
`ion-menu` is disabled. This results in a few problematic behaviors:
- If used with an `ion-split-pane`, the split pane will not render with
the menu.
- If used with an `ion-menu-button`, the menu icon will not render and
the menu will not be accessible.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removes automatically disabling the `ion-menu` when in a server
environment.
- Prevents setting an `ion-menu` that no longer exists in the DOM, as an
active menu. This allows the most recent menu to be enabled when
rendered from Angular Universal builds.
Loom recording overviewing the change:
https://www.loom.com/share/5a149218adc84cc2af435fc1b1f45124?sid=249028f4-be3d-4d4a-948a-597da83be95a
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev-build: `7.1.4-dev.11689625795.1d16532b`
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The `ion-header` and `ion-footer` use a base64 encoded image for a box
shadow instead of using the CSS box-shadow property directly. The use of
the background image creates CSP violations. The historic reasoning of
using an image instead of box shadow was to improve scroll performance.
Browsers and devices have improved a lot since that was implemented (5
years ago).
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updates the usage of `ion-header` and `ion-footer` to use a box
shadow. The value comes from Material's web implementation:
https://material-components.github.io/material-components-web-catalog/#/component/top-app-bar
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: N/A
---------
<!-- Please refer to our contributing documentation for any questions on
submitting a pull request, or let us know here if you need any help:
https://ionicframework.com/docs/building/contributing -->
<!-- Some docs updates need to be made in the `ionic-docs` repo, in a
separate PR. See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#modifying-documentation
for details. -->
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Menu sliding tests use legacy syntax
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Menu sliding tests use modern syntax
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
<!-- Please refer to our contributing documentation for any questions on
submitting a pull request, or let us know here if you need any help:
https://ionicframework.com/docs/building/contributing -->
<!-- Some docs updates need to be made in the `ionic-docs` repo, in a
separate PR. See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#modifying-documentation
for details. -->
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
This is the first PR to introduce the infrastructure required to add
test generators to the Ionic Framework project. This PR introduces the
file name changes necessary to support two playwright configs, so I
recommend reviewing the PR by commit:
1e5012cea1
- Created a `playwright.config-legacy.ts` file and updates
`package.json`.
- Running `npm run test.e2e` will run the generator tests, and running
`npm run test.e2e.legacy` will run the legacy tests.
4fe8de7df7
- Updates the GitHub Action scripts to run both the modern and legacy
E2E tests. I added command modifiers to avoid collisions with output
directories.
e8bcfaf926
- Updates `*.e2e.ts` files to have the legacy format name:
`*.e2e-legacy.ts`. This naming scheme is required for the two Playwright
configs to pull in the correct files. When migrating tests to
generators, team members will rename the file to remove the `-legacy`
part.
5bf196c36d
(warning: lots of files!)
- Updates the `*.e2e.ts-snapshots` directories to have the legacy format
name: `*.e2e-legacy.ts-snapshots`. The screenshot directory in
Playwright is generated based on the test file name which is why we are
updating the screenshot directory. When migrating tests to generators,
team members will rename the directory to remove the `-legacy` part.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
<!-- Please refer to our contributing documentation for any questions on
submitting a pull request, or let us know here if you need any help:
https://ionicframework.com/docs/building/contributing -->
<!-- Some docs updates need to be made in the `ionic-docs` repo, in a
separate PR. See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#modifying-documentation
for details. -->
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
`page.locator` is synchronous, but we were `await`ing the calls:
https://playwright.dev/docs/api/class-page#page-locator
We were also doing `page.locator(...).click()` when we can just do
`page.click([selector])` directly,
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removes `await` usage from `page.locator`
- Removes `page.locator().click()` usage in favor of `page.click()`
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
<!-- Please refer to our contributing documentation for any questions on
submitting a pull request, or let us know here if you need any help:
https://ionicframework.com/docs/building/contributing -->
<!-- Some docs updates need to be made in the `ionic-docs` repo, in a
separate PR. See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#modifying-documentation
for details. -->
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
<!-- Issues are required for both bug fixes and features. -->
Issue URL: resolves
https://github.com/ionic-team/ionic-framework/issues/24907
`ion-menu` currently clears the `menuInnerEl` and `backdropEl` refs
created by Stencil when `disconnectedCallback` is fired. If the
`ion-menu` component is re-mounted but _not_ re-rendered, those refs
will still be `undefined` when the `open` method is called, resulting in
the linked issue. Note that if the `ion-menu` re-renders before `open`
is called then this issue does not reproduce.
This clearing behavior was added ~6 years ago before we utilized Stencil
refs:
687b37ad3e/packages/core/src/components/menu/menu.tsx (L136-L137)
During this time we had to manually create and clear the element
references.
Several years later we moved to using Stencil refs, but we did not
remove the logic that clears the refs:
d83d8eed12
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Menu no longer sets `menuInnerEl` and `backdropEl` to `undefined` in
`disconnectedCallback`.
- The `close` method is called so that the state is reset prior to the
menu being re-added. I observed that without this, the animation to
re-present a menu did not work correctly.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
<!-- Please refer to our contributing documentation for any questions on
submitting a pull request, or let us know here if you need any help:
https://ionicframework.com/docs/building/contributing -->
<!-- Some docs updates need to be made in the `ionic-docs` repo, in a
separate PR. See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#modifying-documentation
for details. -->
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
<!-- Issues are required for both bug fixes and features. -->
Issue URL: N/A
Playwright recommends using Locators with web-first assertions instead
of using `waitForSelector`:
https://playwright.dev/docs/api/class-frame#frame-wait-for-selector
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removes waitForSelector usages for checking if components are visible
in favor of the `toBeVisible` or `toBeHidden` assertions.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
## Pull request checklist
Please check if your PR fulfills the following requirements:
- [x] Tests for the changes have been added (for bug fixes / features)
- [ ] Docs have been reviewed and added / updated if needed (for bug
fixes / features)
- Some docs updates need to be made in the `ionic-docs` repo, in a
separate PR. See the [contributing
guide](https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#modifying-documentation)
for details.
- [x] Build (`npm run build`) was run locally and any changes were
pushed
- [x] Lint (`npm run lint`) has passed locally and any fixes were made
for failures
## Pull request type
Please check the type of change your PR introduces:
- [x] Bugfix
- [ ] Feature
- [ ] Code style update (formatting, renaming)
- [ ] Refactoring (no functional changes, no api changes)
- [ ] Build related changes
- [ ] Documentation content changes
- [ ] Other (please describe):
## What is the current behavior?
- When the document direction is dynamically changed, the menu does not
switch to the correct position. For example, `<ion-menu side='start'>`
will always be on the left side regardless of direction.
- When the side property is dynamically changed, the animation starts in
the middle of the screen instead of off screen.
Issue URL: resolves#25601#19489
## What is the new behavior?
- Animation is smooth regardless of side property or document direction
being dynamically change.
- Menu appears on the correct side based on document direction when
dynamically updated.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
## Other information
N/A
---------
Co-authored-by: ionitron <hi@ionicframework.com>
The Ionic Framework team would like to re-evaluate our approach to improving customization options when building mobile applications. We are looking at other solutions that a) make customizing an app UI easier and b) are applicable to a broader set of developers.
