- Fix Internal issue (FW-5205) - Removed the build conditional in the
`item` component since the previous issue is already fixed in Stencil.
---------
<!-- 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. -->
- No changes were made in terms of behavior.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- No changes were made in terms of behavior so it will work as before.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
- Spec tests still pass even after this change (we can see below the
results before and after the change)
- Ran the command `npm run test.spec
src/components/item/test/item.spec.ts
src/components/item/test/item.spec.tsx`
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. -->
Ionic Framework has fallback detection for Capacitor 2 applications to
avoid applying status bar style changes to the card modal.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Ionic Framework's detection for applying status bar styles will be
based on the APIs available in Capacitor 3+.
- Ionic Framework will no longer support the legacy Capacitor 2
configurations.
## Does this introduce a breaking change?
- [x] Yes
- [ ] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
Developer should upgrade to the latest major release of Capacitor.
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
BREAKING CHANGE:
The `legacy` property and support for the legacy syntax, which involved placing an `ion-radio` inside of an `ion-item` with an `ion-label`, have been removed from radio. For more information on migrating from the legacy radio syntax, refer to the [Radio documentation](https://ionicframework.com/docs/api/radio#migrating-from-legacy-radio-syntax).
BREAKING CHANGE:
The `legacy` property and support for the legacy syntax, which involved placing an `ion-toggle` inside of an `ion-item` with an `ion-label`, have been removed from toggle. For more information on migrating from the legacy toggle syntax, refer to the [Toggle documentation](https://ionicframework.com/docs/api/toggle#migrating-from-legacy-toggle-syntax).
Issue number: internal
---------
## What is the current behavior?
In Ionic Framework v7, we [simplified the select
syntax](https://ionic.io/blog/ionic-7-is-here#simplified-form-control-syntax)
so that it was no longer required to be placed inside of an `ion-item`.
We maintained backwards compatibility by adding a `legacy` property
which allowed it to continue to be styled properly when written in the
following way:
```html
<ion-item>
<ion-label>Label</ion-label>
<ion-select></ion-select>
</ion-item>
```
While this was supported in v7, console warnings were logged to notify
developers that they needed to update this syntax for the best
accessibility experience.
## What is the new behavior?
- Removes the `legacy` property and support for the legacy syntax.
Developers should follow the [migration
guide](https://ionicframework.com/docs/api/select#migrating-from-legacy-select-syntax)
in the select documentation to update their apps. The new syntax
requires a `label` or `aria-label` on `ion-select`:
```html
<ion-item>
<ion-select label="Label"></ion-select>
</ion-item>
```
- Removes the legacy tests under under `select/test/legacy/` and all
related screenshots
- Removes the select usage from `item/test/disabled`,
`item/test/legacy/alignment`, and `item/test/legacy/disabled` and all
related screenshots if the test was removed
## Does this introduce a breaking change?
- [x] Yes
- [ ] No
1. Developers have had console warnings when using the legacy syntax
since the v7 release. The migration guide for the new select syntax is
outlined in the [Select
documentation](https://ionicframework.com/docs/api/select#migrating-from-legacy-select-syntax).
2. This change has been documented in the Breaking Changes document with
a link to the migration guide.
BREAKING CHANGE:
The `legacy` property and support for the legacy syntax, which involved
placing an `ion-select` inside of an `ion-item` with an `ion-label`,
have been removed from select. For more information on migrating from
the legacy select syntax, refer to the [Select
documentation](https://ionicframework.com/docs/api/select#migrating-from-legacy-select-syntax).
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: internal
---------
## What is the current behavior?
In Ionic Framework v7, we [simplified the input
syntax](https://ionic.io/blog/ionic-7-is-here#simplified-form-control-syntax)
so that it was no longer required to be placed inside of an `ion-item`.
We maintained backwards compatibility by adding a `legacy` property
which allowed it to continue to be styled properly when written in the
following way:
```html
<ion-item>
<ion-label>Label</ion-label>
<ion-input></ion-input>
</ion-item>
```
While this was supported in v7, console warnings were logged to notify
developers that they needed to update this syntax for the best
accessibility experience.
## What is the new behavior?
- Removes the `legacy` property and support for the legacy syntax.
Developers should follow the [migration
guide](https://ionicframework.com/docs/api/input#migrating-from-legacy-input-syntax)
in the input documentation to update their apps. The new syntax requires
a `label` or `aria-label` on `ion-input`:
```html
<ion-item>
<ion-input label="Label"></ion-input>
</ion-item>
```
- Removes the legacy tests under under `input/test/legacy/` and all
related screenshots
- Removes the input usage from `item/test/a11y`, `item/test/counter`,
`item/test/disabled`, `item/test/highlight`,
`item/test/legacy/alignment`, `item/test/legacy/disabled`,
`item/test/legacy/fill`, and `item/test/legacy/form` and all related
screenshots if the test was removed
## Does this introduce a breaking change?
- [x] Yes
- [ ] No
1. Developers have had console warnings when using the legacy syntax
since the v7 release. The migration guide for the new input syntax is
outlined in the [Input
documentation](https://ionicframework.com/docs/api/input#migrating-from-legacy-input-syntax).
2. This change has been documented in the Breaking Changes document with
a link to the migration guide.
BREAKING CHANGE:
The `legacy` property and support for the legacy syntax, which involved
placing an `ion-input` inside of an `ion-item` with an `ion-label`, have
been removed from input. For more information on migrating from the
legacy input syntax, refer to the [Input
documentation](https://ionicframework.com/docs/api/input#migrating-from-legacy-input-syntax).
---------
Co-authored-by: ionitron <hi@ionicframework.com>
⚠️ This is a combination of previously approved PRs with the
exception of
fe9dca513c.
This change was made as a result of
https://github.com/ionic-team/ionic-framework-design-documents/pull/248.
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. -->
Users do not have a way of increasing the contrast in Ionic apps. This
is valuable for people with low vision as increasing the contrast
between foreground and background content helps improve readability.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Adds a high contrast light and high contrast dark theme. As with our
other themes, developers can choose between system, class, and always
stylesheets.
While we aim to improve contrast for text and UI components, this
feature prioritizes text in the event that both text and UI component
cannot be improved without one negatively impacting the other.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## 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.6.7-dev.11706894781.1cd59fde`
Testing instructions:
1. Open `src/themes/test/css-variables`. Activate the high contrast
light and dark themes to verify that contrast does increase.
2. Use the dev build to integrate the theme into a test app (conference
app, starter app, etc).
I'd recommend using these imports:
```css
@import "@ionic/angular/css/themes/high-contrast.system.css";
@import "@ionic/angular/css/themes/high-contrast-dark.system.css";
```
Note: Make sure this is imported **after** `core.scss`
---------
Co-authored-by: Shawn Taylor <shawn@ionic.io>
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Co-authored-by: Sean Perkins <13732623+sean-perkins@users.noreply.github.com>
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.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. -->
This code was added to account for a Safari 14 issue that would cause
datetime to render incorrectly. The Safari bug was fixed starting in
Safari 15. However, Ionic v7 supported back to Safari 14.
More context is available
[here](https://github.com/ionic-team/ionic-framework/pull/24421#discussion_r796113907)
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed the Safari 14 workarounds since Ionic v8 does not support
Safari 14
I tested on iOS 15, 16, and 17 to verify that removing this hack does
not cause any issues. Also verified that removing this hack does
reproduce the issue on iOS 14 (to verify that I am reproducing the
original issue correctly)
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## 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: 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. -->
Ionic Framework has a patch implementation to workaround a Safari 14 bug
that resulted in the calendar month jumping when opening/closing the
month/year interface.
This bug was fixed in Safari 15.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Ionic v8 no longer supports Safari 14, so we can safely remove this
patch code
- Calendar month does not jump when opening/closing the month/year
interface with Safari/iOS 15-17
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## 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 tested on Sims for iOS 15-17. Tested against a physical device for iOS
17 as well.
Issue number: internal
---------
## What is the current behavior?
The old `border-radius` mixin added additional selectors and styles
depending on whether the direction was set to `ltr` or `rtl`.
Old mixin usage:
```scss
.old-border-radius {
@include border-radius(5px, 6px, 7px, 8px)
}
```
generates:
```css
.old-border-radius {
border-top-left-radius: 5px;
border-top-right-radius: 6px;
border-bottom-right-radius: 7px;
border-bottom-left-radius: 8px;
}
:host-context([dir=rtl]) .old-border-radius {
border-top-left-radius: 6px;
border-top-right-radius: 5px;
border-bottom-right-radius: 8px;
border-bottom-left-radius: 7px;
}
[dir=rtl] .old-border-radius {
border-top-left-radius: 6px;
border-top-right-radius: 5px;
border-bottom-right-radius: 8px;
border-bottom-left-radius: 7px;
}
@supports selector(:dir(rtl)) {
.old-border-radius:dir(rtl) {
border-top-left-radius: 6px;
border-top-right-radius: 5px;
border-bottom-right-radius: 8px;
border-bottom-left-radius: 7px;
}
}
```
## What is the new behavior?
The new `border-radius` mixin uses the [logical
properties](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical_properties_and_values/Margins_borders_padding)
which handles switching based on the
[writing-mode](https://developer.mozilla.org/en-US/docs/Web/CSS/writing-mode),
[direction](https://developer.mozilla.org/en-US/docs/Web/CSS/direction),
and
[text-orientation](https://developer.mozilla.org/en-US/docs/Web/CSS/text-orientation):
| Before | After |
| -----------------------------| ----------------------------|
| `border-top-left-radius` | `border-start-start-radius` |
| `border-bottom-left-radius` | `border-end-start-radius` |
| `border-top-right-radius` | `border-start-end-radius` |
| `border-bottom-right-radius` | `border-end-end-radius` |
New mixin usage:
```scss
.new-border-radius {
@include border-radius(5px, 6px, 7px, 8px)
}
```
```css
.new-border-radius {
border-start-start-radius: 5px;
border-start-end-radius: 6px;
border-end-end-radius: 7px;
border-end-start-radius: 8px;
}
```
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
## Other information
The `select` styles have been updated to use the mixin instead of
hardcoding `border-radius`.
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. -->
Team members are running into unexpected errors running spec tests:
```
TypeError: Cannot read properties of undefined (reading '$instanceValues$')
```
This line is the culprit:
f885a5526a/core/src/components/toast/test/toast.spec.tsx (L108)
We set the Ionic config for toastDuration to 5000. This means that on
present a setTimeout callback will fire after 5000ms and dismiss the
toast. For this test, this is fine because we never present the toast
therefore the setTimeout is never created.
The problem is that this config is not automatically reset between
tests. As a result, when we have tests that only present the toast (and
never dismiss it) the duration is also 5000 there:
f885a5526a/core/src/components/toast/test/toast.spec.tsx (L179-L184)
This results in a bunch of setTimeouts being created. The timeout
callback runs dismiss, and the body of that function tries to access
data on the host toast. Since the toast instance has already been torn
down (since the tests are done), the undefined error occurs.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Reset the Ionic config after the test that sets `toastDuration` to
`5000`
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
In https://github.com/ionic-team/ionic-framework/issues/28981 there was
some confusion surrounding how to remove an overlay from the DOM if it
was never presented. The `dismiss` method will remove the overlay from
the DOM, but only if the overlay is visible. Otherwise, it's a no-op.
This PR updates the `dismiss` method docs for each overlay component to
note that developers can use the browser's remove method to remove the
element from the DOM.
Issue number: internal
---------
## What is the current behavior?
In Ionic Framework v7, we [simplified the textarea
syntax](https://ionic.io/blog/ionic-7-is-here#simplified-form-control-syntax)
so that it was no longer required to be placed inside of an `ion-item`.
We maintained backwards compatibility by adding a `legacy` property
which allowed it to continue to be styled properly when written in the
following way:
```html
<ion-item>
<ion-label>Label</ion-label>
<ion-textarea></ion-textarea>
</ion-item>
```
While this was supported in v7, console warnings were logged to notify
developers that they needed to update this syntax for the best
accessibility experience.
## What is the new behavior?
- Removes the `legacy` property and support for the legacy syntax.
Developers should follow the [migration
guide](https://ionicframework.com/docs/api/textarea#migrating-from-legacy-textarea-syntax)
in the textarea documentation to update their apps. The new syntax
requires a `label` or `aria-label` on `ion-textarea`:
```html
<ion-item>
<ion-textarea label="Label"></ion-textarea>
</ion-item>
```
- Removes the legacy tests under `textarea/test/legacy/` and all related
screenshots
- Removes the textarea usage in `input/test/legacy/spec`,
`item/test/disabled`, `item/test/legacy/disabled` and
`item/test/legacy/fill`
## Does this introduce a breaking change?
- [x] Yes
- [ ] No
1. Developers have had console warnings when using the legacy syntax
since the v7 release. The migration guide for the new textarea syntax is
outlined in the [Textarea
documentation](https://ionicframework.com/docs/api/textarea#migrating-from-legacy-textarea-syntax).
2. This change has been documented in the Breaking Changes document with
a link to the migration guide.
BREAKING CHANGE:
The `legacy` property and support for the legacy syntax, which involved
placing an `ion-textarea` inside of an `ion-item` with an `ion-label`,
have been removed from textarea. For more information on migrating from
the legacy textarea syntax, refer to the [Textarea
documentation](https://ionicframework.com/docs/api/textarea#migrating-from-legacy-textarea-syntax).
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#28985
---------
<!-- 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. -->
<!-- Please describe the current behavior that you are modifying. -->
When a popover is being rendered in iOS mode, the arrow renders under
the backdrop.
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The arrow renders at the same level as the content.
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Credit [Sahil-B07](https://github.com/Sahil-B07) for providing the
[fix](https://github.com/ionic-team/ionic-framework/pull/28430). A new
PR had to be created in order to update snapshots.
---------
Co-authored-by: Sahil Bhor <92709590+Sahil-B07@users.noreply.github.com>
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#28541
---------
<!-- 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. -->
On iOS when dismissing the `ion-action-sheet`, the animation does not
account for the safe area of the device. This results in the action
sheet not completely animating off the visible viewport on a device with
safe area enabled.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The `ion-action-sheet` will animate consistently off the viewport when
dismissing, including the safe area.
To better support custom animations not needing to account for the safe
area, the safe area has been added to the padding of the action sheet
container. This results in the height increasing based on the bottom
safe area and animating correctly when translating between [`100%` and
`0%`](9d57758e3e/core/src/components/action-sheet/animations/ios.enter.ts (L23)).
|Before|After|
|---|---|
|<video
src="https://github.com/ionic-team/ionic-framework/assets/13732623/d9475a54-f1b9-4283-ae1a-86e2b71a9d9e"></video>|<video
src="https://github.com/ionic-team/ionic-framework/assets/13732623/d051b4d9-4f45-4a51-b522-510f8cddef74"></video>|
In the recorded examples the bottom safe area is exaggerated to show the
dismiss animation differences.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
To test this PR, I would recommend adding the following styles to the
action sheet basic test:
```html
<style>
ion-action-sheet {
--ion-safe-area-bottom: 100px;
}
</style>
```
You can then open dev-tools and slow the animation speed to 10%:
- Open and dismiss the action sheet tied to the "Basic" button.
- Verify that the action sheet animates completely off the view when
dismissed.
- Open the and dismiss the action sheet tied to the "Custom CSS Class"
button. This implementation customizes the `--height` of the action
sheet.
- Verify that the action sheet animates completely off the view when
dismissed.
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: resolves#28963
---------
<!-- 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. -->
In https://github.com/ionic-team/ionic-framework/pull/28861 I fixed an
issue that caused the wrong content inside of a popover to be
scrollable. This CSS should have been applied, but it broke back when
popover was converted to the Shadow DOM. Fixing this issue revealed a
misconfiguration with the select-popover that caused the select-popover
to no longer be scrollable.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Content inside of `ion-select-popover` can now be scrolled
Note that I am considering this a bug fix instead of a regression. While
scrolling used to work in select-popover, it only worked by chance. The
`.popover-viewport` styles should have always applied to the
select-popover, thus requiring the use of `overflow-y: auto` in
select-popover.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## 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.7.1-dev.11706893059.1bef4b38`
Issue number: resolves#28352
---------
<!-- 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. -->
Not all animations are getting properly destroyed after they run. This
means that styles can get stuck at the end value of their animation.
Specifically for this reproduction (as reported in the bug ticket), if
the modal animates from 1 to 0 opacity and then the modal gets reopened
with a different animation where the opacity should be 1 throughout
(i.e. the opacity isn't supposed to animate at all), the modal is
invisible because the opacity got stuck at 0 and never got reset to the
default value of 1.
This bug is probably causing some incorrect behavior on other edge cases
with overlays, but this is the only one I've identified.
### Reproduction steps
Note: you cannot reproduce this when using a modalController
1. Open a modal, e.g. [this
one](http://localhost:3333/src/components/modal/test/card-nav?ionic:mode=ios)
in `ios` mode on a screen wider than 768px
1. Close the modal
1. Open the same modal on a screen narrower than 768px
1. See that the modal does not appear
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Animations are properly destroyed after the animation completes
- The modal now appears as expected after following the reproduction
steps above
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
<!--
## 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: Liam DeBeasi <liamdebeasi@users.noreply.github.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. -->
Several tests were still using the legacy form syntax.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Migrated tests in `core`, `angular`, and `vue` to use the modern form
syntax (`react` did not have form controls).
I opted not to migrate `item/test/highlight` and `item/test/counter`
because those tests are going to be removed in the future once the
deprecate item APIs are removed.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## 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>
Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
Issue number: resolves#27965
---------
https://www.youtube.com/watch?v=a_m7jxrTlaw&list=PLIvujZeVDLMx040-j1W4WFs1BxuTGdI_b&index=3
<!-- 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 is a lack of autocomplete support for AlertButton attribute of
`role` (there may be similar situations for other components too,
however, I was working on this component and found it).
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Support for autocomplete for the two types defined `cancel` and
`destructive`, and also supports any arbitrary string if passed in.
## 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 suggest there to be some global interface similar to the following:
```
interface LooseAutocomplete<T extends string> = T | Omit<string, T>;
```
I referenced this great [video](https://youtu.be/a_m7jxrTlaw) from Matt
@mattpocock
---------
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.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-input` component currently specifies a `size` attribute to
align with the HTML `input` implementation. However, Ionic's custom
appearance for MD and iOS is not compatible and should not be used with
the `size` attribute:
https://github.com/ionic-team/ionic-framework/issues/27945#issuecomment-1669702274.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The `size` property has been removed from `ion-input`.
## Does this introduce a breaking change?
- [x] Yes
- [ ] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
The `size` attribute has been removed from `ion-input`. As it was not
compatible before, this is likely to have a minimal impact to
developers. If your application is using the `size` attribute, replace
the usage with CSS styling to control the width of the `ion-input`.
## 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: resolves#28769
---------
<!-- 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 https://github.com/ionic-team/ionic-framework/pull/28146, we
allowed text wrapping inside of `ion-item` for accessibility purposes.
One of the behaviors we added was to allow start, default, and end
slotted containers to wrap to the next line to align with the iOS spec.
However, this decision was based on an incorrect assumption.
The following screenshot shows the Settings app on iOS:
| default scale | 310% scale |
| - | - |
| <img width="1170" alt="Frame 4"
src="https://github.com/ionic-team/ionic-framework/assets/2721089/462ef153-a060-41c8-9a00-f0aad17839be">
| <img width="1170" alt="Frame 5"
src="https://github.com/ionic-team/ionic-framework/assets/2721089/f047f880-7b80-4710-939b-96da075fbbf9">
|
At the default scale, the blue icon is in the iOS equivalent of the
"start" slot, "Bluetooth" is in the default slot, and "On" is in the
"end" slot. We incorrectly assumed the same markup was true when scaling
the text up. However, at 310% scale the icon, "Bluetooth" text, and "On"
text all become part of the default slot in a single container that
wraps. You can tell because the bottom border runs underneath the blue
icon at 310% whereas it does not at the default scale. This allows the
text to wrap underneath the blue icon. When we originally implemented
#28146 we thought that this meant the start, default, and end slot
containers should wrap to the next line.
I further validated this behavior by creating an app with Swift UI. I
created a list of items where each item has the native equivalent of a
checkbox in the `start` slot and multiple `ion-labels` in the default
slot of the item:
| Default Scale | 310% Scale |
| - | - |
|
|
|
The content within each label wraps within the container, but the
containers themselves never wrap to the next line.
Demo code:
```swift
import SwiftUI
struct ContentView: View {
struct Item: Identifiable, Hashable {
let id = UUID()
}
private var items = [
Item(),
Item(),
Item(),
Item(),
Item()
]
@State private var multiSelection = Set<UUID>()
var body: some View {
NavigationView {
List(items, selection: $multiSelection) {_ in
HStack {
Text("Column 1 with really long text")
Text("Column 2 with really long text")
Text("Column 3 with really long text")
Text("Column 4 with really long text")
}
}
.toolbar { EditButton() }
}
Text("\(multiSelection.count) selections")
}
}
#Preview {
ContentView()
}
```
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- This PR removes the ability for the start, default, and end slot
containers to wrap to the next line. This behavior aligns with
pre-v7.6.0 behaviors. The containers inside of the default slot will not
wrap to the next line. However, content within each container (such as
text within an `ion-label`) will continue to wrap to meet the team's
accessibility requirements.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## 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.6.5-dev.11704916749.1e64a3a7`
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#28525
---------
<!-- 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 navigated via tab-key, the ion-item is not highlighted correctly
after switching from button=false to button=true.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Now, when dynamically changing the the `button` option to `True`,
there's a `@watch` callback that will make sure the internal
`isFocusable` `@state` will be updated.
- A new unit test was added to item/test. As there was still any unit
test for the `ion-item`, a new files was created - `item.spec.tsx`
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
New behavior in runtime:
---------
Co-authored-by: Sean Perkins <sean@ionic.io>
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 some tests that use Playwright's `waitForSelector`
[function](https://playwright.dev/docs/api/class-page#page-wait-for-selector).
However, Playwright has informed the community to not use this function
by labeling it as
[discouraged](https://playwright.dev/docs/api/class-page#page-wait-for-selector).
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Replaced `waitForSelector` with the
[recommended](https://playwright.dev/docs/api/class-page#page-wait-for-selector)
`waitFor`
[function](https://playwright.dev/docs/api/class-locator#locator-wait-for).
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## 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
Issue number: resolves#28344
---------
<!-- 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 an Accordion is inside an Accordion Group, and the Accordion Group
is enabled and not readonly but the Accordion is disabled and/or
readonly, it is possible to navigate to the accordion and open it using
the keyboard. This should not be allowed, just like opening it on click
is not allowed.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- A disabled Accordion inside an Accordion Group may not be opened via
the keyboard.
- A readonly Accordion inside an Accordion Group may not be opened via
the keyboard.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## 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: resolves#28455
---------
<!-- 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 main `ion-content` inside of a popover is not scrollable. Instead,
the `.popover-viewport` container is scrolled because certain styles no
longer applied once we moved popover to the Shadow DOM. This bug
impacted the linked issue because it meant that the infinite scroll
inside of the content never fires (since the content never scrolls).
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The `.popover-viewport` rule now targets slotted content with
the`.popover-viewport` class. This class is added to the root node that
is slotted. This enables us to target the user's content in the light
dom.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## 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.6.6-dev.11705696534.177666f8`
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#28602
---------
<!-- 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. -->
We animate to the new date when the value is changed, but we do not
account for multiple selection. This behavior is valuable for when the
value is set asynchronously on a different month than what it shown.
However, this is confusing when there are multiple dates selected in
different months, because we do not reasonably know which date to
animate to.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Datetime no longer animates to the new value if more than one date is
selected, and the selected dates aren't all in the same month.
An alternative strategy would be to always animate unless one of the
selected dates is in the month currently being viewed. However, this
would still mean guessing at which value the user wants to see, which we
are trying to avoid.
Based on this PR:
https://github.com/ionic-team/ionic-framework/pull/28605
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## 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: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
---------
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: resolves#28325
---------
<!-- 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 typing the time into the date picker pressing "Enter" does not
close the on-screen keyboard.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Pressing "Enter" closes the on-screen keyboard
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Test:
⚠️ While I have a test for this, please also test this on a physical
Android device.
1. Go to `src/components/datetime/test/basic`
2. Open the time picker (in any of the date times)
3. Tap the time to open the keyboard
4. Press "Enter" on Android. Observe that the keyboard closes.
Dev build: `7.6.6-dev.11705528328.1ef5e17b`
Issue number: resolves#28816
---------
<!-- 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 value is set on Segment asynchronously when binding it in Angular.
However, the timing works out such that the value changes after
`connectedCallback` is fired but before any Stencil Watchers are
configured. As a result, our `value` property watcher does not fire
which causes `ionSelect` to not be emitted. Segment Buttons rely on this
event to know when to update their state (if the value changes such that
a segment button is now selected). This results in a checked segment
button not appearing checked.
This is similar to other issues that have been fixed:
https://github.com/ionic-team/ionic-framework/pull/28510https://github.com/ionic-team/ionic-framework/pull/28488https://github.com/ionic-team/ionic-framework/pull/28526
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Segment now emits `ionSelect` on `componentDidLoad` so that any
descendant segment buttons can update correctly.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## 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.6.5-dev.11705415448.16878103`
This is a timing issue with Stencil, so I am unable to write a reliable
automated test. Reviewers should test the dev build in the repro
provided in the linked issue.
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. -->
When iOS alert has 3 or more buttons, those are rendered vertically. All
but the last button will have a right border. There shouldn't be a right
border when the buttons are stacked.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Vertical buttons don't have a right border.
- Separated the test in order to also test dark theme.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## 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: resolves#28818
---------
<!-- 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. -->
Select has logic in place to prevent the overlay from opening when
clicking the slotted content. As part of this, we need to deal with the
`<label>` element dispatching another click that then bubbles up and
causes the overlay to open when clicking the slotted content. We
currently deal with this by calling `preventDefault` which prevents this
extra event from being dispatched only when clicking the slotted
content.
We also call `stopPropagation`. This code is not necessary, and in most
cases should not have any adverse effects on developer applications.
However, this does impact React applications due to how React handles
events. When a developer places `onClick` on a slotted element, a native
"click" listener is not immediately applied to that element. Instead,
React adds a native "click" listener to the root element of an
application. When that listener's callback fires, React will dispatch a
synthetic click event on the slotted element. Since we are calling
`stopPropagation`, the click event never bubbles up to this root node's
listener. As a result, the synthetic event is never dispatched on the
slotted element, and the developed `onClick` callback never fires.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Select no longer prevents events from bubbling. The existing
`event.preventDefault` is sufficient to prevent the label from
dispatching another click (thereby causing the select overlay to open)
when clicking the slotted content.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## 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.6.5-dev.11705430252.1023daf3`
resolves#28826
BREAKING CHANGE: `getLength` returns `Promise<number>` instead of `<number>`. This method was not previously available in Nav's TypeScript interface, but developers could still access it by casting Nav as `any`. Developers should ensure they `await` their `getLength` call before accessing the returned value.
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. -->
In MD mode, items in an inset list currently receive their own border
radius, separate from the border radius also applied to the inset list
itself. The original intent was likely to ensure that the corners of the
items don't spill out of the list. However, the item's border radius is
no longer needed, for two reasons:
1. MD has since added top/bottom padding to their lists
([spec](https://m2.material.io/components/lists#specs)), which we've
mirrored. This means the borders no longer line up anyway.
2. Even if a developer removes the list's vertical padding (we set it on
the host
[here](535b8ed724/core/src/components/list/list.md.scss (L9)),
so it's easy to overwrite), inset lists currently have `overflow:
hidden` set
[here](535b8ed724/core/src/components/list/list.scss (L20)),
so the list's border radius still applies correctly even with the items'
border radius removed.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Item border radius in inset lists removed.
When testing locally, you may find it useful to increase the MD border
radius value
[here](535b8ed724/core/src/components/list/list.md.vars.scss (L47))
so it's easier to see.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
3. Update the BREAKING.md file with the breaking change.
4. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## 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: 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. -->
`ion-button` is being used as a way to open the alerts. It's not being
used to test functionality.
When `ion-button` is updated then the screenshots in the alert tests
must be updated. This shouldn't happen when `ion-button` isn't necessary
to have in these tests.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Replaced `ion-button` with `button`
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## 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: resolves#16304, resolves#20681
---------
<!-- 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. -->
Split Pane assumes that Menu is a child of the Split Pane. This means
that CSS selectors and JS queries only check for children instead of
descendants. When a Menu is encapsulated in a component that component
can itself show up as an element in the DOM depending on the
environment. For example, both Angular and Web components show up as
elements in the DOM. This causes the Menu to not work because it is no
longer a child of the Split Pane.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Menu can now be used as a descendant of Split Pane. The following
changes make this possible:
1. When the menu is loaded, it queries the ancestor Split Pane. If one
is found, it sets `isPaneVisible` depending on if the split pane is
visible or not.
2. Any changes to the split pane visibility state after the menu is
loaded will be handled through the `ionSplitPaneVisible` event.
3. A menu is now considered to be a pane if it is inside of a split pane
4. Related CSS no longer uses `::slotted` which only targets children.
The CSS was moved into the menu stylesheets. I consider the coupling
here to be valuable as menu and split pane are often used together. We
also already have style coupling between the two components, so this
isn't anything new.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
There are no known changes to the public API or public behavior.
However, there are two risks here:
1. There is an unknown risk into how this change impacts nested split
panes. This isn't an explicitly supported feature, but it technically
works in Ionic now. We don't know if anyone is actually implementing
this pattern. We'd like to evaluate use cases for nested split panes
submitted by the community before we try to account for this
functionality in menu and split pane.
5. There may be some specificity changes due to the new CSS. CSS was
moved from split pane to menu so it could work with encapsulated
components:
`:host(.split-pane-visible) ::slotted(.split-pane-side)` has a
specificity of 0-1-1
`:host(.menu-page-visible.menu-pane-side)` has a specificity of 0-1-0
There shouldn't be any changes needed to developer code since the
selectors are in the Shadow DOM and developer styles are in the Light
DOM. However, we aren't able to anticipate every edge case so we'd like
to place this in a major release just to be safe.
## 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.6.2-dev.11704922151.1fd3369f`
