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#28399
---------
<!-- 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/26976 I
fixed an issue where `pointer-events: none` was not applied until after
the menu open gesture finishes. This resolved a bug where scrolling was
latching after the menu gesture starts.
However, I did not account for the edge case where scrolling latches
_before_ `pointer-events: none` is applied in the DOM. Since scrolling
has already latched then `pointer-events: none` does not change the
scrolling behavior. This can happen if a user swipes up and to the right
from the left edge of the screen.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `overflow-y: hidden` is now applied to the scrollable content which
will interrupt any scrolling when the menu is open.
## 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:
This bug fixes a timing issue where scrolling latches on the main
content as the menu tries to open. As a result, I am unable to write
reliable automated tests for this. Reviewers should perform the
following test on iOS and Android physical devices:
1. Open `src/components/menu/test/basic`.
2. Add enough elements to the main page content such that it scrolls (I
added a list with items).
3. On each device, attempt to scroll the main content while also opening
the menu on the starting edge of the screen.
Scrolling on the main content should not happen if the menu opens.
Dev build: `7.6.5-dev.11705341148.1a550d3b`
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: N/A
---------
## What is the current behavior?
The `system` and `always` dark theme files target the mode-specific
styles by using the following selectors:
```scss
:root {
@include dark-base-theme();
}
.ios body {
@include dark-ios-theme();
}
.md body {
@include dark-md-theme();
}
```
This is an issue because then users **cannot** override the dark theme
by targeting `:root.ios`, they must target the `body`.
## What is the new behavior?
Updates the mode selectors to target the `:root` with the mode-specific
class:
```scss
:root {
@include dark-base-theme();
}
:root.ios {
@include dark-ios-theme();
}
:root.md {
@include dark-md-theme();
}
```
This makes more sense, since we want it to still be global but
mode-specific, and allows users to override it on `:root` if desired.
## Does this introduce a breaking change?
- [ ] Yes
- [x] Maybe
- [ ] No
BREAKING CHANGES:
In previous versions, it was recommended to define the dark theme in the
following way:
```css
@media (prefers-color-scheme: dark) {
body {
/* global app variables */
}
.ios body {
/* global ios app variables */
}
.md body {
/* global md app variables */
}
}
```
In Ionic Framework version 8, the dark theme is being distributed via
css files that can be imported. Below is an example of importing a dark
theme file in Angular:
```css
/* @import '@ionic/angular/css/themes/dark.always.css'; */
/* @import "@ionic/angular/css/themes/dark.class.css"; */
@import "@ionic/angular/css/themes/dark.system.css";
```
By importing the `dark.system.css` file, the dark theme variables will
be defined like the following:
```css
@media (prefers-color-scheme: dark) {
:root {
/* global app variables */
}
:root.ios {
/* global ios app variables */
}
:root.md {
/* global md app variables */
}
}
```
Notice that the dark theme is now applied to the `:root` selector
instead of the `body` selector. The
[`:root`](https://developer.mozilla.org/en-US/docs/Web/CSS/:root)
selector represents the `<html>` element and is identical to the
selector `html`, except that its specificity is higher.
While migrating to include the new dark theme files is unlikely to cause
breaking changes, these new selectors can lead to unexpected overrides
if custom CSS variables are being set on the `body` element. We
recommend updating any instances where global application variables are
set to target the `:root` selector instead.
For more information on the new dark theme files, refer to the [Dark
Mode documentation](https://ionicframework.com/docs/theming/dark-mode).
## Other Information
Dev build: `7.6.2-dev.11705355381.14b22962`
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: 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 light theme tokens are included in the starter apps but not in Ionic
Framework itself.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The light mode tokens are bundled with Ionic Framework. This allows
developers to always have the light mode accessible to them including
the tokens.
## 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: 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: 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. -->
Our theme tests currently consume an internal dark theme. This was
needed to add light/dark theme tests prior to us shipping separate
stylesheets to developers. However, now that these stylesheets have been
created we should always be testing with them so we can catch any bugs
in the dark mode stylesheet.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Remove the custom dark.css file and removed references to it
- Added a TODO to do the same thing for the light theme once FW-5862 is
done.
## 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: 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: 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. -->
Ionic's progress bar implementation deviates from the appearance of a
progress bar on iOS 17.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Progress bar is updated to have rounded corners (around the
container).
- Increases progress bar height to `4px`
- Solid progress bars (progress bars with a buffer value of `1`) will
have a consistent background appearance.
- Buffer progress bars will continue to have the colored background
appearance as they do in v7.
## 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.
-->
### Breaking Changes
- `--buffer-background` has been removed in favor of `--background`.
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Accomplishing rounded caps for the inner progress with Ionic's scale
transformation was not viable. To maintain 60fps animations for the
progress, rounded corners were applied to the container.
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Liam DeBeasi <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. -->
The searchbar implementation for Ionic's iOS mode does not align with
the appearance of a native search control in iOS 17.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The spacing between the searchbar and the cancel button has increased
to `12px`.
- The cancel button font size has increased to `17px`.
|iOS 17|Ionic|Diff|
|----|----|----|
||||
- Ionic's text and background color is different than iOS, this is
expected. Ionic uses the `$text-color-rgb`, which is compatible with
dark mode appearance. Ionic does not currently have rgb variables for
step colors to closer align to iOS color when requiring opacity.
- iOS reference image is from the Notes app. Ionic reference image is
from `searchbar/test/basic`, with a modified content background color of
`#f2f2f7` to closer align to the Notes app.
## 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. -->
The additional screenshot diffs that are a part of this PR are valid
changes. When updating the color palette for AA contrast, these
reference images were not updated. We currently use a
[threshold](dc1dd9c395/core/playwright.config.ts (L57))
that determines if a diff exists. The reason that they show up in this
PR is because I manually deleted the reference images and forced new
references. As such the text color changes you see here are actually
from the AA contrast changes.
---------
Co-authored-by: ionitron <hi@ionicframework.com>
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: 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 card presentation of a presented view from a modal does not match
iOS 17 design.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updates the transform scale of the presenting element with a modal to
have a similar width to iOS 17. In my discovery `0.91` is the closest
scale value.
- The presenting element refers to the view pushed behind the modal when
displayed with a card appearance.
|iOS|Ionic|Diff|
|----|----|----|
||||
The iOS reference is from the Events app, when creating a new event. The
Ionic reference is from the `modal/tests/card` example in the repository
(with the changes in this PR).
## 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: 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. -->
Tab Button icons on iOS are all 30px font size with or without a label.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Tab button icons are still 30px font size when there is no label
- Tab button icons are 24px font size when there is a label
## 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: 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 Toggle styles do not match iOS 17.
| iOS 17 Screenshot | New Design | Ionic |
| --------------------------------------------- |
------------------------------------------------------- |
------------------------------------------------- |
| 
| 
| 
|
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The Toggle handle box shadow matches iOS 17 specs
- The Toggle height matches iOS 17 specs
## 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>
