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>
Issue number: resolves#24905, resolves#26840, resolves#15710
---------
<!-- 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 current picker is only displayed as an overlay which makes it
impossible to use inline with the rest of the application. Additionally,
there are several bugs and missing features. For example, it is
impossible to know when the value of the picker column has changed using
public APIs. This is valuable for updating other columns in response to
that data.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Introduces `ion-picker` as an inline wheel picker component. The
overlay picker is still available using `ion-picker-legacy`.
- The implementation of this component resolves linked bugs. It also
resolves linked features by exposing an `ionChange` event for developers
to listen for.
## 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.11702398696.1ab62ea9`
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: Shawn Taylor <shawn@ionic.io>
Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
Co-authored-by: Sean Perkins <13732623+sean-perkins@users.noreply.github.com>
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
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>
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#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>
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#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: 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#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#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.
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: 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. -->
`ion-datetime` uses an `ion-item` to render the month/year toggle button
inside of the header.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `ion-datetime` uses a `button` element for the month/year toggle
button
## Does this introduce a breaking change?
- [x] Yes
- [ ] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
Impact and migration path is noted in the `BREAKING.md`.
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
- `translucent` is not a valid CSS value for `background`. This was
always intended to be `transparent`.
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
BREAKING CHANGE: The CSS shadow part for `month-year-button` has been changed to target a `button` element instead of `ion-item`. Developers should verify their UI renders as expected for the month/year toggle button inside of `ion-datetime`.
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. -->
It is possible to navigate the columns of a disabled Datetime with
`prefer-wheel` via the keyboard.
https://github.com/ionic-team/ionic-framework/assets/14926794/9c9dafc4-4b77-45a6-a276-70201c5c3ea5
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Picker Column Internal has a disabled state that disables the full
column
- When a Datetime is disabled with `prefer-wheel`, the columns in the
Datetime will be disabled
- It is no longer possible to navigate the wheels in a disabled Datetime
via the keyboard
Comparison of native & Ionic 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. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: resolves#28494
---------
<!-- 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 appearance of the input is being set to `none` which clears the
browser appearance settings for height on the control. This results in
the `<input type="date" />` to render without a height.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Minimum height is assigned to the alert input, forcing it to render at
it's expected height
- Date input renders correctly in Mobile Safari
## 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. -->
We have screenshots for this component, but Playwright runs an emulation
of Mobile Safari that does not reproduce this issue that is only present
on device. There for we cannot write a test on this change.
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#28548
---------
<!-- 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 was not scrolling at all when the `value` prop was changed
programmatically. This was due to some logic we had in
`componentDidRender` to work around a WebKit bug which was causing the
scroll position to be moved back to where it was prior to setting the
`value` prop. This caused the scroll position to never move.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Datetime scrolls to the new value when `value` is updated
programmatically even if `min` is set.
## 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.6-dev.11700169088.140f3e6a`
Co-authored-by: amandaejohnston
<amandaejohnston@users.noreply.github.com>
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Type checking inside of the Stencil unit tests have been disabled for a
long time. This has resulted in a difficult developer experience and
numerous issues (both types and implementation) within our unit tests.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Type checking is now enabled for all Stencil unit tests
- Tests have been updated to resolve type errors and implementation
errors
- Many `as any` casts were introduced, as many legacy tests test invalid
configurations of functions that require it (for example passing
`undefined` to an argument that cannot be `undefined`).
## 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. -->
To test this PR you can checkout the branch locally. Install
dependencies in the `/core` directory to make sure you are on at least
`@stencil/core@4.7.2`.
Opening either a `.spec.ts` or `.spec.tsx` file, validate that your IDE
detects types and can provide auto completions for jest global types.
If you desire, you can provide an invalid type and try building the
project - you will observe the build will fail due to the invalid type.
Issue number: resolves#23977
---------
<!-- 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 MD Alert on tablet dimensions does not match the MD spec
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- MD Alert now follows the MD spec for tablet dimensions
- Added tablet and mobile viewport mixins for alert and the card modal.
(There should be no visual diffs for the card modal)
## 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 supersedes https://github.com/ionic-team/ionic-framework/pull/27462
since I needed to add new screenshot tests. The author of that PR has
been given co-author credit here.
---------
Co-authored-by: GlenOttley <GlenOttley@users.noreply.github.com>
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Issue number: resolves#28506
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
ion-accordion-group would not set the value when using it as a Angular
standalone component and data binding:
``` html
<ion-accordion-group #accordionGroup [value]="fromValue">
<ion-accordion value="turtles">
<ion-item slot="header" color="light">
<ion-label>First Accordion</ion-label>
</ion-item>
<div class="ion-padding" slot="content">First Content</div>
</ion-accordion>
<ion-accordion value="second">
<ion-item slot="header" color="light">
<ion-label>Second Accordion</ion-label>
</ion-item>
<div class="ion-padding" slot="content">Second Content</div>
</ion-accordion>
</ion-accordion-group>
```
The problem here is Angular is setting the value of the accordion group
after the component has been initialized (but not loaded) and before the
component watchers are setup, so
[valueChanged](d69ad43482/core/src/components/accordion-group/accordion-group.tsx (L78))
does not fire automatically.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Run valueChanged() in componentDidLoad().
-
-
## 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: Mohamed Ben Makhlouf <benmakhlouf@softcatalyst.com>
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: resolves#21769
---------
<!-- 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. -->
Toast does not support swipe gestures to dismiss.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Added a `swipeGesture` property that allows users to swipe toasts
closed.
Note: This is a combination of previous PRs
https://github.com/ionic-team/ionic-framework/pull/28380 and
https://github.com/ionic-team/ionic-framework/pull/28402⚠️ There is a visual glitch on iOS where dragging and having the toast
animate back to its opened position causes a flicker. This is an iOS 17
regression and is being tracked in
https://github.com/ionic-team/ionic-framework/issues/28467. This bug has
been reported to and confirmed by Apple.
## 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. -->
⚠️ Give co-author credit to author in
https://github.com/ionic-team/ionic-framework/pull/23124
---------
Co-authored-by: evgeniy-skakun <evgeniy-skakun@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. -->
While evaluating step colors for high contrast themes I discovered that
this code is not actually applied anywhere.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Remove unused code
## 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#28356
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
`ion-radio-group` would not set the radio value when using it as a
Angular standalone component and data binding:
```html
<ion-radio-group [value]="fromValue">
<ion-radio value="dogs">Dogs</ion-radio><br />
<ion-radio value="cats">Cats</ion-radio><br />
<ion-radio value="turtles">Turtles</ion-radio><br />
<ion-radio value="fish">Fish</ion-radio><br />
</ion-radio-group>
```
This is happening because the value is set before the [value
watcher](c5dd622bbe/core/src/components/radio-group/radio-group.tsx (L34))
has been configured. The event, `ionValueChange`, does not get
[dispatched](c5dd622bbe/core/src/components/radio-group/radio-group.tsx (L37)).
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Run `valueChanged()` in `componentDidLoad()`.
- `valueChanged()` function is tied to the [value
watcher](c5dd622bbe/core/src/components/radio-group/radio-group.tsx (L34))
so it will
[dispatch](c5dd622bbe/core/src/components/radio-group/radio-group.tsx (L37))
the `ionValueChange`.
## 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. -->
In our testing, we observed that the issue described below only occurs
when assigning a value to the radio group within the primary content,
such as rendering within the app component template.
When the template is isolated to a route, the value is assigned
correctly. To address this issue, we need to ensure that the watcher is
called after the component has finished loading, allowing the emit to be
dispatched correctly.
Dev build: 7.5.4-dev.11699404450.136700d7
Issue number: resolves#28466
---------
<!-- 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/issues/27060 I fixed an
issue where the main title would be visible briefly before the
collapsible large title a) was configured and b) hid the main title. I
accomplished this by using CSS to target
`ion-header[collapse="condense"]`. However, I failed to account for when
the property is not reflected on the host. Some JS frameworks allow the
property to remain on the element but some do not.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- I improved this fix by also targeting the class set on the host. This
class is set regardless of property reflection status.
| main | branch |
| - | - |
| <video
src="https://github.com/ionic-team/ionic-framework/assets/2721089/991523da-8549-451b-930f-5df45c2783de"></video>
| <video
src="https://github.com/ionic-team/ionic-framework/assets/2721089/149c9546-2d9b-42a2-89f1-a17fa146aee6"></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.5.4-dev.11699282935.1db450b0`
---------
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Issue number: resolves#28468
---------
<!-- 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 cancel button in the searchbar used to align with the back button,
but that behavior gradually regressed between Ionic v4 and Ionic v7.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Adjusted the padding on the searchbar back button
- Reduced the size of the searchbar back button. It was currently set to
25.6px whereas the `ion-back-button` icon was 24px. This caused the
icons to never align even with 9px. (This should cause a few additional
diffs)
- Added a screenshot test
| v4 | v5 | v6 | v7 | branch |
| - | - | - | - | - |
| 
|
|
|
|
|
Note that in v4 the alignment was slightly off. It was fixed in v5, but
then broke in v6 and remained unchanged in v7 (until now).
## 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.11699310489.151b2717`
---------
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Co-authored-by: ionitron <hi@ionicframework.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 safe area for Item Divider would change sides when the direction
changed. e.g., if the safe area padding should be on the left, it would
be on the left when the direction was LTR but would be on the right when
the direction was RTL. It should always be on the left.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The left safe area padding is on the left side of an Item Divider
whether the direction is LTR or RTL.
- The right safe area padding is on the right side of an Item Divider
whether the direction is LTR or RTL.
- Updated LTR and RTL screenshots for item to include an item divider
Similar to #28403 but for Item Divider.
## 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>
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Issue number: resolves#28435
---------
<!-- 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 item in the last item-sliding still has a border in an inset list.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Item in last item-sliding no longer has a border
I originally only added `ion-item-sliding:last-of-type ion-item` but I
discovered that the original `ion-item:last-child` causes items in
item-sliding where the item is the last element in the item-sliding
container to not have a border, so the original fix was incomplete.
I added comments as to what each line does and why we didn't just do
`ion-item:last-child`.
## 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: Brandy Carney <brandyscarney@users.noreply.github.com>
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Brandy Carney <brandyscarney@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. -->
<!-- Please describe the current behavior that you are modifying. -->
Sometimes the screenshot gets captured as
when it should be
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Hopefully the screenshot will be more consistent.
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
<!-- 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. -->
The safe area for Item would change sides when the direction changed.
e.g., if the safe area padding should be on the left, it would be on the
left when the direction was LTR but would be on the right when the
direction was RTL. It should always be on the left.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The left safe area padding is on the left side of Item whether the
direction is LTR or RTL.
- The right safe area padding is on the right side of Item whether the
direction is LTR or RTL.
- There's now a screenshot test for left and right padding for both
directions.
Note: There is a separate ticket for updating the safe area padding for
ion-item-divider.
## 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: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Issue number: Resolves#23942
---------
<!-- 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 an overlay is created (inserted in the DOM), but not presented, the
scroll gesture is prevented. This behavior comes from the
`connectedCallback` of `ion-backdrop`, where the gesture is prevented as
soon as the backdrop is inserted in the DOM.
This means in situations where a developer creates an overlay, but does
not present it immediately, the user cannot scroll. This is not desired.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Scroll blocking behavior tied to the gesture has been removed from
`ion-backdrop` and implemented into the overlays directly.
- When an overlay is presented, scroll blocking is enabled on the `body`
element (the user cannot scroll on the main content).
- When the last presented overlay is dismissed, scroll blocking is
disabled on the `body` element (the user can scroll on the main
content).
## Does this introduce a breaking change?
- [x] Yes
- [ ] No
`ion-backdrop` no longer prevents scrolling on the main content when the
backdrop is either inserted into the DOM or removed from the DOM.
Developers using Ionic overlays do not need to migrate their
implementations.
Developers with custom overlays using `ion-backdrop` internally can
either use Ionic's gesture controller to disable scrolling when their
overlay is presented/dismissed or can manually add the
`backdrop-no-scroll` Ionic global class to the `body` element.
<!-- 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: #28121
---------
<!-- 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 is not possible to navigate between months when ion-datetime is in
readonly mode. This means that if there are multiple dates selected, the
user cannot browse to view them all.
Also, keyboard navigation is not prevented in `readonly` or `disabled`
mode where it should be.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
When `readonly`:
- Clicking the month-year button changes the month & year in readonly
mode
- Clicking the next & prev buttons changes the month in readonly mode
- Left and right arrow keys change the month in readonly mode
- Swiping/scrolling changes the month in readonly mode
- The selected date does not change when doing any of the above
- You cannot clear the value using keyboard navigation of the clear
button in readonly mode
When `disabled`:
- You cannot navigate months via keyboard navigation of the month-year
button in disabled mode
- You cannot navigate months using keyboard navigation of the previous &
next buttons in disabled mode
- You cannot navigate months via the left and right arrow keys in
disabled mode
- The selected date does not change when doing any of the above
- You cannot clear the value using keyboard navigation of the clear
button in disabled mode
Known bug:
- It is still possible to navigate through dates in `prefers-wheel` when
`disabled`. This bug existed prior to this PR. I created FW-5408 to
track this.
## 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: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
