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. -->
Several tests for this component are still using Playwright's old
`toMatchSnapshot` assertion. It's now recommended to use the newer
`toHaveScreenshot` assertion. This new assertion reduces the size of
each screenshot and brings anti-flake improvements such as disabling
animations by default.
We previously migrated most of our codebase to use `toHaveScreenshot`,
but it looks like we missed the tests that were written during the
development of Ionic 7 in a separate branch off `main`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Migrate component tests to use `toHaveScreenshot`.
Note: There should be no layout changes to any of the screenshots. The
only difference between the old and new screenshots should be image and
file size.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: 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: 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 two problems with this test:
1. The screenshots are not capturing the correct UI. For example, the
following screenshot should capture the date and time grid picker, but
it's only capturing the year wheel picker:
8ab3476ac7/core/src/components/datetime/test/presentation/datetime.e2e.ts-snapshots/datetime-presentation-date-time-diff-ios-rtl-Mobile-Safari-linux.png
2. These screenshots are flaky. This is possibly due to how they were
written where they iterate through an array, select a value from the
`select`, and then wait a timeout for the view to change.
3. I also discovered that we'll have some visual diffs once 2024 hits.
The current value of the datetime on the wheel picker is 2022. 2023 is
shown, but 2024 is not (since we are still in 2023). Once Jan 1 2024
hits, these tests will likely start to fail with visual diffs.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Refactored these tests to use a test fixture where each presentation
is a separate test. This ensures that the tests are correct. Because
there is less interaction going on with the page (i.e. the correct
presentation is set on load), my hope is that this also reduces test
flakiness.
- Also changed the date used to be several years ago so we don't have
new years showing up in the wheel picker screenshots as time goes on.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: 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: 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. -->
Several tests for this component are still using Playwright's old
`toMatchSnapshot` assertion. It's now recommended to use the newer
`toHaveScreenshot` assertion. This new assertion reduces the size of
each screenshot and brings anti-flake improvements such as disabling
animations by default.
We previously migrated most of our codebase to use `toHaveScreenshot`,
but it looks like we missed the tests that were written during the
development of Ionic 7 in a separate branch off `main`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Migrate component tests to use `toHaveScreenshot`.
Note: There should be no layout changes to any of the screenshots. The
only difference between the old and new screenshots should be image and
file size.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: N/A
---------
<!-- Please 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 for this component are still using Playwright's old
`toMatchSnapshot` assertion. It's now recommended to use the newer
`toHaveScreenshot` assertion. This new assertion reduces the size of
each screenshot and brings anti-flake improvements such as disabling
animations by default.
We previously migrated most of our codebase to use `toHaveScreenshot`,
but it looks like we missed the tests that were written during the
development of Ionic 7 in a separate branch off `main`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Migrate component tests to use `toHaveScreenshot`.
Note: There should be no layout changes to any of the screenshots. The
only difference between the old and new screenshots should be image and
file size.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: N/A
---------
<!-- Please 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. -->
That particular test is flaky. When going to try and fix the flakiness,
I realized that this behavior is already tested by another test. This
test presents the `ion-picker-internal` components which are also tested
in
7c2b6aed05/core/src/components/datetime/test/custom/datetime.e2e.ts (L10).
These show the same components which have the same APIs, so this test
shouldn't even be needed.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed the duplicate 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. -->
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. -->
Several tests for this component are still using Playwright's old
`toMatchSnapshot` assertion. It's now recommended to use the newer
`toHaveScreenshot` assertion. This new assertion reduces the size of
each screenshot and brings anti-flake improvements such as disabling
animations by default.
We previously migrated most of our codebase to use `toHaveScreenshot`,
but it looks like we missed the tests that were written during the
development of Ionic 7 in a separate branch off `main`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Migrate component tests to use `toHaveScreenshot`.
Note: There should be no layout changes to any of the screenshots. The
only difference between the old and new screenshots should be image and
file size.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: N/A
---------
<!-- Please 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 for this component are still using Playwright's old
`toMatchSnapshot` assertion. It's now recommended to use the newer
`toHaveScreenshot` assertion. This new assertion reduces the size of
each screenshot and brings anti-flake improvements such as disabling
animations by default.
We previously migrated most of our codebase to use `toHaveScreenshot`,
but it looks like we missed the tests that were written during the
development of Ionic 7 in a separate branch off `main`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Migrate component tests to use `toHaveScreenshot`.
Note: There should be no layout changes to any of the screenshots. The
only difference between the old and new screenshots should be image and
file size.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: N/A
---------
<!-- Please 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 for this component are still using Playwright's old
`toMatchSnapshot` assertion. It's now recommended to use the newer
`toHaveScreenshot` assertion. This new assertion reduces the size of
each screenshot and brings anti-flake improvements such as disabling
animations by default.
We previously migrated most of our codebase to use `toHaveScreenshot`,
but it looks like we missed the tests that were written during the
development of Ionic 7 in a separate branch off `main`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Migrate component tests to use `toHaveScreenshot`.
Note: There should be no layout changes to any of the screenshots. The
only difference between the old and new screenshots should be image and
file size.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: N/A
---------
<!-- Please 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 for this component are still using Playwright's old
`toMatchSnapshot` assertion. It's now recommended to use the newer
`toHaveScreenshot` assertion. This new assertion reduces the size of
each screenshot and brings anti-flake improvements such as disabling
animations by default.
We previously migrated most of our codebase to use `toHaveScreenshot`,
but it looks like we missed the tests that were written during the
development of Ionic 7 in a separate branch off `main`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Migrate component tests to use `toHaveScreenshot`.
Note: There should be no layout changes to any of the screenshots. The
only difference between the old and new screenshots should be image and
file size.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: N/A
---------
<!-- Please 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 `text-wrap` attribute was removed in Ionic v5, but references to it
still exist in the `ion-label` stylesheets.
https://github.com/ionic-team/ionic-framework/blob/main/BREAKING_ARCHIVE/v5.md#css-utilities
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed references to the unsupported `text-wrap` attributed.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
Note: This is not a breaking change because support for `text-wrap` was
removed in Ionic v5.
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
<!-- Please 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. -->
Router outlet files can be hard to find when searching for them.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Router outlet files are named what you'd expect.
## 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#28041
---------
<!-- 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. -->
`parseDate` returns `undefined` when given an invalid value. However,
our min/max processing functions did not account for this. As a result,
we would attempt to destructure an undefined value which resulted in an
error.
Note regarding linked issue: The developer is calling
`setMin(undefined)`. However, this is triggering a React quirk with
Custom Elements where `undefined` is being set to `null` inside of
React. The type signature on min/max is `string | undefined`, so `null`
is being treated as an invalid date value.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Min/Max processing functions now return `undefined` if the input was
invalid.
## 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.11692887667.1614d10a`
Issue number: resolves#28030
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
`ion-menu` registers itself with the menu controller when
`connectedCallback` fires and then unregisters itself when
`disconnectedCallback` fires. When the menu was removed from the DOM,
`disconnectedCallback` was not always being fired due to
https://github.com/ionic-team/stencil/issues/4070.
`ion-menu-button` checks to see if it should be visible by grabbing the
current menu in
314055cf7a/core/src/components/menu-button/menu-button.tsx (L74).
Since `disconnectedCallback` was not being fired, `ion-menu-button`
would still find the menu even when it was no longer in the DOM. In this
case, the menu was not being unregistered due to `disconnectedCallback`
not firing.
When the linked Stencil bug was resolved in Stencil 4.0.3, the menu
button started to disappear. This is happening because
`disconnectedCallback` is now correctly called when the menu is removed
from the DOM. Since `disconnectedCallback` is called, the menu is
un-registered from the menu controller, and the menu button can no
longer find it.
However, this revealed a long-standing bug where re-adding the menu
would not fire `ionMenuChange` again. As a result, the menu button
remained hidden.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The menu now fires `ionMenuChange` on `connectedCallback` as long as
`componentDidLoad` has already been run.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.3.2-dev.11692803611.15c1bc87`
---------
Co-authored-by: Sean Perkins <sean@ionic.io>
Issue number: Resolves#26391
---------
<!-- 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 updating the `value` programmatically on an `ion-datetime` after it
has already been created:
- With grid style: The selected date visually updates, but the calendar
does not scroll to the newly selected month.
- With wheel style: The selected date does not visually update, i.e. the
wheels do not move to show the newly selected date.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Grid style datetimes now scroll to the selected date using the same
animation as when clicking the next/prev month buttons.
- This animation mirrors the behavior in both MUI and native iOS. See
the [design
doc](https://github.com/ionic-team/ionic-framework-design-documents/blob/main/projects/ionic-framework/components/datetime/0003-datetime-async-value.md)
for more information and screen recordings.
- The animation will not occur if the month/year did not change, or when
the datetime is hidden.
- Wheel style datetimes now visually update to the selected date. No
animation occurs, also mirroring native.
- The `parseDate` util has also had its type signatures updated to
account for returning `undefined` when the date string is improperly
formatted. This was missed when the util was refactored to support
multiple date selection.
## 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. -->
- Docs PR: https://github.com/ionic-team/ionic-docs/pull/3053
- While this can technically be considered a bug fix, we are merging it
into a feature branch for safety; it's a fairly significant change to
how datetime behaves, and may interfere with custom logic when updating
a datetime's value async.
- Jumping to the newly selected value is handled by replacing everything
[here](https://github.com/ionic-team/ionic-framework/pull/27806/files#diff-4a407530c60e3cf72bcc11acdd21c4803a94bf47ea81b99e757db1c93d2735b8L364-L407)
with `processValue()`. This covers both wheel and grid datetimes.
- `activePartsClone` as a whole was also removed. It was added in
https://github.com/ionic-team/ionic-framework/pull/24244 to enable
changing `activeParts` without triggering a rerender (and thus jumping
to the new value) but since we now want to do that jump, the clone is no
longer needed.
- The animation code might be tricky to follow, so I recorded going
through it:
https://github.com/ionic-team/ionic-framework/assets/90629384/1afa5762-f493-441a-b662-f0429f2d86a7
## What is the current behavior?
There is no description of how to set the value of a picker.
## What is the new behavior?
Readers can find this description in the documentation.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
---------
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: resolves#27746
---------
<!-- 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. -->
Pressing the Tab key when focused on an input/textarea with
`clearOnEdit` clears the text field and then moves focus to the next
focusable element.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Pressing the Tab key does not clear the text field even when
clearOnEdit is enabled.
- Added test coverage
- I also noticed that input did not have an `index.html` file in the
basic directory, so I added that.
## 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.1-dev.11692202566.13cd16c4`
As part of our incident learning review, the team would like to add
better documentation as to the purpose of `renderHiddenButton` for
future reference.
Issue number: multiple internals
---------
<!-- 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. -->
Multiple tests that use gestures are flaky on GitHub. Due to that those
tests are being skipped.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `page.mouse.move` will not work as expected if it the mouse moves
outside of the viewport. This may lead to events to not fire every time.
There's now a check to determine if the coordinates are valid. If they
are not, then it will update the coordinates to be as close to the
viewport's edge instead of being outside.
- Safari doesn't repaint the frame as often as the other browsers. This
causes the tests on GitHub to appear to be lagging. Now the frame is
forced to repaint only for Safari.
- Most tests are no longer being skipped.
- Range is still having issues on GitHub. It is no longer flaky locally
with the changes in this PR. I've had to revert them back to skip until
further notice.
## 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. -->
If this PR is merged, then:
- FW-3006, FW-2795, and FW-3079 can be closed
- FW-4556 still needs to remain open since range is still flaky on
GitHub
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
There was some confusion on
https://github.com/ionic-team/ionic-framework/issues/27985 as to how the
`--highlight-*` variables on `ion-item` apply to the modern form
controls. These variables only work with the legacy form syntax, but we
did not add a proper deprecation message.
`--highlight-*` variables have been added to `ion-input` and
`ion-textarea` instead so developers can customize the highlight when
using the modern form syntax.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Deprecated the `--highlight-*` variables on `ion-item`.
## 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. -->
Bumps [@playwright/test](https://github.com/Microsoft/playwright) from
1.36.2 to 1.37.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/Microsoft/playwright/releases"><code>@playwright/test</code>'s
releases</a>.</em></p>
<blockquote>
<h2>v1.37.0</h2>
<h2>✨ New tool to merge reports</h2>
<p>If you run tests on multiple shards, you can now merge all reports in
a single HTML report (or any other report)
using the new <code>merge-reports</code> CLI tool.</p>
<p>Using <code>merge-reports</code> tool requires the following
steps:</p>
<ol>
<li>
<p>Adding a new "blob" reporter to the config when running on
CI:</p>
<pre lang="js"
data-meta="title="playwright.config.ts""><code>export default
defineConfig({
testDir: './tests',
reporter: process.env.CI ? 'blob' : 'html',
});
</code></pre>
<p>The "blob" reporter will produce ".zip" files
that contain all the information
about the test run.</p>
</li>
<li>
<p>Copying all "blob" reports in a single shared location and
running <code>npx playwright merge-reports</code>:</p>
<pre lang="bash"><code>npx playwright merge-reports --reporter html
./all-blob-reports
</code></pre>
</li>
</ol>
<p>Read more in <a href="https://playwright.dev/docs/test-sharding">our
documentation</a>.</p>
<h2>📚 Debian 12 Bookworm Support</h2>
<p>Playwright now supports Debian 12 Bookworm on both x86_64 and arm64
for Chromium, Firefox and WebKit.
Let us know if you encounter any issues!</p>
<p>Linux support looks like this:</p>
<table>
<thead>
<tr>
<th align="left"></th>
<th align="center">Ubuntu 20.04</th>
<th align="center">Ubuntu 22.04</th>
<th align="center">Debian 11</th>
<th align="center">Debian 12</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">Chromium</td>
<td align="center">✅</td>
<td align="center">✅</td>
<td align="center">✅</td>
<td align="center">✅</td>
</tr>
<tr>
<td align="left">WebKit</td>
<td align="center">✅</td>
<td align="center">✅</td>
<td align="center">✅</td>
<td align="center">✅</td>
</tr>
<tr>
<td align="left">Firefox</td>
<td align="center">✅</td>
<td align="center">✅</td>
<td align="center">✅</td>
<td align="center">✅</td>
</tr>
</tbody>
</table>
<h2>🌈 UI Mode Updates</h2>
<ul>
<li>UI Mode now respects project dependencies. You can control which
dependencies to respect by checking/unchecking them in a projects
list.</li>
<li>Console logs from the test are now displayed in the Console
tab.</li>
</ul>
<h2>Browser Versions</h2>
<ul>
<li>Chromium 116.0.5845.82</li>
<li>Mozilla Firefox 115.0</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="2c9e02a800"><code>2c9e02a</code></a>
chore: mark 1.37.0 (<a
href="https://redirect.github.com/Microsoft/playwright/issues/26410">#26410</a>)</li>
<li><a
href="37ba0b657d"><code>37ba0b6</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/26411">#26411</a>):
docs: add release notes for js v1.37</li>
<li><a
href="9a5172e6c1"><code>9a5172e</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/26413">#26413</a>):
fix(merge): allow reports with same name as input (<a
href="https://redirect.github.com/Microsoft/playwright/issues/26417">#26417</a>)</li>
<li><a
href="eed73de573"><code>eed73de</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/26400">#26400</a>):
feat(chromium): roll to r1076 (<a
href="https://redirect.github.com/Microsoft/playwright/issues/26403">#26403</a>)</li>
<li><a
href="7999841a19"><code>7999841</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/26390">#26390</a>):
chore: allow merging defineConfig</li>
<li><a
href="56b22fa0b1"><code>56b22fa</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/26380">#26380</a>):
devops(merge): authorize service principal by us… (<a
href="https://redirect.github.com/Microsoft/playwright/issues/26384">#26384</a>)</li>
<li><a
href="421bffb7d7"><code>421bffb</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/26382">#26382</a>):
docs(merge): use azcopy for uploads (<a
href="https://redirect.github.com/Microsoft/playwright/issues/26383">#26383</a>)</li>
<li><a
href="ff0aef37f8"><code>ff0aef3</code></a>
devops: use azcopy for better upload performance (<a
href="https://redirect.github.com/Microsoft/playwright/issues/26360">#26360</a>)</li>
<li><a
href="65ac0d5256"><code>65ac0d5</code></a>
chore: add k8s grid deployments (<a
href="https://redirect.github.com/Microsoft/playwright/issues/26359">#26359</a>)</li>
<li><a
href="ffd6cf60eb"><code>ffd6cf6</code></a>
fix: eliminate race in compilation cache (<a
href="https://redirect.github.com/Microsoft/playwright/issues/26353">#26353</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/Microsoft/playwright/compare/v1.36.2...v1.37.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#27966
---------
<!-- 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 large title on iOS added bottom padding to create space between the
title and the main content. However, this caused tall text to be cut off
on the top.
During development I also noticed that the padding value we were using
does not match the iOS spec.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The padding is now applied to the toolbar that contains the large
title. The title itself is positioned absolutely so adding
padding/margin to it never actually had the desired effect. What we want
is space between the title and any content in sibling toolbars. All the
padding on the title did was shift content within the title up to give
the impression of space between the title and other content.
- Adjusted the actual padding values to align with the iOS spec
Note: The screenshot diffs here are correct. By adding padding to the
toolbar we are increasing the height of the toolbar by 6px. As noted
above, we never truly had spacing between the large title and the
content since the text inside of the title was just being shifted by 6px
to give the impression of spacing.
Additionally, the padding values were further adjusted to match the iOS
spec:
| native | ionic | diff |
| - | - | - |
|
|
|
|
- [ ] 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.2.4-dev.11691683954.1b6ed4bb`
---------
Co-authored-by: ionitron <hi@ionicframework.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. -->
While working on getting our starter app tests running on CI, I ran into
the following error:
```
⎯⎯⎯⎯ Unhandled Rejection ⎯⎯⎯⎯⎯
ReferenceError: document is not defined
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
❯ Module.startTapClick node_modules/@ionic/core/components/index9.js:133:15
131| };
132| const doc = document;
133| doc.addEventListener('ionGestureCaptured', cancelActive);
| ^
134| doc.addEventListener('touchstart', onTouchStart, true);
135| doc.addEventListener('touchcancel', onTouchEnd, true);
❯ node_modules/@ionic/core/components/ion-app.js:21:113
This error originated in "src/App.test.tsx" test file. It doesn't mean the error was thrown inside the file itself, but while it was running.
This error was caught after test environment was torn down. Make sure to cancel any running tasks before test finishes:
```
We are referencing `document` without any "document defined" checks.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Tap Click is only enabled if the `document` is available since we set
event listeners on the document.
## 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#27945
---------
<!-- 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` accepts a `size` attribute that implies that it will
effect the size of the input under certain rules. This is not the case.
The `size` attribute has no effect on the size of the `input` element
since Ionic sets the input width to 100%.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removes the documentation around the `size` attribute so that it will
be removed from the Ionic Docs
- Adds a task link to remove the `size` attribute in an upcoming major
release
## 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#27952
---------
<!-- 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 hidden button in `ion-button` that is responsible for submitting the
form does not get added when the `form` property is set async.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `ion-button` now checks to see if it needs to render a hidden button
whenever it re-renders. This allows it to account for changes to the
`type` property, `form` property, etc.
Since this code can potentially run multiple times I added an extra
check so we don't add multiple buttons to the form.
## 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.2.3-dev.11691523847.1760ab58`
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. -->
`ion-datetime` has a state variable `isPresented`, which is never set
and goes unused except to add a CSS class (also unused).
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
State variable and class removed.
## 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#27913
---------
<!-- 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 determining what the changed month is, we grab the element at the
center of the datetime and then grab the nearest calendar month. This
works fine if the datetime is fully in view, but if the center point is
out of the viewport then this will return `null`. As a result, scrolling
in the datetime will break.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- We now check scroll position instead of querying for DOM elements at
coordinates. This allows the view to continue to update even if the
entire calendar body is outside the viewport.
## 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.2.2-dev.11690996559.1019674a`
Issue number: resolves#27928
---------
<!-- 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. -->
Action sheet, alert, picker, and toast did not have logic where the
overlay presents if `isOpen="true"` on load. Modal, popover, and loading
had this logic but did not have test coverage.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updated action sheet, alert, picker, and toast to present if
`isOpen="true"` on load
- Added test coverage to all overlays for this functionality.
## 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.2.3-dev.11691156718.1638345c`
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: resolves#27910
---------
<!-- 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 an edge case in our `ion-item-sliding` code where options can
be added after the `querySelectorAll` has been run in `updateOptions`
but before `watchForOptions` has been called which causes us to miss the
newly created options. These options can never be shown as a result.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `watchForOptions` is called before the initial `updateOptions` call so
that we can re-run `updateOptions` in the event that options are added
while that first call is running.
## 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.2.2-dev.11690983626.19a2a8cb`
Issue number: resolves#27893
---------
<!-- 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 is another instance of
https://github.com/ionic-team/ionic-framework/issues/22895. The
`progressCallback` function is fires asynchronously, so it's possible
for the gesture start and end callbacks to run before the animation is
ever set in `progressCallback`. When this happens, the animation gets
locked up.
I previously fixed this in
https://github.com/ionic-team/ionic-framework/pull/23527 for
`ion-router-outlet`, but I did not fix it for `ion-nav`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- If the gesture has ended by the time `progressCallback` fires, reset
the animation to the beginning so it does not get locked up.
## 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.2.2-dev.11690896715.12338339`
Issue number: resolves#27071, resolves#27786
---------
<!-- 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-select-popover` is using the legacy syntax for `ion-checkbox` and
`ion-radio`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Migrated checkbox and radio to use the modern syntax
- Updated the visual rendering tests to also check the checked state. I
noticed during development that I accidentally broke the checked state,
so I added tests so we can't accidentally break it again.
A couple notes on other screenshot diffs:
- On iOS, the item border line now extends past the radio circle. This
is an intentional behavior and aligns with native iOS. Having the radio
in the "start" slot is typically only done when the content in the
default slot is another interactive element (like and input) and not a
text label.
- On MD, the control heights are smaller. When comparing with
https://material-components.github.io/material-components-web-catalog/#/component/select,
the new behavior seems to be correct. Both the spec and Ionic item
heights are 48px. Interestingly, the radios in `ion-select-popover` have
always been 48px tall, but the checkboxes were 54px. Now both the radios
and checkboxes are 48px.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: amandaejohnston <amandaejohnston@users.noreply.github.com>
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#17269
---------
<!-- 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. -->
Long radio and checkbox labels truncate with ellipsis instead of
wrapping to the next line. This makes the label hard to understand
because users cannot read the entire label.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Labels now wrap to the next line instead of truncating.
Note: Some of the screenshots may show wider alerts than before. This is
the correct behavior. When rendering text, the browser will try to
render as much text on a single line as it can. Since our alerts can
expand in width, the alert wrapper will expand in width (up to the max
width) to accommodate this text. Once the the wrapper is at the max
width, text will then wrap to the next line.
For example, you may notice the MD alert increasing to 280px in width:
b8553d89f8/core/src/components/alert/alert.md.vars.scss (L11).
There should be no visual diff for alerts with text that would not
normally wrap to the next line.
This was not happening before because we did not allow text to wrap to
the next line.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#27812
---------
<!-- 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 currently have CSS to ensure the floating/stacked label is not
obscured by the input/textarea when using the outline styles. However,
it was discovered that this scenario can happen with any
floating/stacked label not just when the input/textarea is using the
outline style.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Floating/stacked labels appear on top of the input/textarea regardless
of fill mode.
## 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.2.1-dev.11690464203.1b2b4419`
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#27797
---------
<!-- 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. -->
Datetime Button passes a parsed value to one of the many text formatting
utilities we have, such as `getMonthAndYear`. However, developers can
pass partial date values such as `2022` or `2022-04` (April 2022).
According to
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#date_time_string_format,
these are still valid date strings.
However, the `parseDate` utility does not add fallback values. So
passing `2022` will cause the `day` and `month` fields to be
`undefined`. This means that `getNormalizedDate` passes `'//2022'` to
the `Date` constructor.
Some browsers, such as Chrome, will automatically account for the stray
slashes and still return a valid date. Other browsers, such as Safari,
do not do this and will either return "Invalid Date" or throw an error.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Date normalizing utility now has fallback values so we always pass in
a valid date. In the example above, `getNormalizedDate` will now pass
`'1/1/2022'` instead of `'//2022'` to the `Date` constructor.
- Refactored other utils that use `new Date` to make use of
`getNormalizedDate` since they are also impacted.
Note: I added an E2E test instead of a spec test because I want to test
cross-browser behavior to ensure consistency.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
## What is the current behavior?
Buttons containing only icons are not accessible as there is no way to
pass an `aria-label` attribute (or any other html attribute).
## What is the new behavior?
- Adds the `htmlAttributes` property on the `AlertButton` interface
- Passes the `htmlAttributes` to the buttons
- Adds a test to verify `aria-label` and `aria-labelled-by` are passed
to the button
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
Issue number: N/A
---------
## What is the current behavior?
Buttons containing only icons are not accessible as there is no way to
pass an `aria-label` attribute (or any other html attribute).
## What is the new behavior?
- Adds the `htmlAttributes` property on the `ActionSheetButton`
interface
- Passes the `htmlAttributes` to the buttons (both the buttons array and
the cancelButton)
- Adds two tests to verify `aria-label` and `aria-labelled-by` are
passed to a button with and without the cancel role - this was done
because action sheet breaks these buttons up when rendering
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
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. -->
See: https://github.com/ionic-team/ionic-framework/issues/27877
The current description does not accurately describe what `size="auto"`
does.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Description clarifies that the width of the popover is set based on
platform defaults.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
## What is the current behavior?
Buttons containing only icons are not accessible as there is no way to
pass an `aria-label` attribute (or any other html attribute).
## What is the new behavior?
- Adds the `htmlAttributes` property on the `ToastButton` interface
- Passes the `htmlAttributes` to the buttons
- Adds a test to verify `aria-label` and `aria-labelled-by` are passed
to the button
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
Issue number: resolves#27438
---------
<!-- 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 a few issues with the modern radio syntax:
1. The native radio is inside the Shadow DOM. As a result, radios are
not announced with their parent group with screen readers (i.e. "1 of
3")
2. The native radio cannot be focused inside of `ion-select-popover` on
Firefox.
3. The `ionFocus` and `ionBlur` events do not fire.
I also discovered an issue with item:
1. Items inside of a Radio Group have a role of `listitem` which prevent
radios from being grouped correctly in some browsers. According to
https://bugzilla.mozilla.org/show_bug.cgi?id=1840916, browsers are
behaving correctly here. The `listitem` role should not be present when
an item is used in a radio group (even if the radio group itself is
inside a list).
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Most of the changes are test-related, but I broke it down per commit to
make this easier to review:
ae77002afd
- Item no longer has `role="listitem"` when used inside of a radio
group.
- Added spec tests to verify the role behavior
0a9b7fb91d
- I discovered that some the legacy basic test were accidentally using
the modern syntax. I corrected this by adding `legacy="true"` to the
radios.
a8a90e53b2,
412d1d54e7,
and
1d1179b69a
- The current radio group tests only tested the legacy radio syntax, and
not the modern syntax.
- I created a `legacy` directory to house the legacy syntax tests.
- I created new tests in the root test directory for the modern syntax.
- I also deleted the screenshots for the modern tests here because the
tests for `ion-radio` already take screenshots of the radio (even in an
item).
e2c966e68b
- Moved radio roles to the host. This allows Firefox to focus radios and
for screen readers to announce the radios as part of a group.
- I also added focus/blur listeners so ionFocus and ionBlur fire
f10eff47a5
- I cleaned up the tests here to use a common radio fixture
## 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 tested this with the following setups. ✅ indicates the screen reader
announces the group count (i.e. "1 of 4"). ❌ indicates the screen reader
does not announce the group count.
**Radio in Radio Group:**
- iOS + VoiceOver: ✅
- Android + TalkBack: ✅
- macOS + VoiceOver + Safari: ✅
- macOS + VoiceOver + Firefox: ✅
- macOS + VoiceOver + Chrome: ✅
- Windows + NVDA + Chrome: ✅
- Windows + NVDA + Firefox: ✅
**Radio in Item in Radio Group :**
- iOS + VoiceOver: ✅
- Android + TalkBack: ❌
(https://bugs.chromium.org/p/chromium/issues/detail?id=1459006)
- macOS + VoiceOver + Safari: ✅
- macOS + VoiceOver + Firefox: ✅
- macOS + VoiceOver + Chrome: ❌
(https://bugs.chromium.org/p/chromium/issues/detail?id=1459003)
- Windows + NVDA + Chrome: ✅
- Windows + NVDA + Firefox: ✅
Issue number: resolves#27830
---------
<!-- 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. -->
Card modals set the body background to `black` to match iOS. This color
should be removed once the final card modal has been closed. When modals
were updated to work inline, the code that removed the background color
was never updated to account for this. As a result, opening multiple
inline card modals never removes the background color because there are
always >1 modals in the DOM.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The card modal now queries for _visible_ modals in the DOM to
determine if it should remove the background color.
## 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.2.1-dev.11689879279.14e28634`
