Issue number: resolves#28293
---------
<!-- 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. -->
Disabled toggles, radios, and checkboxes can still be enabled by
manually dispatching a click event on them.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Toggles, radios, and checkboxes no longer activate if `disabled` is
set to `true`
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.4.4-dev.11696545130.1171e7a9`
Issue number: resolves#20092, resolves#19676, resolves#19000
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Menu is currently throwing errors because it expects no animations to be
running when any state changes happen (such as changing `disabled` or
`swipeGesture`).
For example, if you set `swipeGesture="false"` mid-gesture then the menu
will error. Alternatively, if you set `disabled="true"` mid-open
animation then the menu will error also. This is undesirable because it
can cause visual flickering and other undesirable behaviors as noted in
the linked threads.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Any in-progress animation is cancelled if the state updates such that
the animation is no longer relevant (i.e. `disabled` is set to `true`
while the menu is opening)
- Removed relevant assertions
- Added tests
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.4.3-dev.11696264821.1755dd6a`
Issue number: resolves#27060
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The main header is controlled by the header with `collapse="condense"`
set:
a04a11be35/core/src/components/header/header.tsx (L144)
The collapse header will hide the main header and then show it once the
user has scrolled enough. However, if the main header is rendered before
the collapse header is rendered, then the main header will be visible
for a brief moment before being hidden by the collapse header. This
gives the perception of flicker that is reported on the linked issue.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The main header will be hidden on load if it loads before the collapse
header
The selector was written in a way such that once the collapse header
loads, this CSS no longer applies (since the collapse header will add
`.header-collapse-main` to the main header)
| `main` | branch |
| - | - |
| <video
src="https://github.com/ionic-team/ionic-framework/assets/2721089/3cb11a57-e084-435a-89c2-e1c2afba04b1"></video>
| <video
src="https://github.com/ionic-team/ionic-framework/assets/2721089/c5caeb5e-3b33-4598-986f-bf097c46251c"></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. -->
Note: `:has` browser compat is still fairly new. However, it is
available on both Chromium and WebKit browsers (and has been for at
least a year): https://caniuse.com/?search=%3Ahas
Given that this bug is a fairly minor UI glitch (as opposed to something
that would cause an app to crash or otherwise malfunction), I think this
is an acceptable tradeoff. As time goes on this will become less of a
concern as more users update their devices.
Dev build: `7.4.3-dev.11696365694.156f41d3`
Issue number: resolves#17676
---------
<!-- 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 IonNav, IonRouterOutlet, and .ion-page elements have `overflow:
hidden` which prevent content from spilling out of it. This was likely
done to prevent these elements from having overflow scroll (since the
inner IonContent should be scrollable). However, this breaks the
translucency effect on IonTabBar because the content in IonContent can
not scroll under the IonTabBar.
```html
<ion-tabs>
<ion-router-outlet> <!-- this has overflow: hidden -->
...
<ion-content fullscreen="true">...</ion-content>
</ion-router-outlet>
<ion-tab-bar translucent="true">...</ion-tab-bar>
</ion-tabs>
```
In Ionic v3 components such as IonTabs and IonNav did have `overflow:
hidden`:
cf35d5eb7f/src/components/app/app.scss (L241-L246)
However, components like IonNav were not used inside of tabs at the
time, so the reported bug was not a problem then.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed `overflow: hidden` from IonNav, IonRouterOutlet, and
.ion-page. This change seems safe to make because the `position:
absolute` and top/right/bottom/left values should ensure that these
elements take up the available screen space and avoid having overflow
scrolling.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.4.2-dev.11695832397.13fa6703`
Note: Fixing this reveals
https://github.com/ionic-team/ionic-framework/issues/21130 which is why
this fix is dependent on the linked issue getting fixed first.
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#17499
---------
<!-- 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, there isn't a way to position toasts such that they don't
overlap navigation elements such as headers, footers, and FABs.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Added the new `positionAnchor` property, which specifies an element that
the toast's position should be anchored to.
While the name can be tweaked, we should take care to keep the relation
between it and the `position` property clear. The `position` acts as a
sort of "origin" point, and the toast is moved from there to sit near
the chosen anchor element. This is important because it helps clarify
why the toast sits above the anchor for `position="bottom"` and vice
versa.
I chose not to rename the `position` prop itself to avoid breaking
changes.
Docs PR: https://github.com/ionic-team/ionic-docs/pull/3158
## 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>
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: resolves#21130
---------
<!-- 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. -->
IonContent sets `--offset-top` and `--offset-bottom` variables to allow
the content to scroll under headers, footers, and tab bars. This is
essential to creating the translucency effect on these components.
IonContent does this by computing its offsetHeight and offsetTop
coordinates which take into account the dimensions of headers, footers,
and tab bars. Occasionally, this code will run before the IonTabBar has
been hydrated which means that the offset will be wrong because the
IonTabBar will have a dimension of 0x0 prior to hydration.
This impacts Ionic Angular devs who are using the lazy loaded build of
Ionic. React and Vue devs are not impacted because they are using the
dist-custom-elements build of Ionic which does not have hydration.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- IonContent will re-run the offset computation code whenever the
`ionTabBarLoaded` event is emitted. This event is emitted at most once
per IonTabBar instance.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.4.2-dev.11695831341.191bdf12`
Note: I did not write a test since this is fixing a race condition. I
wasn't able to find a non-flaky way of testing this. You can test this
in an Ionic Angular Tabs starter application with the dev build. The
`--offset-bottom` variable on `ion-content` should be large enough such
that the content will scroll under the tab bar. The translucency effect
won't work just yet, but that is being fixed in
https://github.com/ionic-team/ionic-framework/pull/28246.
Issue number: resolves#28096
---------
<!-- 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 a segment button is clicked, the segment will auto-scroll to
position the newly active button fully in view. However, this behavior
does not occur on first load. This means that when a segment is
initialized with a `value` corresponding to an off-screen button, the
button will remain off-screen.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
The same auto-scroll behavior from button click now also occurs on
component load.
## 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: 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. -->
Code is duplicated between the router outlet and the overlays
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Code is reused between the router outlet and the overlays
## 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#25444
---------
<!-- 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 the custom elements build, currently used by React and Vue packages,
the range knob can be rendered incorrectly if the value is assigned
after the `connectedCallback` but before the initial render of the
component. This is most apparent with the dual knobs implementation in
React (referenced issue).
This results in the range's value being correct, but the visual
representation of the range to be incorrect.
This also causes issues with the custom elements build in the standalone
implementation of Ionic's components in Angular. If a range is presented
in a modal via a controller, the range will never render with the value
that is initially assigned to it.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updates the range knob positioning when the range has initially
rendered.
## 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. -->
This change needs to be pulled into the Ionic angular standalone work.
Dev-build: `7.4.3-dev.11695926109.13b1266a`
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 `getSnapshotSettings` method was used in the pre-generator test
infrastructure. It was deprecated at the start of the generator
migration.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Now that the generator migration is complete, this method is no longer
needed. As a result, I removed it. Developers should use the
`screenshot` function:
https://github.com/ionic-team/ionic-framework/blob/main/core/src/utils/test/playwright/docs/api.md#using-the-return-value-from-each-configuration
## 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#23750
---------
<!-- 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 does not support h11 and h24 hour formats
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Datetime supports h11 and h24 formats
## 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. -->
Implementation Notes:
1. I broke up the `is24Hour` function into two functions:
- The first function, `is24Hour`, accepts an hour cycle and returns true
if the hourCycle preference uses a 24 hour format
- The second function, getHourCycle, accepts a locale and an optional
hour cycle and returns the computed hour cycle. I found that the hour
cycle is not always set via `hourCycle` (such as when we are using the
system default if it's specified in the `locale` prop using locale
extension tags). This was coupled to is24Hour, but I needed this
functionality elsewhere to add support for this feature, so I decided to
break the functions up.
2. We were using the hour cycle types in several places, so I decided to
create a shared `DatetimeHourCycle` to avoid accidental typos.
Issue number: resolves#22564
---------
<!-- 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. -->
Changing the size of the FAB button causes it to be positioned
incorrectly. This was happening because we set position values based on
the assumption that the default FAB button would always be 56px x 56px.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- FAB and FAB List positioning is now computed based on intrinsic 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. -->
Dev build: `7.4.1-dev.11695395641.14897417`
---------
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. -->
When testing Dynamic Font Scaling with a custom font I noticed that the
large title does not respect `--ion-font-family` on transition.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The cloned large title now respect `--ion-font-family`
Note: This happens in `main` too which is why I am merging into there
instead of the Dynamic Font Scaling branch.
| `main` | branch |
| - | - |
|
|
|
## 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. -->
The `fill` prop on `ion-item` is currently deprecated (see warning
[here](https://github.com/ionic-team/ionic-framework/blob/main/core/src/components/item/item.tsx#L248-L253))
but the docs have not been updated to reflect this.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
`@deprecated` flag added to the `fill` prop.
## 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: 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. -->
Some of the tests for `item-sliding` were being skipped due to
flakiness.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updated the tests to use the stable function, `dragElementBy` to
handle gestures, removing the gesture flakiness.
- Separated the basic test to lessen the gesture complexity else it
becomes flaky since it can't handle opening and closing and opening in
the same test.
- Tests are now checking all modes and all directions.
- Updated a utils function with a warning regarding an open issue with
RTL.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
N/A
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Issue number: Resolves#27169
---------
<!-- 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. -->
Clicking the padded space within an `ion-item` will not pass the click
event to the slotted `ion-radio`, `ion-checkbox`, `ion-select` or
`ion-toggle`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The padded space at the start of `.item-native` and at the end of
`.item-inner` is clickable to activate a control.
- When the item is clicked, we check if the event is a result of
clicking the control or clicking the item's padded space. If the click
event is on the control, we don't need to do anything and let the
default behavior occur. If the click event is on the padded space, we
manually call the `.click()` method for the interactive element.
- The cursor pointer displays when hovering over the padded space when a
slotted interactive control is present.
## 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#27199
---------
<!-- 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 using the modern range in an item, the knob will get cut off by the
item when the value is at either the min or the max.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Range knob is no longer cut off by the 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. -->
This is an extension of
https://github.com/ionic-team/ionic-framework/pull/27188. I decided to
make a separate branch/PR since I added tests and changed the
implementation a bit. Feel free to take all/some/none of this code.
---------
Co-authored-by: Sean Perkins <sean-perkins@users.noreply.github.com>
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#28180
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
When presenting an overlay, we remove the root (usually
`ion-router-outlet`) from the accessibility tree. This makes it so you
cannot accidentally focus elements behind the overlay. When dismissing
an overlay we re-add the root to the accessibility tree. However, we
fail to consider if there are multiple presented overlays. For example,
if you present a modal, then an alert, then dismiss the alert, then the
root is re-added to the accessibility tree even though the modal is
still presented.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The root is now re-added to the accessibility tree only if it is the
last presented overlay.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.4.1-dev.11694783260.13da477f`
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
- There are no tests for menu when safe area is applied.
- The safe area variables on menu weren't being reset properly to allow
easy local customization.
Currently, some of the variables are being set to `env()`. This is the
same structure that is being used in core. However, this doesn't
prevents users from mocking the safe area when using
`--ion-safe-area-left: 50px` on `html`. It makes it hard to create tests
to validate that padding is being applied to the safe area.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Tests have been added.
- The safe area variables on menu are now being reset to use the values
from `:root`.
The variables are being `unset` in order for the variables to [default
to parent styles](https://stackoverflow.com/a/69491310/5374225). Since
core styles has already declared the variables, then developers can use
`--ion-safe-area-left: 50px` on `html`.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
N/A
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Bumps [@playwright/test](https://github.com/Microsoft/playwright) from
1.37.1 to 1.38.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.38.0</h2>
<h2>UI Mode Updates</h2>
<p><img
src="https://github.com/microsoft/playwright/assets/746130/8ba27be0-58fd-4f62-8561-950480610369"
alt="Playwright UI Mode" /></p>
<ol>
<li>Zoom into time range.</li>
<li>Network panel redesign.</li>
</ol>
<h2>New APIs</h2>
<ul>
<li>[<code>browserContext.on('weberror')</code>]</li>
<li>[<code>locator.pressSequentially()</code>]</li>
<li>The [<code>reporter.onEnd()</code>] now reports
<code>startTime</code> and total run <code>duration</code>.</li>
</ul>
<h2>Deprecations</h2>
<ul>
<li>The following methods were deprecated: [<code>page.type()</code>],
[<code>frame.type()</code>], [<code>locator.type()</code>] and
[<code>elementHandle.type()</code>].
Please use [<code>locator.fill()</code>] instead which is much faster.
Use [<code>locator.pressSequentially()</code>] only if there is a
special keyboard handling on the page, and you need to press keys
one-by-one.</li>
<li>The method [<code>expect(value).toMatchSnapshot()</code>] is
deprecated in favor of [<code>expect(page).toHaveScreenshot()</code>]
and [<code>expect(locator).toHaveScreenshot()</code>].</li>
</ul>
<h2>Breaking Changes: Playwright no longer downloads browsers
automatically</h2>
<blockquote>
<p>[!NOTE]
If you are using <code>@playwright/test</code> package, this change
<strong>does not</strong> affect you.</p>
</blockquote>
<p>Playwright recommends to use <code>@playwright/test</code> package
and download browsers via <code>npx playwright install</code> command.
If you are following this recommendation, nothing has changed for
you.</p>
<p>However, up to v1.38, installing the <code>playwright</code> package
instead of <code>@playwright/test</code> did automatically download
browsers. This is no longer the case, and we recommend to explicitly
download browsers via <code>npx playwright install</code> command.</p>
<p><strong>v1.37 and earlier</strong></p>
<p><code>playwright</code> package was downloading browsers during
<code>npm install</code>, while <code>@playwright/test</code> was
not.</p>
<p><strong>v1.38 and later</strong></p>
<p><code>playwright</code> and <code>@playwright/test</code> packages do
not download browsers during <code>npm install</code>.</p>
<p><strong>Recommended migration</strong></p>
<p>Run <code>npx playwright install</code> to download browsers after
<code>npm install</code>. For example, in your CI configuration:</p>
<pre lang="yml"><code>- run: npm ci
- run: npx playwright install --with-deps
</code></pre>
<p><strong>Alternative migration option - not recommended</strong></p>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="da997ee8c0"><code>da997ee</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/27067">#27067</a>):
docs: fix line wrapping in release notes</li>
<li><a
href="94b6fe1bdb"><code>94b6fe1</code></a>
chore: mark 1.38.0 (<a
href="https://redirect.github.com/Microsoft/playwright/issues/27030">#27030</a>)</li>
<li><a
href="55cf8eae25"><code>55cf8ea</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/27028">#27028</a>):
docs: add release notes for 1.38</li>
<li><a
href="a0a099fe4a"><code>a0a099f</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/27049">#27049</a>):
feat(webkit): roll to r1908 (<a
href="https://redirect.github.com/Microsoft/playwright/issues/27055">#27055</a>)</li>
<li><a
href="cd8b12c0d5"><code>cd8b12c</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/27041">#27041</a>):
feat(chromium): roll to r1080 (<a
href="https://redirect.github.com/Microsoft/playwright/issues/27045">#27045</a>)</li>
<li><a
href="9981f1418a"><code>9981f14</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/27008">#27008</a>):
chore: polish ui mode for better mac appearance</li>
<li><a
href="5f78f27a7a"><code>5f78f27</code></a>
cherry-pick(<a
href="https://redirect.github.com/Microsoft/playwright/issues/27006">#27006</a>):
chore: document new onEnd params</li>
<li><a
href="7c838653d6"><code>7c83865</code></a>
chore: fix the split view, reset window on timeline click (<a
href="https://redirect.github.com/Microsoft/playwright/issues/27007">#27007</a>)</li>
<li><a
href="d9eabda09d"><code>d9eabda</code></a>
fix(locators): escape quotes in regular expressions (<a
href="https://redirect.github.com/Microsoft/playwright/issues/27002">#27002</a>)</li>
<li><a
href="6bbc09c96c"><code>6bbc09c</code></a>
chore: show channel name in trace viewer metadata (<a
href="https://redirect.github.com/Microsoft/playwright/issues/26987">#26987</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/Microsoft/playwright/compare/v1.37.1...v1.38.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>
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The `--ion-safe-area-left` and `--ion-safe-area-right` variables in
`ion-menu` are being set as if they use the app's direction. It's been
determined that safe area is not logical and uses the device's
direction. The current implementation is adding padding in the wrong
sides for `ion-toolbar` and `ion-content` within a `ion-menu`.
Additionally, `ion-menu` does not use the entire screen so the safe area
only needs to be applied to the side that is touching the device screen.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Set the `--ion-safe-area-left` and `--ion-safe-area-right` variables
to the correct values based on the device's direction.
- Padding is only added to the side that is not in the safe area.
- `ion-toolbar` is adding `--ion-safe-area-left` and
`--ion-safe-area-right` based on the device's direction.
- `ion-toolbar` can now inherit the correct values from
`--ion-safe-area-left` and `--ion-safe-area-right`.
- `ion-content` can now inherit the correct values from
`--ion-safe-area-left` and `--ion-safe-area-right`.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: 7.3.4-dev.11694015543.18bc484f
Issue number: resolves#25340
---------
- Exposes the following parts for a calendar day: `calendar-day`,
`today`, and `active`
- Combines the `calendar-day-highlight` element with the `calendar-day`
element so developers don't have to know to style two different elements
& we don't have to expose them as separate parts
- Improves height parity of the calendar day across browsers
- Updates the `custom` e2e test to include an example of styling days
using the newly exposed CSS parts
- Adds tests for the focus states of the calendar day
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: 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 progress bar basic test makes use of the `ion-range` component in
the captured screenshot. This results in tight coupling when the
appearance of the range changes.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Decouples `ion-range` from the progress bar basic screenshot captures
- Splits out dynamic behavior that was used with `ion-range` to test
files that can be manually interacted with
## 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. -->
Radio has a test with the wrong screenshot name of toggle.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Radio has a test with the correct screenshot name.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
N/A
Issue number: resolves#22142
---------
<!-- 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. -->
Textarea always takes up the entire width of a line which prevents the
`cols` property from working correctly.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The textarea respects the `col` property value only when `autoGrow` is
`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. -->
Dev build: `7.3.2-dev.11693402720.1adb3bcf`
---------
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: 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>
