Issue number: Internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The `ion-input` component currently specifies a `size` attribute to
align with the HTML `input` implementation. However, Ionic's custom
appearance for MD and iOS is not compatible and should not be used with
the `size` attribute:
https://github.com/ionic-team/ionic-framework/issues/27945#issuecomment-1669702274.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The `size` property has been removed from `ion-input`.
## Does this introduce a breaking change?
- [x] Yes
- [ ] 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.
-->
The `size` attribute has been removed from `ion-input`. As it was not
compatible before, this is likely to have a minimal impact to
developers. If your application is using the `size` attribute, replace
the usage with CSS styling to control the width of the `ion-input`.
## 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#28344
---------
<!-- 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 Accordion is inside an Accordion Group, and the Accordion Group
is enabled and not readonly but the Accordion is disabled and/or
readonly, it is possible to navigate to the accordion and open it using
the keyboard. This should not be allowed, just like opening it on click
is not allowed.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- A disabled Accordion inside an Accordion Group may not be opened via
the keyboard.
- A readonly Accordion inside an Accordion Group may not be opened via
the keyboard.
## 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. -->
Issue number: resolves#28455
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The main `ion-content` inside of a popover is not scrollable. Instead,
the `.popover-viewport` container is scrolled because certain styles no
longer applied once we moved popover to the Shadow DOM. This bug
impacted the linked issue because it meant that the infinite scroll
inside of the content never fires (since the content never scrolls).
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The `.popover-viewport` rule now targets slotted content with
the`.popover-viewport` class. This class is added to the root node that
is slotted. This enables us to target the user's content in the light
dom.
## 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.6-dev.11705696534.177666f8`
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#28602
---------
<!-- 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 animate to the new date when the value is changed, but we do not
account for multiple selection. This behavior is valuable for when the
value is set asynchronously on a different month than what it shown.
However, this is confusing when there are multiple dates selected in
different months, because we do not reasonably know which date to
animate to.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Datetime no longer animates to the new value if more than one date is
selected, and the selected dates aren't all in the same month.
An alternative strategy would be to always animate unless one of the
selected dates is in the month currently being viewed. However, this
would still mean guessing at which value the user wants to see, which we
are trying to avoid.
Based on this PR:
https://github.com/ionic-team/ionic-framework/pull/28605
## 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. -->
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
---------
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: resolves#28325
---------
<!-- 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 typing the time into the date picker pressing "Enter" does not
close the on-screen keyboard.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Pressing "Enter" closes the on-screen keyboard
## 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. -->
Test:
⚠️ While I have a test for this, please also test this on a physical
Android device.
1. Go to `src/components/datetime/test/basic`
2. Open the time picker (in any of the date times)
3. Tap the time to open the keyboard
4. Press "Enter" on Android. Observe that the keyboard closes.
Dev build: `7.6.6-dev.11705528328.1ef5e17b`
Issue number: resolves#28816
---------
<!-- 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 value is set on Segment asynchronously when binding it in Angular.
However, the timing works out such that the value changes after
`connectedCallback` is fired but before any Stencil Watchers are
configured. As a result, our `value` property watcher does not fire
which causes `ionSelect` to not be emitted. Segment Buttons rely on this
event to know when to update their state (if the value changes such that
a segment button is now selected). This results in a checked segment
button not appearing checked.
This is similar to other issues that have been fixed:
https://github.com/ionic-team/ionic-framework/pull/28510https://github.com/ionic-team/ionic-framework/pull/28488https://github.com/ionic-team/ionic-framework/pull/28526
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Segment now emits `ionSelect` on `componentDidLoad` so that any
descendant segment buttons can update correctly.
## 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.5-dev.11705415448.16878103`
This is a timing issue with Stencil, so I am unable to write a reliable
automated test. Reviewers should test the dev build in the repro
provided in the linked issue.
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. -->
When iOS alert has 3 or more buttons, those are rendered vertically. All
but the last button will have a right border. There shouldn't be a right
border when the buttons are stacked.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Vertical buttons don't have a right border.
- Separated the test in order to also test dark theme.
## 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. -->
N/A
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#28818
---------
<!-- 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. -->
Select has logic in place to prevent the overlay from opening when
clicking the slotted content. As part of this, we need to deal with the
`<label>` element dispatching another click that then bubbles up and
causes the overlay to open when clicking the slotted content. We
currently deal with this by calling `preventDefault` which prevents this
extra event from being dispatched only when clicking the slotted
content.
We also call `stopPropagation`. This code is not necessary, and in most
cases should not have any adverse effects on developer applications.
However, this does impact React applications due to how React handles
events. When a developer places `onClick` on a slotted element, a native
"click" listener is not immediately applied to that element. Instead,
React adds a native "click" listener to the root element of an
application. When that listener's callback fires, React will dispatch a
synthetic click event on the slotted element. Since we are calling
`stopPropagation`, the click event never bubbles up to this root node's
listener. As a result, the synthetic event is never dispatched on the
slotted element, and the developed `onClick` callback never fires.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Select no longer prevents events from bubbling. The existing
`event.preventDefault` is sufficient to prevent the label from
dispatching another click (thereby causing the select overlay to open)
when clicking the slotted content.
## 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.5-dev.11705430252.1023daf3`
resolves#28826
BREAKING CHANGE: `getLength` returns `Promise<number>` instead of `<number>`. This method was not previously available in Nav's TypeScript interface, but developers could still access it by casting Nav as `any`. Developers should ensure they `await` their `getLength` call before accessing the returned value.
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. -->
In MD mode, items in an inset list currently receive their own border
radius, separate from the border radius also applied to the inset list
itself. The original intent was likely to ensure that the corners of the
items don't spill out of the list. However, the item's border radius is
no longer needed, for two reasons:
1. MD has since added top/bottom padding to their lists
([spec](https://m2.material.io/components/lists#specs)), which we've
mirrored. This means the borders no longer line up anyway.
2. Even if a developer removes the list's vertical padding (we set it on
the host
[here](535b8ed724/core/src/components/list/list.md.scss (L9)),
so it's easy to overwrite), inset lists currently have `overflow:
hidden` set
[here](535b8ed724/core/src/components/list/list.scss (L20)),
so the list's border radius still applies correctly even with the items'
border radius removed.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Item border radius in inset lists removed.
When testing locally, you may find it useful to increase the MD border
radius value
[here](535b8ed724/core/src/components/list/list.md.vars.scss (L47))
so it's easier to see.
## 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.
3. Update the BREAKING.md file with the breaking change.
4. 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. -->
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-button` is being used as a way to open the alerts. It's not being
used to test functionality.
When `ion-button` is updated then the screenshots in the alert tests
must be updated. This shouldn't happen when `ion-button` isn't necessary
to have in these tests.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Replaced `ion-button` with `button`
## 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. -->
N/A
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#16304, resolves#20681
---------
<!-- 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. -->
Split Pane assumes that Menu is a child of the Split Pane. This means
that CSS selectors and JS queries only check for children instead of
descendants. When a Menu is encapsulated in a component that component
can itself show up as an element in the DOM depending on the
environment. For example, both Angular and Web components show up as
elements in the DOM. This causes the Menu to not work because it is no
longer a child of the Split Pane.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Menu can now be used as a descendant of Split Pane. The following
changes make this possible:
1. When the menu is loaded, it queries the ancestor Split Pane. If one
is found, it sets `isPaneVisible` depending on if the split pane is
visible or not.
2. Any changes to the split pane visibility state after the menu is
loaded will be handled through the `ionSplitPaneVisible` event.
3. A menu is now considered to be a pane if it is inside of a split pane
4. Related CSS no longer uses `::slotted` which only targets children.
The CSS was moved into the menu stylesheets. I consider the coupling
here to be valuable as menu and split pane are often used together. We
also already have style coupling between the two components, so this
isn't anything new.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
There are no known changes to the public API or public behavior.
However, there are two risks here:
1. There is an unknown risk into how this change impacts nested split
panes. This isn't an explicitly supported feature, but it technically
works in Ionic now. We don't know if anyone is actually implementing
this pattern. We'd like to evaluate use cases for nested split panes
submitted by the community before we try to account for this
functionality in menu and split pane.
5. There may be some specificity changes due to the new CSS. CSS was
moved from split pane to menu so it could work with encapsulated
components:
`:host(.split-pane-visible) ::slotted(.split-pane-side)` has a
specificity of 0-1-1
`:host(.menu-page-visible.menu-pane-side)` has a specificity of 0-1-0
There shouldn't be any changes needed to developer code since the
selectors are in the Shadow DOM and developer styles are in the Light
DOM. However, we aren't able to anticipate every edge case so we'd like
to place this in a major release just to be safe.
## 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.2-dev.11704922151.1fd3369f`
Issue number: None
---------
<!-- 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. -->
Similar to #28809, in my work for FW-5822, I found that I had unexpected
screenshot diffs. `--ion-color-dark` was not defined in our test
infrastructure, and this toggle icon was therefore displaying in the
wrong color in the tests.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Toggle has the correct icon color even when the --ion-color-dark token
is not defined
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
Introduces style changes if the token is undefined, but it should always
be defined in real-world uses.
<!--
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. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: None
---------
<!-- 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 my work for FW-5822, I found that I had unexpected screenshot diffs.
`--ion-color-light` was not defined in our test infrastructure, and the
white fallback for the datetime background was causing snapshots to have
a white background when they should have had a light one.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Datetime has the correct background color even when the
`--ion-color-light` token is not defined
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
Introduces style changes if the token is undefined, but it should always
be defined in real-world uses.
<!--
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. -->
---------
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 team would like to ensure that Ionic Framework components that use
an Ionic color (primary, secondary, etc) on top of a contrast color pass
minimum contrast ratios as defined in the WCAG.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Introduces a revised set of Ionic colors that pass AA color contrast
guidelines when with the appropriate contrast.
## 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. -->
---------
Co-authored-by: Sean Perkins <13732623+sean-perkins@users.noreply.github.com>
Co-authored-by: Brandy Carney <brandy@ionic.io>
Co-authored-by: Sean Perkins <sean@ionic.io>
Co-authored-by: Shawn Taylor <shawn@ionic.io>
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
Co-authored-by: Maria Hutt <thetaPC@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. -->
As part of FW-2832 the team has an initiative to remove much of the
`any` usage in favor of stronger types. This will make modifications to
this codebase safer as we will have access to proper type checking.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed several `any` usages in favor of stronger types.
Note that not all of the `any` types within these files have been
removed. I mainly stuck to the low hanging fruit 😄
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
I intentionally made type changes that do not impact public APIs. Any
incorrect type changes would cause our CI checks to fail.
<!--
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. -->
Issue number: resolves#28762
---------
<!-- 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. -->
Focused inputs have `pointer-events: none`. This code was added in
e27452b789
to address https://github.com/ionic-team/ionic-framework/issues/5536.
However, this causes slotted buttons to not be clickable when the input
is focused because pointer events have been removed.
This also causes the input to blur whenever you tap the label text.
This behavior only exists on `ion-input`. Textarea is not affected.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
This code was added several years ago for the (now) legacy syntax. I
don't have full confidence that this won't break the legacy input
because there's not a lot of context around why specifically this code
was added. As a result, I scoped these styles only to the legacy input.
- Slotted buttons can now be clicked when the input is focused.
- Tapping the label when an input is focused keeps the input focused.
## 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. -->
**Testing:**
1. I manually verified that scroll assist still works with the modern
input.
2. I manually verified that the input remains focused after tapping the
label.
Dev build: `7.6.3-dev.11704229014.12cdc767`
Issue number: resolves#28677
---------
<!-- 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. -->
Defining disabled a `@Prop() disabled = false` causes Stencil to mark
this property as optional. This behavior is not desired on our end, but
making the property required would be a breaking change. Additionally,
the root issue is due to how Stencil resolves types.
For example, `disabled` is [optional in the LocalJSX
namespace](e96a1457a3/core/src/components.d.ts (L6921))
but [required in the Components
namespace](e96a1457a3/core/src/components.d.ts (L2239)).
Addressing this inside of Stencil is significant breaking change. As a
result, the team has decided to compromise and support the falsy
`disabled` state for radio for now. Other Ionic components that support
the `disabled` prop also check for falsy values.
Stencil plans to de-risk this in
https://ionic-cloud.atlassian.net/browse/STENCIL-917.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Radio Group now looks at falsy values instead of strictly checking
`false`.
## 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.2-dev.11703182244.1165aeec`
Issue number: resolves#28737
---------
<!-- 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/28246 we removed
the overflow on Nav and Router Outlet to allow content to flow outside
of these containers. This allows the translucent tab effect to work
(otherwise content would be clipped and there would be no translucency).
However, this had the unintended side effect of causing page transitions
to flow outside of these components. This is most noticeable on larger
displays when using SplitPane because the page can cover the menu
mid-transition.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Overflow is no longer allowed on the main content. I originally set
the overflow on the router outlet/nav itself, but that caused the
translucent tab bar behavior to regress. Since this issue only happens
with split pane, I decided to apply the fix there.
## 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.3-dev.11703103144.148eb1f6`
⚠️ Please test in a physical app too
### Before/After Demo
| `main` | branch |
| - | - |
| <video
src="https://github.com/ionic-team/ionic-framework/assets/2721089/2f3f0d74-9a7e-4ebe-b58a-6e1a6ea3636e"></video>
| <video
src="https://github.com/ionic-team/ionic-framework/assets/2721089/cdbf8fb5-e217-48cf-8c1e-4bdecee4de4c"></video>
|
### Screenshot Diffs
The `menu-custom` screenshot diffs
([Example](https://github.com/ionic-team/ionic-framework/pull/28745/files))
are correct. By adding `overflow: hidden`, the box shadow from the
"Content" header no longer flows outside of the container.
The menu [border on MD has an opacity of
0.18](e5226016a0/core/src/components/menu/menu.md.vars.scss (L7)),
so the border color was mixing with the color of the box shadow from the
header.
Since the shadow no longer flows outside of the container, the border
color does not mix with the box shadow color.
### Does this break translucent tabs when the split pane is inside of a
tab?
No. The [split pane has `contain: strict`
set](e5226016a0/core/src/components/split-pane/split-pane.scss (L24))
which prevents content from flowing under the tab bar, so the
translucent tab bar never worked with this layout.
---------
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 keyboard navigation tests for radio were disable due to flakiness
with Safari when it came to the CI.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Re-enabled the tests.
Debugging was done with a saved artifact.
The artifact didn't provide a clear reason of why it flakes. But it did
seem that the test was tabbing before the Safari page finished loading.
I've added a `waitFor()` to verify that the radios have rendered. This
was done for Safari only to prevent any additional wait time.
## 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. -->
There is no great way to test this since it only flakes on GitHub.
Issue number: resolves#28617
---------
<!-- 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 check to see if `webkitOverflowScrolling` is supported on
the refresher's style object in order to enable to native iOS refresher.
This works well for iOS, but it does not work for iPadOS. This is
because this property was removed in iPadOS 13:
https://developer.apple.com/documentation/safari-release-notes/safari-13-release-notes
> Disabled -webkit-overflow-scrolling: touch on iPad. All frames and
scrollable overflow areas now use accelerated one-finger scrolling
without changing stacking.
As a result, the native iOS refresher does not activate on iPadOS.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- I think it's safe to assume that `webkitOverflowScrolling` may be
removed on iOS in the future too since it was already removed on iPadOS.
As a result, I implemented a solution that avoids checking this.
- The `CSS.supports` check is required because otherwise the native iOS
refresher would be activated in an emulated environment such as Chrome
dev tools because the user agent is spoofed. The `apple-pay-logo-black`
named image is only supported on Apple devices.
Risks:
- Apple could remove the `apple-pay-logo-black` named image in the
future. However, we currently use this check elsewhere in Ionic too and
it has worked well:
60303aad23/core/src/components/datetime/datetime.ios.scss (L177).
- Apple could add touch emulation to desktop Safari which could cause
the native refresher to activate when using responsive design mode for
testing. However, this would only impact app developer and would not
impact production use cases.
## 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.11703088210.14a72b83`
Co-authored-by: Sean Perkins <sean-perkins@users.noreply.github.com>
---------
Co-authored-by: Sean Perkins <sean-perkins@user.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 removed the background color from today's calendar day button if
selected when implementing the calendar-day button shadow part feature:
79b005da70 (diff-8e2912d52559aa44c9c6dc062c8d683e7b51c92c7b7ba420ad6f7587f1e1a61aL139)
We did not catch this because we do not have test coverage for this use
case. We typically avoid rendering datetime on today's date because
"today" could be something totally different depending on the test
machine's locale/configuration.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Adds the background rule that was removed
- Added test coverage. I mocked today's date to be a fixed date so it
never changes
## 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. -->
---------
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. -->
In https://github.com/ionic-team/ionic-framework/issues/28694 there was
some confusion around how to access `this` inside of a callback function
passed to a property on Ionic components. The root issue was due to how
the `this` context is determined with developers being responsible for
setting the appropriate `this` context.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- While this isn't an Ionic bug, I think it's worth calling out this
behavior so developers are aware of how to account for it.
## 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. -->
Note: The link in the docs will not work until
https://github.com/ionic-team/ionic-docs/pull/3333 is merged.
---------
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
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>
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.
