Issue number: resolves#28716
---------
<!-- 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. -->
All components that have per-mode stylesheets can have their mode
adjusted by setting `mode` on the component. We use the `setMode`
function to determine which mode to use on the component:
516b84475e/core/src/global/ionic-global.ts (L75)
While this works on refresher, it is missing the `virtualProp` jsdoc
comment which causes it to not have the appropriate type information. As
a result, when developers try to use a JS binding for `mode`, they will
get compilation errors.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Adds virtualProp for mode to refresher
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
I am considering this a bug fix instead of a feature. In non-TypeScript
environments you can set `mode` on `ion-refresher` and it does change
the mode. What's missing here is the type information associated with
it.
Dev build: `7.6.2-dev.11702914017.1ae72da5`
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. -->
Buttons slotted in the start/end slots of input, textarea, or select
have a lot of excess padding that can cause them to look misaligned from
other pieces such as the control's label, especially when using
`fill="clear"`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Padding removed, and a border radius added so that non-clear buttons as
well as the focus state on clear buttons still look okay. Existing
screenshot tests have also been updated to include buttons (non-clear
ones so you can see the border radius in the screenshots).
Let me know if you think this should go on a feature branch instead. I
chose `main` because the current experience looks somewhat broken and we
just did a minor release recently, but this could be considered a
notable enough behavior change.
## 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. -->
While working on an unrelated task, I noticed the list items in the list
starter app run off the page. This is due to the text wrapping behavior
in v7.6 where we allows the labels to grow/shrink. However, we do not
set a limit on how much they can grow. This means that child elements
inside of `ion-label` with long text can cause the label container to
grow indefinitely.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Labels in item have a max-width of 100%
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!--
If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.6.1-dev.11702498225.1ad6eda6`
| before | after |
| - | - |
| 
| 
|
---------
Co-authored-by: ionitron <hi@ionicframework.com>
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.
