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. -->
Screenshots in a branch are currently compared against the screenshots
on `main`. While we ultimately need to compare against ground truths in
`main`, this can cause tests to seemingly fail at random. For example,
this branch was created based on
eb2772c0ce.
However,
381de0b3d3
was added to `main` after the first commit and has new screenshot diffs.
I do not have the latest ground truths for the changed screenshots in
this branch, so the screenshot tests failed in
https://github.com/ionic-team/ionic-framework/actions/runs/4995702351/jobs/8947969061
even though I did not change any component implementations.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Test runs in CI now run against the ground truths available in the
branch. When a commit is added to the merge queue, it will be tested
against the latest `main` and any commits ahead of it in the queue. As a
result, if there _is_ a conflict then the test run will fail at that
point and the commit will be removed from the merge queue.
## 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
[@stencil/vue-output-target](https://github.com/ionic-team/stencil-ds-output-targets)
from 0.8.4 to 0.8.5.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/ionic-team/stencil-ds-output-targets/commits">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 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: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: Resolves#22176
---------
<!-- 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. -->
Translucent popovers do not get blurred in Chromium
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Translucent popover gets blurred in Chromium
Note: existing screenshot tests nicely show the change in behavior.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
Because of the [existing, apparently
intentional](https://bugs.chromium.org/p/chromium/issues/detail?id=1148826)
behavior in Chromium browsers with `backdrop-filter` and animation, we
need to either animate the arrow and content instead of the wrapper or
apply the filter to a different element. Here, I've animated the arrow
and content instead of the wrapper.
The fix only needs to apply in `ios` mode. The translucent option is not
supported in `md` mode.
<!-- 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#27184
---------
## What is the current behavior?
The modern form controls do not use the same opacity for their labels
when disabled, resulting in inconsistent UI when using two different
types in the same view (select vs checkbox, for example).
## What is the new behavior?
The checkbox, input, radio, range, select, textarea and toggle labels
have been updated on both modes to use the same opacity as each other
when disabled. The checkbox and radio icons have been updated to use a
different opacity than the label for `md` mode.
- Updates `ios` mode so all form controls use the same opacity of `0.3`
- I could not find any guidelines by Apple for what color these should
be, so I decided to just make them the same as what is most commonly
used & match item
- Updates `md` mode so all form control labels use the same opacity of
`0.38`
- I used the [Material Design 3
documentation](https://m2.material.io/components) to get this number as
well as the opacity of the disabled selection controls in the [Material
Design 2 figma design
kit](https://www.figma.com/community/file/778763161265841481). The
Material Design 2 documentation does not mention the opacity, but this
is also the number used by Material Design 1 so it's safe to assume it
is what the disabled form labels should also use for Material Design 2.
- Updates the `md` range so the slotted elements are also included when
setting the opacity on the label
- Updates the range, radio & checkbox tests to make sure there are
screenshots in the different disabled states
- Updates the item/disabled test to include radio & textarea so you can
see all form controls side by side
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
## Other information
I downloaded screenshots of the item disabled tests and put them side by
side for `main` and this branch in order to see the differences in the
labels. The grey boxes to the left of each item are just a bigger
version of the label color for that item, so it's easier to see when
they aren't the same.
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#25990
---------
<!-- 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 tab bar and footer are being shown too soon after the keyboard
begins to hide. This is happening because the webview resizes _after_
the keyboard begins to dismiss. As a result, it is possible for the tab
bar and footer to briefly appear on the top of the keyboard in
environments where the webview resizes.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The tab bar and footer wait until after the webview has resized before
showing again
| before | after |
| - | - |
| <video
src="https://user-images.githubusercontent.com/2721089/236905066-42ac17a5-a5bf-458b-9c62-005fcce05e20.MP4"></video>
| <video
src="https://user-images.githubusercontent.com/2721089/236905185-d2f539d1-6d93-4385-b1cb-24dd7aa06393.MP4"></video>
|
This code works by adding an optional parameter to the keyboard
controller callback called `waitForResize`. When defined, code within
Ionic can wait for the webview to resize as a result of the keyboard
opening or closing. Tab bar and footer wait for this `waitForResize`
promise to resolve before re-showing the relevant elements.
This `waitForResize` parameter is only only defined when all of the
following are two:
**1. The webview resize mode is known and is _not_ "None".**
If the webview resize mode is unknown then either the Keyboard plugin is
not installed (in which case the tab bar/footer are never hidden in the
first place) or the app is being deployed in a browser/PWA environment
(in which case the web content typically does not resize). If the
webview resize mode is "None" then that means the keyboard plugin is
installed, but the webview is configured to never resize when the
keyboard opens/closes. As a result, there is no need to wait for the
webview to resize.
**2. The webview has previously resized.**
If the keyboard is closed _before_ the opening keyboard animation
completes then it is possible for the webview to never resize. In this
case, the webview is at full height and the tab bar/footer can
immediately be re-shown.
------
Under the hood, we use a
[ResizeObserver](https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver)
to listen for when the web content resizes. Which element we listen on
depends on the resize mode set in the developer's Capacitor app. We
determine this in the `getResizeContainer` function.
From there, we wait for the ResizeObserver callback, then wait 1 more
frame so the promise resolves _after_ the resize has finished.
## 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.0.6-dev.11683905366.13943af0`
