Issue number: internal
---------
## What is the current behavior?
- `LogLevel` throws error `Error: Cannot access ambient const enums when
'isolatedModules' is enabled`
- Several existing console warns and errors are not calling the function
that respects the `logLevel` config
## What is the new behavior?
- Remove `const` from the `enum` to work with `isolatedModules`
- Update `console.warn`s to `printIonWarning`
- Update `console.error`s to `printIonError`
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
## Other information
Dev build: `8.5.5-dev.11744729748.174bf7e0`
---------
Co-authored-by: Brandy Smith <6577830+brandyscarney@users.noreply.github.com>
Issue number: resolves#29712
---------
<!-- 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?
In every type of overlay, the auto incremented overlay id is overwriting
any id set in htmlAttributes.
## What is the new behavior?
The id in htmlAttributes now takes precedence.
## 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. -->
---------
Co-authored-by: Sean Perkins <13732623+sean-perkins@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. -->
Modal inherits `aria-label` and `role` to an element inside of its
Shadow DOM. However, this only works if developers set the attributes on
the host element directly. Setting the attributes via the
`htmlAttributes` property causes the attributes to be set on the host
and not inherited.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `aria-label` and `role` are inherited even when set using
`htmlAttributes`.
## 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.4-dev.11709154993.1b49c313`
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: 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: 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 https://github.com/ionic-team/ionic-framework/issues/28694 there was
some confusion around how to access `this` inside of a callback function
passed to a property on Ionic components. The root issue was due to how
the `this` context is determined with developers being responsible for
setting the appropriate `this` context.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- While this isn't an Ionic bug, I think it's worth calling out this
behavior so developers are aware of how to account for it.
## 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. -->
Note: The link in the docs will not work until
https://github.com/ionic-team/ionic-docs/pull/3333 is merged.
---------
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
Issue number: resolves#28524
---------
<!-- 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. -->
Watchers in Stencil are constructed sometime between `connectedCallback`
and `componentDidLoad`. If a property is set/changed during that time it
is possible for the callback associated with the watcher to not fire
because the watcher has not been setup yet. This is most often with
`dist-custom-elements` and frameworks such as Angular when using a
binding (i.e. `[trigger]` instead of `trigger`)
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The trigger callback associated with the watcher is manually called in
`componentDidLoad` for each overlay.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.5.5-dev.11699974376.13a15397`
Note: This is a timing related bug due to a behavior in Stencil, so I
did not write automated tests. However, I manually verified that this
issue a) reproduces on `main` and b) is fixed with this dev build for
each overlay component.
Issue number: resolves#28105
---------
<!-- 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 swiping to dismiss the card modal, the status bar style is reset
too late. Since we are using 1 animation for the card modal, the dismiss
animation is played _then_ the `dismiss` method is called (which resets
the status bar style). This means the status bar style is wrong for the
duration of the dismiss animation.
This does not impact dragging to close the modal such that the status
bar changes mid-gesture or calling the `dismiss` method directly -- only
quickly swiping to dismiss.
Also one of the changes in core/src/components/modal/modal.tsx
accidentally changed the modal behavior so that the status bar is
changed _after_ the present transition finishes.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- When the card modal is swiped to dismiss the `onDismiss` callback will
also reset the status bar style.
- When the card modal is presented the status bar is set correctly as
the animation begins
| `main` | branch |
| - | - |
| <video
src="https://github.com/ionic-team/ionic-framework/assets/2721089/8a18419d-a7ec-4629-8632-62e2ed401912"></video>
| <video
src="https://github.com/ionic-team/ionic-framework/assets/2721089/62ffcf00-8dbd-4e0c-83a3-5af5d463bccc"></video>
|
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.3.3-dev.11693592322.138d91e6`
Issue number: resolves#27200
---------
<!-- 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. -->
A bug occurs when you click twice quickly to open an overlay with a
small timeout. In some cases, the overlay will present, dismiss,
present, then not dismiss the second time, getting stuck open. You can
reproduce manually this by grabbing the test HTML included in this PR
and putting it in a branch that doesn't include a fix.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- When an overlay with a short timeout is triggered twice quickly, it
will open-close-open-close.
- The behavior is the same for all overlay components
## 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. -->
Relevant links:
* https://github.com/ionic-team/ionic-framework/issues/27200
* https://ionic-cloud.atlassian.net/browse/FW-4374
* https://ionic-cloud.atlassian.net/browse/FW-4053
I'm not sure how to write an automated test for this bug due to the
short timeout required.
You can manually test the fix in [this
Stackblitz](https://stackblitz.com/edit/g1kjci?file=package.json) by
changing the Ionic version between 7.3.1 and
7.3.2-dev.11693262117.17edbf6d
---------
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: resolves#27190, resolves#24780
---------
<!-- 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. -->
Popovers with dynamic widths were not being positioned correctly
relative to the trigger element. This was happening because the child
component always had dimensions of 0 x 0. Ionic has logic built-in to
wait for the child components to be rendered, but this was not working
as intended for two reasons:
1. `this.usersElement` was referencing the popover element itself not
the user’s component. When calling `deepReady` on
01fc9b4511/core/src/components/popover/popover.tsx (L477)
we are waiting for the popover to be hydrated, not the child content.
The popover was already hydrated on page load, so this resolves
immediately. However, the child content that was just added to the DOM
has not yet been hydrated, so we aren’t waiting long enough.
This is happening because we return `BaseComponent `from
`attachComponent` which is a reference to the overlay:
01fc9b4511/core/src/utils/framework-delegate.ts (L133)
Other framework delegates return the actual child content:
- Core delegate with controller:
01fc9b4511/core/src/utils/framework-delegate.ts (L35)
(this is part of why the controller popover works but the inline popover
does not)
- React delegate:
01fc9b4511/packages/react/src/framework-delegate.tsx (L31)
- Vue delegate:
01fc9b4511/packages/vue/src/framework-delegate.ts (L45)
2. `attachComponent` is unable to return the correct element currently
because the child content has not been mounted yet in this scenario.
`ionMount` is emitted after `attachComponent` resolves:
01fc9b4511/core/src/components/popover/popover.tsx (L466)
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `ionMount` is emitted before `attachComponent` runs
- `attachComponent` now consistently returns the child view if present
in the DOM
- Added a test
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.3.2-dev.11693321763.15a54694`
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#27923
---------
<!-- 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. -->
`setCurrentBreakpoint` still animates even when `animated: false`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `setCurrentBreakpoint` jumps directly to the new breakpoint when
`animated: false`
## 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. -->
Updated design doc:
https://github.com/ionic-team/ionic-framework-design-documents/pull/137
Dev build: `7.2.3-dev.11691069391.1d91d2be`
Issue number: Internal
---------
<!-- Please refer to our contributing documentation for any questions on
submitting a pull request, or let us know here if you need any help:
https://ionicframework.com/docs/building/contributing -->
<!-- Some docs updates need to be made in the `ionic-docs` repo, in a
separate PR. See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#modifying-documentation
for details. -->
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The counter for incrementing the `id` and `z-index` of an overlay is
incremented whenever the `connectedCallback` is fired for an overlay.
When an overlay is presented and/or conditionally rendered, the overlay
`id` can increment by `n+2` instead of `n+1`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Increments all overlay ids consistently
- Removes legacy `ion-modal-{id}` and `ion-popover-{id}` logic
- Adds unit tests for the id behavior
- Tests are split up into separate files so that the counter is always
starting from `0`
- Adds an integration test with the Angular test app to verify
conditional rendering behavior
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: resolves#27343
---------
<!-- Please refer to our contributing documentation for any questions on
submitting a pull request, or let us know here if you need any help:
https://ionicframework.com/docs/building/contributing -->
<!-- Some docs updates need to be made in the `ionic-docs` repo, in a
separate PR. See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#modifying-documentation
for details. -->
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
In
30e3a1485d
I removed the `deepWait` call from popover/modal in custom element
bundle environments (React and Vue as of writing). This had an
unintended side effect where WebKit/iOS would not play the modal enter
animation correctly because the inner contents are mounted
mid-animation. This does not impact other mobile platforms.
This only impacted the modal because popover had a patch in
be9a399eee
which causes it to wait for the JS Framework to finish mounting before
proceeding with the transition.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Modal now emits `ionMount` event and waits 2 frames before proceeding
with the animation.
Note 1: The JS Framework overlay components were already updated to
support this `ionMount` event in
be9a399eee.
I also updated the modal Angular component to listen for `ionMount`. It
is not needed right now because Angular does not use the custom elements
bundle and therefore does not call `ionMount` (it runs the `deepReady`
function though). However, if we move Angular to support the custom
elements bundle in the future this may become an issue. This behavior
currently exists in the popover component for Angular too.
Note 2: This does appear to be a WebKit bug since it does not happen on
Android. However, this patch seems fairly safe which is why I've opted
to try and fix it internally instead of waiting for a patch from Apple.
| before | after |
| - | - |
| <video
src="https://user-images.githubusercontent.com/2721089/235495325-2f258526-0c43-422b-84c3-ac4f5e228bbd.MP4"></video>
| <video
src="https://user-images.githubusercontent.com/2721089/235495362-9b3bb35d-782c-4a8f-ac13-8aaa8f17729b.MP4"></video>
|
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
The Ionic Framework team would like to re-evaluate our approach to improving customization options when building mobile applications. We are looking at other solutions that a) make customizing an app UI easier and b) are applicable to a broader set of developers.
BREAKING CHANGE:
`ActionSheetAttributes`, `AlertAttributes`, `AlertTextareaAttributes`, `AlertInputAttributes`, `LoadingAttributes`, `ModalAttributes`, `PickerAttributes`, `PopoverAttributes`, and `ToastAttributes` have been removed. Developers should use `{ [key: string]: any }` instead.
BREAKING CHANGE:
- The `swipeToClose` property has been removed in favor of `canDismiss`.
- The `canDismiss` property now defaults to `true` and can no longer be set to `undefined`.
