This best practice currently resides in our internal testing process
docs. I think this is valuable information for contributors to have as
well, so I've added it to our public best practices doc.
The team had feedback during a sprint retro that the breaking change
process documentation was a bit spread out. In particular, some team
members were not clear that you need to a) update the breaking.md file
and b) add the "BREAKING CHANGE" comment to the commit description.
This PR adds both of these things are comments for awareness.
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. -->
Ionic React projects using `@types/react@18.2.43` or greater will run
into a type-check error on build with `IonRouterOutlet` and potentially
other components:
```
Property 'placeholder' is missing in type '{ children: Element[]; }' but required in type 'Pick<IonRouterOutlet & { basePath?: string | undefined; ref?: Ref<any> | undefined; ionPage?: boolean | undefined; } & IonicReactProps & Omit<...>, "color" | ... 254 more ... | "ionPage">'.
```
Definitely typed decided to make a breaking type change in a patch
release:
b954269038
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Patches the type to allow for compatibility between React v16, 17 and
18.
## 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. -->
### Testing
1. Create a new Ionic react project with the "list" template.
2. Run `npm run build`
3. Observe: Exception posted above
4. Install the dev-build
5. Run `npm run build`
6. Observe: No exception, build passes
7. You can additionally serve the app to verify no runtime
exceptions/broken behavior.
Dev-build: `7.6.1-dev.11702322681.17e39348`
Issue number: resolves#21530
---------
## What is the current behavior?
The `box-shadow` and `transform` properties cannot be styled on a menu
when it is inside of a split pane and visible due to the following:
1) The `box-shadow` and `transform` properties are set to `none` with
`!important`
2) The menu itself is not on "top" of the split pane content so the
content hides any box shadow
## What is the new behavior?
- Removes all uses of `!important` in split pane and menu
- Developers will need to change the `z-index` from `0` to `1` on the
`ion-menu` so the menu will sit on top of the split pane and show the
`box-shadow`
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
## Other information
I considered putting the test for this in `split-pane` but I thought
since it was styling the `ion-menu` it should go in menu. I can move
this if others think it makes more sense in `split-pane`.
---------
Co-authored-by: ionitron <hi@ionicframework.com>
I've noticed a few instances where the team forgets to add the
"resolves" keyword (or similar "closes"/"fixes" keywords) when linking a
PR to an issue. GitHub will not link the PR with the issue and will not
close the issue on PR merge unless one of these keywords is used.
I've updated the PR template to add the "resolves" keyword so team
members don't need to worry about remembering to add it.
Older versions of WebKit used an old `constant()` syntax for safe area
variables: https://caniuse.com/?search=env
As of Safari 11.3, `env()` is supported instead. We haven't supported
Safari 11 in years, so I think this is safe to remove.
Issue number: resolves#24260
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
When replacing a route (`router.push(newRoute, 'none', 'replace')`) the
`RouterDirection` from the route being replaced is being used (if it
exists) instead of the new one the user specifies.
## What is the new behavior?
User-specified `RouteDirection` is used, if it exists. If it doesn't it
falls back to the `RouteDirection` of the route being replaced.
## 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
Please see the following comment for why I think the current behavior is
incorrect, and why this change is needed:
https://github.com/ionic-team/ionic-framework/issues/24260#issuecomment-1078960780
---------
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: resolves#28633
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
In https://github.com/ionic-team/ionic-framework/pull/28005 I introduced
a fix that causes "clearOnEdit" to not clear input/textarea when the Tab
key was pressed. However, there were several edge cases I missed. For
instance, pressing the "shift" key and then the "tab" key would still
clear the input because "shift" was not explicitly excluded.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Input and textarea now explicitly ignores modifier keys that do not
change the value of the input
- `didInputClearOnEdit` is not set to `true` when an ignored key is
pressed. Otherwise, pressing an ignored key and then an accepted key
would not cause the input to be cleared. For example, pressing "shift",
releasing "shift", then pressing "A" should cause the input to still get
cleared.
- Added test coverage
## 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. -->
Playwright bug report for
a9f34a54f1:
https://github.com/microsoft/playwright/issues/28495
Issue number: resolves#28673
---------
<!-- 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 reviewing https://github.com/ionic-team/ionic-framework/pull/28671
I noticed a bug where the custom animation was not used when going back
after a replace.
`handleNavigate` will override whatever is in `incomingRouteParams`.
Since we were passing `routeAnimation` (which is `undefined`), it was
overriding the animation we set in `handleNavigateBack`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `routeAnimation` is no longer overridden
## 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.6.1-dev.11702048520.13c82dad`
Issue number: resolves#25839
---------
<!-- 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. -->
Confirming the working day when a datetime using a wheel picker without
an initial value will result in a value of `undefined` instead of the
displayed working day the user sees.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `preferWheel` uses the working value on confirmation
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev-build: `7.5.7-dev.11701896424.13d40ac9`
Co-authored-by: liamdebeasi <liamdebeasi@users.noreply.github.com>
Bumps [@axe-core/playwright](https://github.com/dequelabs/axe-core-npm)
from 4.8.1 to 4.8.2.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/dequelabs/axe-core-npm/blob/develop/CHANGELOG.md"><code>@axe-core/playwright</code>'s
changelog</a>.</em></p>
<blockquote>
<h1>Change Log</h1>
<p>All notable changes to this project will be documented in this file.
See <a href="https://conventionalcommits.org">Conventional Commits</a>
for commit guidelines.</p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/dequelabs/axe-core-npm/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 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>
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. -->
We currently apply a workaround to `ion-select` so it can wrap correctly
inside of `ion-item`:
357b8b2beb/core/src/components/select/select.scss (L99-L103)
However, this causes issues when a parent element has `display: flex`
because the `ion-select` width becomes 0.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- In order to get the desired behavior, we need the `ion-select` (and
other elements in the default slot) to either truncate or wrap within
its own container and then have the entire container (i.e. the entire
`ion-select`) wrap to the next line once the container is too small.
To achieve this, I needed to set a min-width on `.item-inner` to define
the point at which the element should wrap to the next line. I also
changed the flex basis from `auto` to `0` which means the initial main
size of the flex item will be 0px. In reality, this will be
`--inner-min-width` since we also set `min-width:
var(--inner-min-width)`. I used `0` for simplicity but I can change this
to use the CSS variable if that's more clear. Since we also set
`flex-grow: 1` we indicate that the element can grow from that basis
(but it cannot shrink).
I chose `--inner-min-width: 4rem` to minimize the number of diffs. We
can certainly change this, but it may cause some diffs as certain
elements will start wrapping sooner. I also chose to use `rem` because
having a fixed min-width means that fewer characters are going to fit in
the same space as text scales.
I made this a CSS variable but left it undocumented. If developers need
a way of changing this `min-width` they can request it and we can easily
expose this variable. However, I think `4rem` is small enough that this
should be sufficient.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
The visual diffs here are correct. The table below shows the screenshot
group and an explanation for why the changes are correct.
| Path | Example | Details |
| - | - | - |
| `disabled` |
[Link](https://github.com/ionic-team/ionic-framework/pull/28631/files#diff-d529716f95f7a7aa82c88588104220775b728af67077f48cd47a8afa04423143)
| The searchbar is able to shrink slightly to fit on the same line as
the checkbox at the bottom. |
| `highlight` |
[Link](https://github.com/ionic-team/ionic-framework/pull/28631/files#diff-0b64f24c91393923701d1ced4e330a1c6b926d72ee461b8ab1e135e708be3457)
| We're changing how small the main content can get, so the input is
only wrapping once it gets to `--inner-min-width`. |
| `legacy/fill` |
[Link](https://github.com/ionic-team/ionic-framework/pull/28631/files#diff-2ef8dbfa5e69e2b96c3e1ed29ab962f08cf5ba2aaf2af773e40bd143e38a4bef)
| We're changing how small the main content can get, so the input is
only wrapping once it gets to `--inner-min-width`. |
| `slotted-inputs` |
[Link](https://github.com/ionic-team/ionic-framework/pull/28631/files#diff-2f173c7303969d6a6c58f30a618cebc3caf918d3761fc83df5642fd48dfabd7b)
| We're changing how small the main content can get, so the range is
only wrapping once it gets to `--inner-min-width`. |
`slotted-inputs` note: I'd argue many of these examples are not best
practices. For example, adding a range in the start slot and the end
slot is a bit unusual. I'm not aware of any native apps that implement
this pattern.
popover note: I [removed the `ion-item` from the `popover/test/async`
test](331fcb859c).
There was a diff because the min-width increased, but IMO that component
should not be used in the popover test since we want to test the
popover, not the item.
--------
Demo:
| `feature-7.6` | `branch` |
| - | - |
| <video
src="https://github.com/ionic-team/ionic-framework/assets/2721089/693d4947-fa33-460d-bc7f-7b96b6338032"></video>
| <video
src="https://github.com/ionic-team/ionic-framework/assets/2721089/df35ca73-87aa-4e76-9bb7-99f0f2810640"></video>
|
(In this demo I updated the `ion-select` to wrap within its own
container first instead of truncate. We may want to consider doing this
by default, but I think this is out of scope for this task)
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Brandy Carney <brandy@ionic.io>
Issue number: resolves#20053
---------
<!-- 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 methods that that are missing for the menu in the
Angular packages. This leads to users to not being able to use methods
like `isAnimating()`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The missing methods have been added by implementing `MenuControllerI`.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: 7.5.8-dev.11701461830.1be851fd
Issue number: resolves#18071
---------
<!-- 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 adding elements to the DOM in the `ionInfinite` callback, scrolling
again would sometimes not cause `ionInfinite` to trigger again. We [set
the didFire flag to
`true`](388d19e04f/core/src/components/infinite-scroll/infinite-scroll.tsx (L126))
before calling `ionInfinite`. This flag ensures that `ionInfinite` is
not called multiple times if users continue to scroll after
`ionInfinite` is fired but before the `complete` method is called.
The [didFire flag is
reset](388d19e04f/core/src/components/infinite-scroll/infinite-scroll.tsx (L131))
once the user scrolls outside of the threshold. Normally this is fine:
If an application adds several new items to a list the current scroll
position will be outside of the threshold. However, if the scroll
position remains in the threshold (such as if an application append a
small number of new items to a list) then the `didFire` flag will not
get reset.
Additionally, there are some instances where the scroll position
restoration when `position="top"` may not work which can cause this bug
to trigger as well. For example, if users quickly scroll to the top, the
scroll position will not be restored correctly and the scroll position
will still be at the top of the screen. That is another instance where
this bug can trigger even if a large number of items were added to the
DOM.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The `didFire` flag is reset when the `complete` method is called. This
ensures that even if the scroll position is still in the threshold
`ionInfinite` can fire again.
Note that developers may notice `ionInfinite` firing more times as a
result of this change. This can happen when appending a small number of
items to the DOM such that the scroll position remains in the threshold.
Previously `ionInfinite` would not fire again, but now it does since
users are scrolling in the threshold. I decided to target this change
for a minor release to minimize any surprises for developers.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.5.4-dev.11700602203.1e7155a1`
---------
Co-authored-by: Maria Hutt <thetaPC@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. -->
The labeler action is currently failing:
https://github.com/ionic-team/ionic-framework/actions/runs/7090913880/job/19298918578?pr=28622.
This is happening due to a breaking change in v5 of the action.
We currently pull from `main` for this action so we are now receiving v5
of the action:
fe3c3d500a/.github/workflows/label.yml (L16)
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- This PR updates the action explicitly to v5 so we don't unexpectedly
take on breaking changes
- This PR also updates the labeler yaml file to account for the v5
breaking changes
## 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: Related to #18132
---------
<!-- 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 documentation about the `autofocus` prop is unclear and does not
accurately reflect how it actually works across browsers and devices.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The documentation for `autofocus` and `setFocus` are more detailed.
- The documentation links to the relevant page in the docs.
## 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#26524
---------
<!-- 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. -->
## Definitions
**Parameterized routes**: A route that includes one or more variables in
the path segments, such as `/form/:index`.
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
When an application routes from a parameterized route, to an
intermediary route, to the same parameterized route, but with a
different value/url, Ionic's routing logic is incorrectly reusing the
view item from the first instance of the parameterized route instead of
calculating that the matched path is different. This results in the
wrong view item being recycled and rendered.
Another way of representing it:
- User navigates to `/form/0` which resolves `FormPage`
- User enters `0` into the form and submits the form
- User navigates to `/link`, which resolves `LinkPage`
- User navigates to `/form/1`, which resolves `FormPage`
- However, instead of creating a new instance of `FormPage` it is
reusing the instance of `FormPage` from `/form/0` which includes the
form having `0` in the input.
- The user now sees a "new view", but with cached data in the form.
This is not expected or desired.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Ionic's routing logic will validate if the entering view item matches
the match route data before reusing it. This results in new instances of
the view item being constructed when using parameterized routes.
https://github.com/ionic-team/ionic-framework/assets/13732623/e7e3d03f-2848-4429-9f60-9074d0761e45
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev-build: `7.5.8-dev.11701383555.17254408`
Issue number: Resolves#26297
---------
<!-- 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. -->
With the modern form control syntax, it is not possible to add icon
buttons or other decorators to the sides of `ion-input`, `ion-textarea`,
or `ion-select`, as you can with `ion-item`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
`start` and `end` slots added to each component.
This PR is a combination of several others that were already approved.
If needed, it might be easiest to review the PRs individually by looking
at the commit history here.
## 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/3271
Dev build: `7.5.4-dev.11701112913.1ea61220`
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: Part of #28300
---------
<!-- 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. -->
Developers are unable to adjust margin, width, etc. of the radio label
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Radio label has a shadow part.
## 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. -->
As part of this work, I investigated moving `pointer-events: none` up
the DOM tree so developers wouldn't be able to override it with the
shadow part. In my testing, I was unable to see any difference in
behavior with vs without `pointer-events: none`. Therefore, I removed it
entirely.
Issue number: Part of #28300
---------
<!-- 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. -->
Developers are unable to adjust margin, width, etc. of the checkbox
label
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Checkbox label has a shadow part.
## 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. -->
As part of this work, I investigated moving `pointer-events: none` up
the DOM tree so developers wouldn't be able to override it with the
shadow part. In my testing, I was unable to see any difference in
behavior with vs without `pointer-events: none`. Therefore, I removed it
entirely.
Issue number: resolves#28611
---------
<!-- 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. -->
It's not possible to pass props that are not camelCase to the `IonNav`
component.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- It is now possible to set a props with kebab-case instead of camelCase
(for example, `root-params` instead of `rootParams`)
## 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 my first PR for ionic so I hope I didn't miss important steps
into the process. I also checked on my project that the fix is working
well. Thank you! 🙂
---------
Co-authored-by: Sean Perkins <sean@ionic.io>
Issue number: resolves#28524
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Watchers in Stencil are constructed sometime between `connectedCallback`
and `componentDidLoad`. If a property is set/changed during that time it
is possible for the callback associated with the watcher to not fire
because the watcher has not been setup yet. This is most often with
`dist-custom-elements` and frameworks such as Angular when using a
binding (i.e. `[trigger]` instead of `trigger`)
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The trigger callback associated with the watcher is manually called in
`componentDidLoad` for each overlay.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.5.5-dev.11699974376.13a15397`
Note: This is a timing related bug due to a behavior in Stencil, so I
did not write automated tests. However, I manually verified that this
issue a) reproduces on `main` and b) is fixed with this dev build for
each overlay component.
Issue number: 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. -->
Testing dark mode is manual per test in Playwright. Ionic developer
needs to setup the variables and assign them to a selector that applies
in the class.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The `.setContent` API will now work with a new config option to test
dark mode automatically without additional configuration/test set-up.
- Default theme is no theme (fallback theme)
- Screenshot names and test titles remain the same for all existing
tests. Only tests that opt into a theme will be pre-pended with `-dark`
or `-light` (as an example for current themes).
## 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. -->
When an item containing a select is used inside of a flex container, the item collapses to `0px` width. Example code:
```html
<div style="display: flex">
<ion-item>
<ion-select aria-label="fruit" placeholder="Select fruit">
<ion-select-option value="apples">Apples</ion-select-option>
<ion-select-option value="oranges">Oranges</ion-select-option>
<ion-select-option value="bananas">Bananas</ion-select-option>
</ion-select>
</ion-item>
</div>
```
This change sets the flex property to `1` on `ion-item` so that it will grow inside of a flex container, resulting in the select being displayed. The `flex` property is ignored when item is inside of a block container.
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 using `.setContent`, the initial page template is lacking key
metadata that will result in AXE violations.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Adds a default `lang` to the `html` document root
- Adds a default `title` tag
## 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. -->
