## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Checkbox's render function applies the `label-text-wrapper-hidden` css
class when there is no label text to prevent extra margin from being
added. The render function is not re-evaluated if the label is updated.
This causes a problem in Angular where dynamic variables get applied
after the page is loaded, and a checkbox using a variable as a label
gets stuck with its label hidden until something else triggers a
re-render, e.g. ticking the box.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The checkbox will be re-rendered, and css classes will be updated,
when the label text is changed.
- Updated tests to check that the label is visible after changing from
blank to having 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/docs/CONTRIBUTING.md#footer
for more information.
-->
Issue number: internal
---------
## What is the current behavior?
Currently, the 8.8 refresher events are not exported to Angular
## What is the new behavior?
With this change, we export the new events and also add Angular tests to
validate that they work and will continue working in the future.
## Does this introduce a breaking change?
- [ ] Yes
- [X] No
Issue number: resolves internal
---------
## What is the current behavior?
When an accordion item was set as disabled, it was still possible to
focus using keyboard navigation.
## What is the new behavior?
When an accordion item is disabled, `tabindex` is set as -1 to stop
being focusable using the keyboard navigation.
## Does this introduce a breaking change?
- [ ] Yes
- [ ] No
## Other information
[preview](https://ionic-framework-qznd9tqne-ionic1.vercel.app/src/components/accordion-group/test/states/)
---------
Co-authored-by: Maria Hutt <maria.hutt@outsystems.com>
Issue number: resolves#30735
---------
## What is the current behavior?
Toast's wrapper and content divs do not have part attributes.
## What is the new behavior?
- Adds `wrapper` and `content` parts to Toast.
## 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/docs/CONTRIBUTING.md#footer
for more information.
-->
## Other information
This PR was originally opened by @Hurubon here in #30737. It was lost in
`feature-8.8` due to a bad merge, so this PR is to re-apply this feature
so it can go out in 8.8.1 (it was originally supposed to go out in
8.8.0)
Co-authored-by: Hurubon <58346722+Hurubon@users.noreply.github.com>
Co-authored-by: Hurubon <58346722+Hurubon@users.noreply.github.com>
Issue number: internal
---------
## What is the current behavior?
The sheet and card modal can be dragged to view content. However, there
are no events that determine when drag has started or ended.
## What is the new behavior?
- Added drag events for sheet and card modal: `ionDragStart`, `ionDragMove`, `ionDragEnd`
- Added a drag interface
- Added tests
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
---------
Co-authored-by: Shane <shane@shanessite.net>
Co-authored-by: Brandy Smith <brandyscarney@users.noreply.github.com>
Issue number: resolves#29862
---------
## What is the current behavior?
Range exposes a single part for both knobs & pins. This makes it impossible to style the knobs/pins differently when dual knobs is enabled.
## What is the new behavior?
- Fixes a bug where the knobs would swap A & B when they cross over each other
- Fixes the focus behavior so that dual knobs act the same as a single knob range when focusing a knob
- Adds the following classes to the host element when `dualKnobs` is enabled:
- `range-dual-knobs`
- `range-pressed-a` when the knob with name A is pressed
- `range-pressed-b` when the knob with name B is pressed
- `range-pressed-lower` when the lower knob is pressed
- `range-pressed-upper` when the upper knob is pressed
- Adds parts for the following:
- `knob-handle-a` — The container for the knob with the static `A` identity when `dualKnobs` is `true`. This identity does not change, even if the knobs cross and swap which one represents the lower or upper value.
- `knob-handle-b` — The container for the knob with the static `B` identity when `dualKnobs` is `true`. This identity does not change, even if the knobs cross and swap which one represents the lower or upper value.
- `knob-handle-lower` — The container for the knob whose current `value` is `lower` when `dualKnobs` is `true`. The lower and upper parts swap which knob handle they refer to when the knobs cross.
- `knob-handle-upper` — The container for the knob whose current `value` is `upper` when `dualKnobs` is `true`. The lower and upper parts swap which knob handle they refer to when the knobs cross.
- `pin-a` — The value indicator above the knob with the static `A` identity when `dualKnobs` is `true`. This identity does not change, even if the knobs cross and swap which one represents the lower or upper value.
- `pin-b` — The value indicator above the knob with the static `B` identity when `dualKnobs` is `true`. This identity does not change, even if the knobs cross and swap which one represents the lower or upper value.
- `pin-lower` — The value indicator above the knob whose current `value` is `lower` when `dualKnobs` is `true`. The lower and upper parts swap which pin they refer to when the knobs cross.
- `pin-upper` — The value indicator above the knob whose current `value` is `upper` when `dualKnobs` is `true`. The lower and upper parts swap which pin they refer to when the knobs cross.
- `knob-a` — The visual knob for the static `A` identity when `dualKnobs` is `true`. This identity does not change, even if the knobs cross and swap which one represents the lower or upper value.
- `knob-b` — The visual knob for the static `B` identity when `dualKnobs` is `true`. This identity does not change, even if the knobs cross and swap which one represents the lower or upper value.
- `knob-lower` — The visual knob whose current `value` is `lower` when `dualKnobs` is `true`. The lower and upper parts swap which knob they refer to when the knobs cross.
- `knob-upper` — The visual knob whose current `value` is `upper` when `dualKnobs` is `true`. The lower and upper parts swap which knob they refer to when the knobs cross.
- `activated` — Added to the knob-handle, knob, and pin when the knob is active. Only one set has this part at a time when `dualKnobs` is `true`.
- `focused` — Added to the knob-handle, knob, and pin that currently has focus. Only one set has this part at a time when `dualKnobs` is `true`.
- `hover` — Added to the knob-handle, knob, and pin when the knob has hover. Only one set has this part at a time when `dualKnobs` is `true`.
- `pressed` — Added to the knob-handle, knob, and pin that is currently being pressed to drag. Only one set has this part at a time when `dualKnobs` is `true`.
- Adds e2e tests for the following:
- customizing label part
- customizing bar parts
- customizing pin parts
- customizing tick parts
- customizing knob parts
- customizing dual knob a & b parts
- customizing dual knob lower & upper parts
- verifies that a & b parts stay on the original elements but lower & upper parts swap when the values swap
- Adds spec tests for the following:
- css classes
- value state classes
- boolean property classes
- pressed state classes
- shadow parts
- static shadow parts
- verifies the shadow parts exist based on the existence of certain range properties
- state shadow parts
- verifies the shadow parts exist based on the state of the range knob (pressed, focused, activated, hover)
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
---------
Co-authored-by: Brandy Smith <6577830+brandyscarney@users.noreply.github.com>
Issue number: N/A
---------
## What is the current behavior?
The inner structural element of list-header is not exposed as a shadow part, preventing users from being able to customize its styles directly.
## What is the new behavior?
- Exposes `inner` shadow part
- Adds e2e test coverage for customizing the shadow part
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
---------
Co-authored-by: Brandy Smith <6577830+brandyscarney@users.noreply.github.com>
Issue number: N/A
---------
## What is the current behavior?
The inner structural elements of item-option are not exposed as shadow parts, preventing users from being able to customize their styles directly.
## What is the new behavior?
- Exposes `inner` and `container` shadow parts
- Adds e2e test coverage for customizing the shadow parts
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
---------
Co-authored-by: Brandy Smith <6577830+brandyscarney@users.noreply.github.com>
Issue number: N/A
---------
## What is the current behavior?
The inner structural elements of item-divider are not exposed as shadow parts, preventing users from being able to customize their styles directly.
## What is the new behavior?
- Exposes `inner` and `container` shadow parts
- Adds e2e test coverage for customizing the shadow parts
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
---------
Co-authored-by: Brandy Smith <6577830+brandyscarney@users.noreply.github.com>
Issue number: N/A
---------
## What is the current behavior?
The inner structural elements of item are not exposed as shadow parts, preventing users from being able to customize their styles directly.
## What is the new behavior?
- Exposes `inner` and `container` shadow parts
- Adds e2e test coverage for customizing the shadow parts
- Removes css variables test, combining it with the shadow parts test
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
---------
Co-authored-by: Brandy Smith <6577830+brandyscarney@users.noreply.github.com>
resolves#30279resolves#30359
## What is the current behavior?
While Ionic's `stencil.config.ts` sets `experimentalSlotFixes: true`,
the fixes never get applied at runtime. Ionic is using an external
runtime, so Ionic components import `defineCustomElement` from
`@stencil/core/internal/client` at runtime and this code has no
awareness of the project's stencil configuration.
This leads to a `NotFoundError` (Failed to execute 'removeChild' on
'Node') when filtering or dynamically removing radios in an
`ion-radio-group`. The error occurs because `ion-radio-group` wraps its
slotted content in an internal `<div>`.
## What is the new behavior?
By setting `externalRuntime: false`, Stencil generates a
project-specific file with `defineCustomElement` that components import.
This file has the project's build settings baked in, correctly applying
slot fixes.
Additionally, the internal wrapper `<div>` around the slotted content in
`ion-radio-group` is removed. With slot fixes correctly applied and the
wrapper removed, radios can be filtered or dynamically removed without
triggering `NotFoundError` or `DOMExceptions`.
## Does this introduce a breaking change?
- [ ] Yes
- [X] No
## Other information
External Runtime is enabled by default and designed for projects that
import Stencil components from multiple sources. This is flawed because
those components will not be running with the runtime settings for which
they were made.
Issue number: resolves#24524
---------
<!-- 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?
There is no way to know when the refresher has fully returned to its
inactive state after a pull gesture. The existing `ionStart` event fires
when pulling begins, but there is no corresponding end event. Watching
the progress property is insufficient because hitting zero doesn’t
necessarily mean the user has completed the pull gesture.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Two new events are added to the refresher component:
- `ionPullStart`: Emitted when the user begins pulling down (same as
`ionStart`, which is now deprecated)
- `ionPullEnd`: Emitted when the refresher returns to inactive state,
with a `reason` property of `'complete'` or `'cancel'` indicating
whether the refresh operation completed successfully or was cancelled
This allows you to know both when the user is no longer touching the
screen AND when the refresher is ready to be pulled again.
## 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/docs/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 page:
https://ionic-framework-git-fw-6591-ionic1.vercel.app/src/components/refresher/test/basic/index.html
Current dev build:
```
8.7.17-dev.11770319814.172b4f50
```
---------
Co-authored-by: Patrick McDonald <764290+WhatsThatItsPat@users.noreply.github.com>
Issue number: resolves#30860
## What is the current behavior?
We have flaky tests in an ionic angular project that root cause are not
cleaned up timeouts.
I commented out the timeout in the searchbar componentWillLoad method.
and after several runs no flaky tests at all.
My guess -> test runs faster than the 300ms it takes til the timeout
runs. Everything is cleaned up, but not the ionic timeouts (i think i
saw something similar in other components)
## What is the new behavior?
Timeouts are cleaned on disconnect.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
## Other information
Testrunner is vitest + angular 20 and latest ionic version 8.x
Issue number: resolves#28411
---------
<!-- 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?
When a modal is displayed on tablet-sized screens (>= 768px × >= 600px),
the `--ion-safe-area-*` CSS variables are explicitly set to 0px. This
was intended for inset modals that don't touch screen edges, but it
breaks safe area handling on newer iPads with Face ID/home indicators,
causing content to overlap with system UI elements.
## What is the new behavior?
Modals now dynamically handle safe-area insets based on their type and
position. This has to be done because modals that don't touch the edges
cannot have a safe area applied (because it will add unnecessary
padding), but modals that do touch the edges need to apply safe area
correctly or the edges will be obstructed by whatever is in the safe
area.
## 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/docs/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. -->
[Modals test
page](https://ionic-framework-git-fw-6830-2-ionic1.vercel.app/src/components/modal/test/safe-area/index.html)
[Popovers test
page](https://ionic-framework-git-fw-6830-2-ionic1.vercel.app/src/components/popover/test/safe-area/index.html)
Current dev build:
```
8.7.18-dev.11770674094.18396f54
```
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#30290
---------
## What is the current behavior?
The segment view swipe gesture can only be disabled by adding the `disabled` property and setting `opacity: 1`.
## What is the new behavior?
- Adds a new property, `swipeGesture`, to disable swiping on the segment view
- Adds an e2e test which verifies the styles blocking the swipe are correctly applied when `swipeGesture` is `false`
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
---------
Co-authored-by: Brandy Smith <6577830+brandyscarney@users.noreply.github.com>
## What is the current behavior?
Content does not reflect the `fullscreen` property or add a class when it is enabled, making it harder to style.
## What is the new behavior?
- Adds `content-fullscreen` class to content when `fullscreen` is true
- Adds an e2e test verifying the class is applied
---------
Co-authored-by: Brandy Smith <6577830+brandyscarney@users.noreply.github.com>
## What is the current behavior?
Range adds classes to the knobs at `min` and `max`, but the host element doesn't reflect those states.
## What is the new behavior?
- Adds `range-value-min` and `range-value-max` when the value is at the `min` or `max`, respectively.
- Adds a spec test verifying the classes are applied properly.
---------
Co-authored-by: Brandy Smith <6577830+brandyscarney@users.noreply.github.com>
Issue number: resolves#30908
---------
## What is the current behavior?
Toast with an icon and long message using a stacked layout will wrap the
message below the icon.
## What is the new behavior?
- Apply `flex: 1` to `.toast-content` regardless of layout, which makes
sure the content does not get wrapped under the icon
- Adds an e2e test for a stacked toast with a long message to
`toast/test/layout`
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
## Other information
- Dev build: `8.7.18-dev.11768592717.14a59d2f`
- Preview:
[Layout](https://ionic-framework-git-fw-7035-ionic1.vercel.app/src/components/toast/test/layout/)
---------
Co-authored-by: Brandy Smith <6577830+brandyscarney@users.noreply.github.com>
Issue number: resolves 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?
When using `ion-input` with a label on Android, TalkBack treats the
visual label text as a separate focusable element. This causes the
initial focus to land on the label instead of the input field, creating
a confusing experience for screen reader users.
## What is the new behavior?
The label text wrapper is now hidden from the accessibility tree via
`aria-hidden="true"`, while the native input maintains proper labeling
through `aria-labelledby`. This ensures Android TalkBack focuses
directly on the input field while still announcing the label 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/docs/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. -->
Current dev build:
```
8.7.16-dev.11767032989.1ae720d0
```
Issue number: resolves internal
---------
## What is the current behavior?
When `ion-tab-bar` is rapidly mounted and unmounted, a race condition in
connectedCallback can cause the keyboard controller to be created after
the component has been disconnected. This results in orphaned event
listeners (`keyboardWillShow`, `keyboardWillHide`) on the window object
that are never cleaned up, causing a memory leak.
## What is the new behavior?
The keyboard controller is now properly destroyed in all scenarios:
- If the component is disconnected while createKeyboardController is
pending, the promise is tracked and destroyed when it resolves
- If a new connectedCallback runs before the previous async completes,
the stale controller is destroyed
The promise tracking pattern ensures only the most recent async
operation assigns its result
## 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/docs/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. -->
Current dev build:
```
8.7.17-dev.11767895575.16ea7cef
```
I was unable to find a way to create tests that accurately identified if
this problem was occurring. Memory leaks are notoriously difficult to
created automated tests for. I ultimately removed my previous attempts
because I didn't want to give a false sense of security.
Issue number: resolves 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?
On iOS, when focusing an `ion-input` or `ion-textarea` that requires
scrolling into view (scroll assist), the placeholder text shifts to the
left and overlaps any content in the start slot (e.g., icons). This
occurs because the cloned input used during scroll assist is positioned
at the container's left edge rather than at the native input's actual
position. Additionally, when quickly switching between inputs before
scroll assist completes, focus jumps back to the original input.
## What is the new behavior?
The cloned input is now positioned at the same offset as the native
input, preventing the placeholder from shifting or overlapping start
slot content during scroll assist. This works correctly for both LTR and
RTL layouts. Also, scroll assist no longer steals focus back if the user
has moved focus to another element while scrolling was in progress.
## 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/docs/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. -->
Current dev build:
```
8.7.16-dev.11767042721.11309185
```
Issue number: resolves#30679
---------
<!-- 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?
When a page contains a card modal with a `presentingElement`, resizing
the viewport (e.g., rotating from portrait to landscape) triggers the
card modal's "lean back" animation on the presenting element, even when
the modal has never been opened.
## What is the new behavior?
Viewport resize events no longer trigger the presenting element
animation when the modal is not presented. The animation only runs when
the modal is actually open.
## 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/docs/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. -->
Current dev build:
```
8.7.16-dev.11767028735.16932cea
```
Issue number: resolves#30679
---------
<!-- 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?
When a page contains a card modal with a `presentingElement`, resizing
the viewport (e.g., rotating from portrait to landscape) triggers the
card modal's "lean back" animation on the presenting element, even when
the modal has never been opened.
## What is the new behavior?
Viewport resize events no longer trigger the presenting element
animation when the modal is not presented. The animation only runs when
the modal is actually open.
## 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/docs/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. -->
Current dev build:
```
8.7.16-dev.11767028735.16932cea
```
Issue number: resolves 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?
The `ion-input-password-toggle` button uses `role="switch"` with
`aria-checked`, causing screen readers like VoiceOver to announce both a
state ("On/Off") and an action ("Show/Hide password"). This results in
confusing, redundant output such as "On, Hide Password" or "Off, Show
Password".
## What is the new behavior?
The password toggle button now uses `aria-pressed` instead of
`role="switch"` with `aria-checked`. Screen readers announce the
action-based label ("Show password" or "Hide password") along with the
pressed state, and properly announce state changes when the button is
activated.
## 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/docs/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. -->
[Old
Preview](https://ionic-framework-git-main-ionic1.vercel.app/src/components/input-password-toggle/test/basic)
[New
Preview](https://ionic-framework-git-fw-6920-ionic1.vercel.app/src/components/input-password-toggle/test/basic)
Current dev build:
```
8.7.15-dev.11766421552.180757ca
```
Issue number: resolves#29929
---------
## What is the current behavior?
When forcing `mode=ios` in a collapsible header,
`.header-collapse-condense` would still be applied from the
`header.md.scss` file, leaving the collapsible header always hidden.
## What is the new behavior?
When forcing `mode=ios` in a collapsible header, the
`.header-collapse-condense` styles from the `header.md.scss` file won't
be applied, and the collapsible header will be visible.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
## Other information
Something worth mentioning is that this behavior only appears after
initial load: if the route is loaded refreshing the page, the header
will appear and work correctly, but navigating forth and back will apply
both the .ios and .md style files.
I showcase this with a modal because It'll always display the broken
hehavior.
| Before | After |
|--------|-------|
| <video
src="https://github.com/user-attachments/assets/1307ee9f-452a-4b00-877d-0b8e360d3bf7">
| <video
src="https://github.com/user-attachments/assets/f9ee3851-ce94-4a27-9947-37aa1f5433b9">
|
---------
Co-authored-by: ShaneK <shane@shanessite.net>
Issue number: resolves#30030
---------
## What is the current behavior?
When modals are presented one after another with matching IDs and then
dismissed by ID it will dismiss the first presented modal.
## What is the new behavior?
- When modals are presented one after another with matching IDs and then
dismissed by ID it will dismiss the last (top-most) presented modal.
- Added e2e tests to verify this behavior works the same as the default
dismiss (not passing an ID).
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
## Other information
[Modal: Dismiss
Behavior](https://ionic-framework-git-fw-7016-ionic1.vercel.app/src/components/modal/test/dismiss-behavior)
---------
Co-authored-by: Brandy Smith <6577830+brandyscarney@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 safe area variables are only reliant on `env` variables that are
provided by devices.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Capacitor 8 has released [safe area variable
fallbacks](https://capacitorjs.com/docs/apis/system-bars#android-note)
to provide consistent behaviors with older Android devices:
> Due to a [bug](https://issues.chromium.org/issues/40699457) in some
older versions of Android WebView (< 140), correct safe area values are
not available via the safe-area-inset-x CSS env variables. This plugin
will inject the correct inset values into a new CSS variable(s) named
--safe-area-inset-x that you can use as a fallback in your frontend
styles.
- Updated safe area variables to use the fallbacks provided by
Capacitor.
## 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/docs/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: `8.7.13-dev.11765920447.1a01ab8b`
---------
Co-authored-by: Brandy Smith <brandyscarney@users.noreply.github.com>
Issue number: resolves internal
---------
## What is the current behavior?
When using ModalController to present a modal in Angular applications,
the browser becomes non-responsive and hangs in some circumstances. This
regression was introduced in #30544 with the addition of a
MutationObserver that watches document.body with subtree: true to detect
when a modal's parent element is removed from the DOM. For
controller-based modals, this observer fires on every DOM mutation in
the document, causing severe performance issues during Angular's change
detection cycles.
## What is the new behavior?
The MutationObserver for parent removal detection is now skipped for
controller-based modals and when the cached parent is the app root
(document.body or ion-app). These parents are never removed from the
DOM, so observing them is unnecessary. This prevents the performance
issues while still maintaining the parent removal detection behavior for
inline modals with meaningful parent elements.
## 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/docs/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. -->
Current dev build:
```
8.7.12-dev.11765231260.1def96ab
```
---------
Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
Issue number: resolves#30700
---------
## What is the current behavior?
When a sheet modal with showBackdrop=false is rendered in a child route
(nested ion-router-outlet), the parent content becomes non-interactive.
Clicks on buttons or other interactive elements in the parent component
are blocked, even though showBackdrop=false should allow background
interaction.
Two separate issues contributed to this bug:
1. **Root locking with `backdropBreakpoint`**: The `shouldLockRoot`
logic in `overlays.ts` didn't account for `backdropBreakpoint`. Modals
with `backdropBreakpoint > 0` were still locking the root with
`aria-hidden`, even though developers expect background interaction when
the modal is below the backdrop breakpoint.
2. **Child route wrapper blocking**: When a modal is in a child route,
the child route's page wrapper (`ion-page`) and its parent
`ion-router-outlet` remain in the DOM with `position: absolute` covering
the viewport. Even after the modal is moved to `ion-app` and has
`pointer-events: none`, these wrapper elements block clicks to the
parent page's content.
This issue stems from
[#30563](https://github.com/ionic-team/ionic-framework/pull/30563),
which added root-locking behavior that didn't account for modals that
allow background interaction. A partial fix in
[#30689](https://github.com/ionic-team/ionic-framework/pull/30689)
partially addressed `showBackdrop=false` and `focusTrap=false`, but
missed `backdropBreakpoint`.
## What is the new behavior?
Sheet modals with showBackdrop=false or focusTrap=false now correctly
allow interaction with parent content when the modal is in a child
route.
Improvements:
- Recalculates isSheetModal in present() to handle Angular binding
timing
- Sets pointer-events: none on the modal element and its original parent
elements when background interaction should be allowed
- Cleans up pointer-events on dismiss
- Adds regression tests
## Does this introduce a breaking change?
- [ ] Yes
- [X] No
## 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:
```
8.7.12-dev.11765060985.14ad27fb
```
Issue number: internal
---------
## What is the current behavior?
A translucent header in a popover does not consistently render as
translucent upon presenting due to the `offset-top` of the content being
set to `0`.
## What is the new behavior?
Watch the header for height changes using `ResizeObserver` and
recalculate the content dimensions when the header height is greater
than `0`.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
---------
Co-authored-by: Brandy Smith <6577830+brandyscarney@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 screen reader does not announce when an option is selected within
the action sheet interface. This is because the action sheet uses
standard buttons, which do not support a detectable selected state via
native properties or ARIA attributes like `aria-checked` or
`aria-selected`, creating an inconsistent user experience across
different interface types.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updated the action sheet buttons to accept `role="radio"`
- Added keyboard navigation to follow the pattern for radio group
- Added test
## 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/docs/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. -->
[Basic](https://ionic-framework-git-fw-6818-ionic1.vercel.app/src/components/select/test/basic/)
---------
Co-authored-by: Brandy Smith <6577830+brandyscarney@users.noreply.github.com>
Co-authored-by: Shane <shane@shanessite.net>
Co-authored-by: Brandy Smith <brandyscarney@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. -->
Playwright's `setContent` cannot handle query params which causes the
`scripts.js` to not run effectively.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Update `scripts.js` to accept hash params as well
- Update `scripts.js` to accept the dark class to set dark mode if dark
query or hash was not passed
## 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/docs/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. -->
How to test:
1. Verify that tests are passing
---------
Co-authored-by: Brandy Smith <brandyscarney@users.noreply.github.com>
Issue number: resolves#30706
---------
<!-- 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?
Due to some recent unknown changes, the intersection observer for date
time no longer reliably fires, especially in mobile views.
## What is the new behavior?
In this PR, we're adding a visibility check after everything has had a
chance to render to make sure we're setting up properly even if the
intersection observer has failed to trigger for some reason.
## Does this introduce a breaking change?
- [ ] Yes
- [X] No
## Other information
Since the intersection observer is being set up after a `raf`, it's
possible something got introduced to make the initial setup slower for
some reason, causing timing issues. I think we should do a more thorough
investigation into the cause of this problem when we have more time.
This PR also adds tests to verify the new fallback works properly.
Current dev build:
```
8.7.10-dev.11763478209.1d9c4cd8
```
---------
Co-authored-by: Brandy Smith <brandyscarney@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. -->
Currently, when an error text is shown, it may not announce itself to
voice assistants. This is because the way error text currently works is
by always existing in the DOM, but being hidden when there is no error.
When the error state changes, the error text is shown, but as far as the
voice assistant can tell it's always been there and nothing has changed.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updated aria attributes
- Added observer with an observer
## 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/docs/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. -->
[Checkbox
preview](https://ionic-framework-git-fw-6757-ionic1.vercel.app/src/components/checkbox/test/validation/)
[Toggle
preview](https://ionic-framework-git-fw-6757-ionic1.vercel.app/src/components/toggle/test/validation/)
[Radio Group
preview](https://ionic-framework-git-fw-6757-ionic1.vercel.app/src/components/radio-group/test/validation/)
⚠️ Flakiness ⚠️
The flakiness on checkbox and toggle is because when a native input is
present on the page, the browser will have the screen reader to be
really fast when it comes to checking information. This speed ends up
being too fast for `ion-checkbox` to be able to add the error text. This
leads to the error text not being announce consistently. There's no
issue when it comes to ion-input or ion-textarea because Ionic uses the
native inputs so their arias are read. There's also no issue
with ion-select because we don't have a native input. It's only an issue
with checkbox and the others is because it has a [native input that is
being
hidden](8e884bd2cb/core/src/components/checkbox/checkbox.tsx (L368-L369)).
So the browser sees that and speeds up the screen reader.
The flakiness on radio group is because when you tab out of the last
radio button, the ionBlur event is emitted by the child <ion-radio>.
This event bubbles up, but the timing is still too early for the group.
Issue number: resolves#30613
---------
<!-- 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. -->
Currently, when you load an accordion group, the initially selected
accordion animates open. This is an unexpected change caused by
upgrading Stencil to >= 4.21.0, which changed the way component
lifecycles got triggered.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
With this change, we're waiting for the accordion in the accordion group
to render and telling it if the update it's going through is the initial
update or not. This allows it to decide to animate properly.
## 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/docs/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. -->
Current dev build:
```
8.7.8-dev.11761840817.1bede576
```
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. -->
`ionFocus` and `ionBlur` are not being emitted for checkbox and toggle.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Moved the `onFocus` and `onBlur` to `Host`
- Added tests for `onFocus`, `onBlur`, and `onChange`.
- Added a workaround on Playwright in order to trigger `ionBlur` since
Playwright browsers aren't acting like native browsers when it comes to
tabbing.
## 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/docs/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: `8.7.7-dev.11761071592.1d1b804d`
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Shane <shane@shanessite.net>
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 per accessibility guidelines, there should only be one banner
landmark per page. A condensed header creates two banner landmarks since
2 `ion-header` components are required on the page. `ion-header` renders
with a `role="banner"` by default (when not in `ion-menu`).
The visual effect of the condensed header is achieved by rendering two
distinct header components. Because both components exist in the code at
the same time and both have `role="banner"`, they create a duplicate
landmark announcement for screen readers. This leads to a violation with
the accessibility guidelines.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The role is updated to either `none` or `banner` based off the
header's active state.
- Added test.
## 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/docs/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. -->
[Preview](https://ionic-framework-git-fw-6767-ionic1.vercel.app/src/components/header/test/condense/?ionic%3Amode=ios)
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. -->
Currently, when an error text is shown, it may not announce itself to
voice assistants. This is because the way error text currently works is
by always existing in the DOM, but being hidden when there is no error.
When the error state changes, the error text is shown, but as far as the
voice assistant can tell it's always been there and nothing has changed.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updated aria attributes
- Added observer with an observer
We had to do this with a mutation observer and state because it's
important in some frameworks, like Angular, that state changes to cause
a re-render. This, combined with some minor aria changes, makes it so
that when a field is declared invalid, it immediately announces the
invalid state instead of waiting for the user to go back to the invalid
field.
## 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/docs/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. -->
[Preview](https://ionic-framework-git-fw-6797-ionic1.vercel.app/src/components/select/test/validation/)
Issue number: resolves#25326
---------
<!-- 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 header flickers upon page transition when on iOS mode and using a
condensed header:
**Entering Page Two (P1 → P2):**
When navigating to Page Two, which has a collapsing header (intended to
be hidden until scroll), the header briefly flashes into view. This
happens because the header is initially rendered with full `opacity: 1`
before the component's logic can apply `opacity: 0` to hide it, causing
a visible flicker.
**Navigating Back (P2 → P1):**
When navigating back, Page One's header briefly bleeds through the top
of Page Two. Although Page Two is on top (`z−index: 100`), its
collapsing header is set to `opacity: 0`. This transparency allows Page
One header (`z−index: 99`) to become visible underneath, as the
transparent area cannot block the content below it.
The header flickers upon page transition when on iOS mode and using a
fade header:
**Entering Page Two (P1 → P2):**
When navigating to Page Two, which has a fade header (should not have a
background on load), the header background briefly flashes into view.
This happens because the header is initially rendered with full
`opacity: 1` before the component's logic can apply `opacity: 0` to hide
it, causing a visible flicker.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Added a transition-specific class that is applied to the condensed
ion-header element to override its default transparency.
This guarantees the header to act as an opaque block during the page
transition, eliminating visual flickering caused by early `opacity: 0`
or the header underneath bleeding through.
- Added a transition-specific class that is applied to the fade
ion-header element to override its default opaque background.
This guarantees the header to act as a transparent block during the page
transition, eliminating visual flickering caused by default `opacity:
1`.
## 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/docs/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: `8.7.6-dev.11759524961.1cff6814`
Issue number: resolves#30611
---------
<!-- 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. -->
Currently, the way tabs are set in the tab bar abuses a bug that existed
in older versions of Stencil where children would be rendered out of the
correct order. This worked in the tab and tab bar's favor previously,
but after the fix it broke our implementation so tabs would no longer
correctly indicate the selected tab on direct navigation.
## What is the new behavior?
We had a temporary fix before we knew what actually caused this issue
before, which was basically just a timeout. That blindly worked because
it triggered after the child was fully rendered. This change embraces
the new, and correct, way these components render and triggers tab
updates 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/docs/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. -->
Current dev build:
```
8.7.6-dev.11759345401.165fca78
```
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#30684
---------
<!-- 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. -->
Recently, we [fixed some issues with aria-hidden in
modals](https://github.com/ionic-team/ionic-framework/pull/30563),
unfortunately at this time we neglected modals that opt out of focus
trapping. As a result, a lot of modals that disable focus trapping still
have it happening and it doesn't get cleaned up properly on dismiss.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
We're now properly checking for and skipping focus traps on modals that
do not want them.
## 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/docs/CONTRIBUTING.md#footer
for more information.
-->
## Other information
I created regression tests for Angular in this to prevent this from
happening again. I initially tried to do this with core, but the issue
doesn't seem to reproduce with core.
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Current dev build:
```
8.7.5-dev.11758652700.103435a3
```
