BREAKING CHANGE: `ion-picker` and `ion-picker-column` have been renamed to `ion-picker-legacy` and `ion-picker-legacy-column`, respectively. This change was made to accommodate the new inline picker component while allowing developers to continue to use the legacy picker during this migration period.
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: 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: 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>
aIssue number: resolves#28388
---------
<!-- 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 added a `min-height: 56px` to the input, textarea, and select
components for MD mode. However, these were added for the outline/solid
style inputs to align with the Material Design spec:
https://material-components.github.io/material-components-web-catalog/#/component/text-field
They should not apply to regular inputs in an item. The end result is
inconsistently sized items when used with non-control items.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Non-filled and non-stacked/floating label controls are now have a
minimum height of 44px.
There should be **no changes** to the following types of controls:
1. iOS controls (all variants)
2. MD filled controls
3. MD stacked controls
## 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.2-dev.11697818830.1a33c881`
---------
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. -->
I forgot to add annotations to tests to indicate the bug fix they are
validating: https://github.com/ionic-team/ionic-framework/pull/28408
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Added annotations
## 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#28373
---------
🚨 Reviewers: Please test this on Chrome, Firefox, and Safari
<!-- 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 fix in
1167a9325f
uncovered a WebKit bug where scrolling an element using `scrollIntoView`
during an accelerated transition causes the segment to jump during the
transition. `scrollIntoView` can cause parent elements to also scroll,
and given that the entering view begins outside the viewport, it's
possible this triggered some sort of WebKit bug where it was trying to
scroll the element into view.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updated the internal implementation to use `scrollBy` instead of
`scrollIntoView`. `scrollBy` does not attempt to scroll parent elements
which avoids the WebKit issue.
- I also updated the initial scroll to be instant rather than smoothly
scroll. If a segment is added to the DOM, I'd expect it to be added with
the correct scroll position (after the first render that is), so
animating on load seemed like a strange behavior. User interaction will
continue to use smooth scrolling though.
## 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.2-dev.11697638908.1f04980a`
Issue number: resolves#28406
---------
<!-- 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 https://github.com/ionic-team/ionic-framework/pull/27898 we
updated the radio and checkbox labels to wrap to the next line instead
of truncate. However, we did not consider long words. As a result, long
words run outside of the container.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The radio and checkbox labels now break on words too in addition to
white space characters.
## 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>
