mirror of
https://github.com/ionic-team/ionic-framework.git
synced 2026-03-13 10:22:08 +08:00
507d5ee1dae2d85819ca17332f0a5d03b270104f
3314 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Shawn Taylor
|
fe3c3d500a |
docs(input, searchbar, textarea): improve docs for managing focus (#28614)
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. --> |
||
|
Liam DeBeasi
|
a3cd204f61 |
fix(overlays): trigger is configured on load (#28526)
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. |
||
|
Sean Perkins
|
5c2a73b262 |
chore(playwright): dark mode support (#28593)
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. --> Testing dark mode is manual per test in Playwright. Ionic developer needs to setup the variables and assign them to a selector that applies in the class. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - The `.setContent` API will now work with a new config option to test dark mode automatically without additional configuration/test set-up. - Default theme is no theme (fallback theme) - Screenshot names and test titles remain the same for all existing tests. Only tests that opt into a theme will be pre-pended with `-dark` or `-light` (as an example for current themes). ## 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. --> |
||
|
Sean Perkins
|
bd27846b28 |
chore(playwright): resolve axe violations with setContent (#28592)
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. --> When using `.setContent`, the initial page template is lacking key metadata that will result in AXE violations. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Adds a default `lang` to the `html` document root - Adds a default `title` tag ## 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. --> |
||
|
Shawn Taylor
|
01130e12e1 |
fix(datetime): allow disabling datetime with prefer-wheel (#28511)
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> |
||
|
Sean Perkins
|
b833f0e826 |
fix(alert): date inputs render correctly in mobile safari (#28495)
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> |
||
|
Liam DeBeasi
|
388d19e04f |
fix(datetime): updating value with min scrolls to new value (#28549)
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> |
||
|
Sean Perkins
|
4f1b4cdc29 |
chore(core): type checking for unit tests (#28529)
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. |
||
|
Liam DeBeasi
|
6a2be9fa3c |
fix(alert): match MD spec on tablet (#28501)
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> |
||
|
Mohamed Ben Makhlouf
|
a000dd2c0b |
fix(accordion-group): correct accordion is open on load (#28510)
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](
|
||
|
Liam DeBeasi
|
342511959a |
chore(datetime): remove unused code (#28502)
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. --> |
||
|
Brandy Carney
|
900267eb36 |
fix(action-sheet): adjust height for safe area with scrollable options (#28504)
Issue number: fixes #27777 --------- ## What is the current behavior? When safe area (top/bottom) is applied to an action sheet with scrollable options and a cancel button, the cancel button is pushed off the screen and cannot be reached. ## What is the new behavior? Properly adjust the height of the action sheet container to account for the top and bottom safe area. ## Does this introduce a breaking change? - [ ] Yes - [x] No ## Other information The below screenshots use the following CSS when safe area is added so it is expected that the action sheet will adjust the top and bottom: ```css :root { --ion-safe-area-top: 60px; --ion-safe-area-bottom: 40px; } ``` ### iOS | | Before (`main`) | After (`FW-4715`) | | -------------------| ----------------| ------------------| | **No** Safe Area |  |  | | **Safe Area** |  |  | ### Material Design | | Before (`main`) | After (`FW-4715`) | | -------------------| ----------------| ------------------| | **No** Safe Area |  |  | | **Safe Area** |  |  | --------- Co-authored-by: ionitron <hi@ionicframework.com> |
||
|
Maria Hutt
|
73b8bfde3f |
fix(radio-group): emit value change on componentDidLoad (#28488)
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]( |
||
|
Liam DeBeasi
|
8227b0ee6d |
fix(header): collapsible large title does not flicker when collapse prop not reflected (#28472)
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> |
||
|
Liam DeBeasi
|
c053fd9c68 |
fix(searchbar): cancel icon aligns with back button (#28478)
Issue number: resolves #28468 --------- <!-- Please do not submit updates to dependencies unless it fixes an issue. --> <!-- Please try to limit your pull request to one type (bugfix, feature, etc). Submit multiple pull requests if needed. --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying. --> The cancel button in the searchbar used to align with the back button, but that behavior gradually regressed between Ionic v4 and Ionic v7. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Adjusted the padding on the searchbar back button - Reduced the size of the searchbar back button. It was currently set to 25.6px whereas the `ion-back-button` icon was 24px. This caused the icons to never align even with 9px. (This should cause a few additional diffs) - Added a screenshot test | v4 | v5 | v6 | v7 | branch | | - | - | - | - | - | |  |  |  |  |  | Note that in v4 the alignment was slightly off. It was fixed in v5, but then broke in v6 and remained unchanged in v7 (until now). ## Does this introduce a breaking change? - [ ] Yes - [x] No <!-- If this introduces a breaking change, please describe the impact and migration path for existing applications below. --> ## Other information <!-- Any other information that is important to this PR such as screenshots of how the component looks before and after the change. --> Dev build: `7.5.4-dev.11699310489.151b2717` --------- Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com> Co-authored-by: ionitron <hi@ionicframework.com> |
||
|
Shawn Taylor
|
4513e0c6b0 |
fix(item-divider): apply safe area to proper side regardless of direction (#28420)
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> |
||
|
Brandy Carney
|
c765dcbac4 |
fix(inputs): remove invalid legacy warnings in input, textarea, and select (#28484)
Issue number: N/A
---------
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
When using an `ion-label` as a `label` slot inside of an `ion-input`,
`ion-textarea` or `ion-select` it erroneously flags the input as a
legacy component and ignores the `label-placement`:
<table>
<tr>
<td>
Code
</td>
<td>
Result
</td>
</tr>
<tr>
<td>
<pre lang="html">
<ion-item>
<ion-input label-placement="floating">
<ion-label slot="label">
<ion-icon name="home"></ion-icon>
Slotted Label
</ion-label>
</ion-input>
</ion-item>
<ion-item>
<ion-input label-placement="floating" value="Value">
<ion-label slot="label">
<ion-icon name="person"></ion-icon>
Slotted Label
</ion-label>
</ion-input>
</ion-item>
</pre>
</td>
<td>
<img
src="https://github.com/ionic-team/ionic-framework/assets/6577830/91ef5470-aba4-4bb6-b277-09e2b1a4650c">
</td>
</tr>
</table>
<img width="1005" alt="Screenshot 2023-11-07 at 10 37 43 AM"
src="https://github.com/ionic-team/ionic-framework/assets/6577830/00208625-2bdb-4b60-b7ce-e487dd89c47e">
## What is the new behavior?
Adds `ion-input`, `ion-textarea`, and `ion-select` as components that
can contain a named label slot so it no longer assumes that they are
legacy components.
<table>
<tr>
<td>
Code
</td>
<td>
Result
</td>
</tr>
<tr>
<td>
<pre lang="html">
<ion-item>
<ion-input label-placement="floating">
<ion-label slot="label">
<ion-icon name="home"></ion-icon>
Slotted Label
</ion-label>
</ion-input>
</ion-item>
<ion-item>
<ion-input label-placement="floating" value="Value">
<ion-label slot="label">
<ion-icon name="person"></ion-icon>
Slotted Label
</ion-label>
</ion-input>
</ion-item>
</pre>
</td>
<td>
<img
src="https://github.com/ionic-team/ionic-framework/assets/6577830/75f06c5e-6887-4e8e-8022-264b716b3e62">
</td>
</tr>
</table>
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
|
||
|
Liam DeBeasi
|
cafafcc9d1 |
fix(list): remove border from last item with item-sliding (#28439)
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> |
||
|
Shawn Taylor
|
00c3a4431a |
test(picker-internal): reduce flakiness of picker internal screenshot test (#28456)
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. --> |
||
|
Shawn Taylor
|
ed040b09e9 |
fix(item): apply safe area to proper side regardless of direction (#28403)
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> |
||
|
Shawn Taylor
|
f6a6877044 |
fix(datetime): allow calendar navigation in readonly mode; disallow keyboard navigation when disabled (#28336)
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> |
||
|
Liam DeBeasi
|
b31ecbbfe8 |
fix(input, textarea, select): use consistent sizes (#28390)
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> |
||
|
Liam DeBeasi
|
dc94ae01fe |
test(alert): add annotations (#28414)
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. --> |
||
|
Liam DeBeasi
|
8e2f818671 |
fix(segment): avoid scrolling webkit bug (#28376)
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
|
||
|
Liam DeBeasi
|
34257d681e |
fix(alert): long words wrap to next line (#28408)
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> |
||
|
Brandy Carney
|
d47b7e7503 |
fix(tab-bar): apply safe area to proper side regardless of direction (#28372)
Issue number: Internal --------- ## What is the current behavior? The safe area padding (both left and right) swap sides when the app's direction changes from LTR to RTL. The `--ion-safe-area-left` should always apply to the left side of the device and the `--ion-safe-area-right` should always apply to the right side of the device. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Updates the tab bar stylesheet to always set `padding-left` and `padding-right` - Adds an e2e test for the basic directory which adds screenshots in both modes/directions for: - the default tab bar - a tab bar with safe area left applied - a tab bar with safe area right applied ## Does this introduce a breaking change? - [ ] Yes - [x] No --------- Co-authored-by: ionitron <hi@ionicframework.com> |
||
|
Brandy Carney
|
f99d5305fb |
fix(list-header): apply safe area to proper side regardless of direction (#28371)
Issue number: Internal --------- ## What is the current behavior? The list header adds padding to the "start" side (`padding-left` in LTR and `padding-right` in RTL) based on the value of `--ion-safe-area-left`. It does not account for `--ion-safe-area-right` at all even though the list header can extend to the right side of the content. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - The `--ion-safe-area-left` always applies to the left side of the screen, regardless of direction. This means that in both LTR and RTL it applies as `padding-left`. - Added support for `--ion-safe-area-right` which applies to `padding-right` in both LTR and RTL. - Adds an e2e test which captures the list header with a button to ensure the proper padding is added for the safe area. ## Does this introduce a breaking change? - [ ] Yes - [x] No ## Other information ### Safe Area Left | mode | direction | `main` | `branch` | | ---| ---| ---| ---| | `ios` | `LTR` |  |  | | `ios` | `RTL` |  |  | | `md` | `LTR` |  |  | | `md` | `RTL` |  |  | ### Safe Area Right | mode | direction | `main` | `branch` | | ---| ---| ---| ---| | `ios` | `LTR` |  | | | `ios` | `RTL` |  |  | | `md` |`LTR` |  |  | | `md` |`RTL` |  |  | --------- Co-authored-by: ionitron <hi@ionicframework.com> |
||
|
dependabot[bot]
|
026efeb0a8 |
chore(deps): Bump @stencil/core from 4.5.0 to 4.6.0 in /core (#28400)
Bumps [@stencil/core](https://github.com/ionic-team/stencil) from 4.5.0 to 4.6.0. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/ionic-team/stencil/blob/main/CHANGELOG.md"><code>@stencil/core</code>'s changelog</a>.</em></p> <blockquote> <h1>💥 <a href="https://github.com/ionic-team/stencil/compare/v4.5.0...v4.6.0">4.6.0</a> (2023-10-23)</h1> <h3>Bug Fixes</h3> <ul> <li><strong>compiler:</strong> consistently generate additional type files (<a href="https://redirect.github.com/ionic-team/stencil/issues/4938">#4938</a>) (<a href=" |
||
|
Maria Hutt
|
60f3d65794 |
fix(alert, action-sheet): show scrollbar for long list of options (#28369)
Issue number: resolves #18487 --------- <!-- 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. --> Web-based users do not get a scrollbar when: - alert has a long list of inputs (this also happens on `ion-select` with the alert interface) - `ion-select` uses the action-sheet interface and has a long list of options This makes it difficult for users to navigate through the options by forcing them to use their keyboards. Some users may also not be used to using their keyboards for navigation. Additionally, this can lead to potential confusion that there are no other options. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> Web-based users get a scrollbar when: - alert has a long list of inputs (this also happens on `ion-select` with the alert interface) - `ion-select` uses the action-sheet interface and has a long list of options ## 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 issue was filed for the alert interface but it's also happening on the action-sheet interface. Dev build: 7.5.1-dev.11697570585.1774584d |
||
|
Maria Hutt
|
7ecd41f385 |
test(radio): skip Safari on legacy tab key tests (#28387)
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. --> Legacy radio has tests that use `Tab` key presses. These tend to flake at unknown moments and were skipped until a fix can be implemented. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> Unable to replicate the flakiness locally or on GitHub. However, it only fails on Safari so the tests were re-enabled except for 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. --> This only happens on legacy. The legacy form controls will also be removed in the future. Due to this, these tests will be removed anyways at that time. |
||
|
Maria Hutt
|
2b015b2214 |
fix(input, searchbar, textarea): ensure nativeInput is always available (#28362)
Issue number: resolves #28283 --------- <!-- 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. --> `getInputElement()` is used to access the native input. If the component has yet to render, then the function will return `undefined`. This happens mostly when using `ref` on React. ```tsx <IonInput ref={async input => { const nativeInput = await input.getInputElement(); // nativeInput is undefined }} /> ``` ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - `getInputElement()` will wait to return once the component is ready. ## 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.1-dev.11697488622.175c9183` |
||
|
Liam DeBeasi
|
15a02253d3 |
chore: add stronger types to several files (#28347)
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 would like to swap out usages of the any type for stronger types. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> |
||
|
Amanda Johnston
|
331c08aad5 |
fix(fab): apply safe area in positioning to proper side regardless of direction (#28377)
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 calculating the fab's horizontal position, the safe area is taken into account. However, which safe area side is applied changes depending on whether the document's direction is LTR or RTL. This is incorrect as the left safe area padding will always be on the left side regardless of direction, and vice versa. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> The left safe area is always applied to the fab's `left` position, and vice versa. ## 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> |
||
|
Liam DeBeasi
|
c801e2ada9 |
chore: remove unused sass variables (#28363)
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. --> This project has several unused Sass variables still in the code base. The team would like to remove these. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Removed unused Sass variables ## 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 original scope of this ticket was for checkbox only, but many other components had unused sass variables, so I decided to tackle everything all at once. Since these variables are not used anywhere: 1. The build should pass 2. There should be no screenshot diffs |
||
|
Liam DeBeasi
|
5a30082546 |
fix(menu): menu no longer disappears with multiple split panes (#28370)
Issue number: resolves #18683, resolves #15538, resolves #22341 --------- <!-- 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. --> Menus in a split pane are hidden when a second split pane is mounted/made visible. This is because the `onSplitPaneChanged` callback does not take into account whether the it is a child of the split pane that emitted `ionSplitPaneVisible`. When split pane 2 is shown, that causes the menu is split pane 1 to hide. When split pane 1 is shown, the menu inside of it _is_ shown. However, since split pane 2 is then hidden that component also emits `ionSplitPaneVisible`, causing the menu inside of split pane 1 to hide. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Menus are only hidden when its parent split pane changes visibility ## 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.1-dev.11697568647.1ac87d08` --------- Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com> |
||
|
Maria Hutt
|
6b7d288536 |
fix(rtl): allow :host to use rtl() (#28353)
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 a safe area padding mixin, I realized that `rtl()`
wasn't being applied for `:host` when using Firefox or Safari. This is
happening because the syntax for `:dir()` is wrong. The placement needs
to be updated for Firefox and Safari to register it.
```scss
:host {
@include rtl() { // <- won't work
// styles
}
}
// generates
:host-context([dir=rtl]) {
// styles
}
:host:dir(rtl) { // <- wrong syntax
// styles
}
```
```scss
:host(.class) {
@include rtl() { // <- won't work
// styles
}
}
// generates
:host-context([dir=rtl]):host(.class) {
// styles
}
:host-context([dir=rtl]).class {
// styles
}
:host(.class):dir(rtl) { // <- wrong syntax
// styles
}
```
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
I updated `rtl()` to use `:dir()` as the `addHostSelector` in the
`add-root-selector` function. This generates all the correct selectors
for Firefox and Safari. However, `:dir()` does not have the structure of
`:host-context()` so I had to add a new parameter to `add-root-selector`
to determine whether to use `:host-context()` or not. I set the default
to `true` since the function originally used `:host-context()`.
An extra win is that the updated function will be ready for when
`:host-context()` can be removed from the codebase.
```diff
:host {
@include rtl() { // <- works
// styles
}
}
// generates
:host-context([dir=rtl]) {
// styles
}
- :host:dir(rtl) {
+ :host(:dir(rtl)) {
// styles
}
```
```diff
:host(.class) {
@include rtl() { // <- works
// styles
}
}
// generates
:host-context([dir=rtl]):host(.class) {
padding-right: 40px;
}
:host-context([dir=rtl]).class {
// styles
}
- :host(.class):dir(rtl) {
+ :host(.class:dir(rtl)) {
// styles
}
```
## 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. -->
N/A
---------
Co-authored-by: ionitron <hi@ionicframework.com>
|
||
|
Brandy Carney
|
416bb736a1 |
refactor(item-sliding): remove unused CSS from item options (#28367)
Issue number: Internal --------- ## What is the current behavior? Item sliding has some unused CSS and no tests for safe area padding based on the direction. This CSS is not used: |
||
|
dependabot[bot]
|
3d96ccb7b2 |
chore(deps-dev): Bump @playwright/test from 1.38.1 to 1.39.0 in /core (#28339)
Bumps [@playwright/test](https://github.com/microsoft/playwright) from 1.38.1 to 1.39.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/microsoft/playwright/releases"><code>@playwright/test</code>'s releases</a>.</em></p> <blockquote> <h2>v1.39.0</h2> <h2>Add custom matchers to your expect</h2> <p>You can extend Playwright assertions by providing custom matchers. These matchers will be available on the expect object.</p> <pre lang="js"><code>import { expect as baseExpect } from '@playwright/test'; export const expect = baseExpect.extend({ async toHaveAmount(locator: Locator, expected: number, options?: { timeout?: number }) { // ... see documentation for how to write matchers. }, }); <p>test('pass', async ({ page }) => { await expect(page.getByTestId('cart')).toHaveAmount(5); }); </code></pre></p> <p>See the documentation <a href="https://playwright.dev/docs/test-configuration#add-custom-matchers-using-expectextend">for a full example</a>.</p> <h2>Merge test fixtures</h2> <p>You can now merge test fixtures from multiple files or modules:</p> <pre lang="js"><code>import { mergeTests } from '@playwright/test'; import { test as dbTest } from 'database-test-utils'; import { test as a11yTest } from 'a11y-test-utils'; <p>export const test = mergeTests(dbTest, a11yTest); </code></pre></p> <pre lang="js"><code>import { test } from './fixtures'; test('passes', async ({ database, page, a11y }) => { // use database and a11y fixtures. }); </code></pre> <h2>Merge custom expect matchers</h2> <p>You can now merge custom expect matchers from multiple files or modules:</p> <pre lang="js"><code>import { mergeTests, mergeExpects } from '@playwright/test'; import { test as dbTest, expect as dbExpect } from 'database-test-utils'; import { test as a11yTest, expect as a11yExpect } from 'a11y-test-utils'; <p>export const test = mergeTests(dbTest, a11yTest); </tr></table> </code></pre></p> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Liam DeBeasi
|
fe47594dc0 |
feat(title): large title transition supports dynamic font scaling (#28290)
Issue number: resolves #28351 --------- <!-- 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 collapsible large title transition does not support Dynamic Font Scaling as the position values are all hardcoded. Additionally, I noticed that the title and the text do not align very well even at the default font scale. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> I made a few changes to support Dynamic Font Scaling, fix the default scale alignment, and generally make this code easier to maintain (or at least I hope it will): 1. Removed most hardcoded values in favor of bounding box calculations. The hardcoded values that remain have comments explaining what they are. 2. Modified the back button animation so the container handles the translation and have the back button text animation handle its scale. Having the back button text handle the translation and the scale at the same time made it hard to figure out what the correct values should be. 3. Added a lot of comments explaining what we are doing/why **When the Large Title and Back Button Texts Do Not Match** | `FW-4146` (default) | branch (default) | `FW-4146` (scaled) | branch (scale) | | - | - | - | - | | <video src="https://github.com/ionic-team/ionic-framework/assets/2721089/a6261499-c5ca-4ee3-af62-fa124718ca46"></video> | <video src="https://github.com/ionic-team/ionic-framework/assets/2721089/0648c0b1-e1f8-43c1-9e7e-91489cc8ec4a"></video> | <video src="https://github.com/ionic-team/ionic-framework/assets/2721089/0def6d88-22d0-48b9-98b3-0ed2bbb407aa"></video> | <video src="https://github.com/ionic-team/ionic-framework/assets/2721089/3650ceb1-f4cb-4530-b7c6-17194f4ccd66"></video> | **When the Large Title and Back Button Texts Do Match** | `FW-4146` (default) | branch (default) | `FW-4146` (scaled) | branch (scale) | | - | - | - | - | | <video src="https://github.com/ionic-team/ionic-framework/assets/2721089/2b8035a4-81aa-4901-99e1-fd49db1fd0d7"></video> | <video src="https://github.com/ionic-team/ionic-framework/assets/2721089/e3c66978-2015-484e-b337-73ac1c4c02a1"></video> | <video src="https://github.com/ionic-team/ionic-framework/assets/2721089/437483a8-2495-4c54-9c27-47c91af4c562"></video> | <video src="https://github.com/ionic-team/ionic-framework/assets/2721089/05ef08b0-cf0d-469d-8834-533071a8c583"></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. --> Note that the alignment of the title/button will not exactly match native iOS. The goal of this PR is to get something that is pretty close (similar to how it was when we originally implemented this) --------- Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com> |
||
|
Liam DeBeasi
|
fa78676d57 |
fix(angular): do not create duplicate menuController instances (#28343)
Issue number: resolves #28337
---------
<!-- 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. -->
Duplicate instances of `menuController` are being created in
`@ionic/angular`. `ion-menu` registers itself in the `menuController`
from `@ionic/core`, but the `MenuController` from `@ionic/angular` uses
the `menuController` from `@ionic/core/components`. This is how the
overlay providers work too. Normally, this is not a problem. However,
`menuController` caches references to registered menus in each
controller instances:
|
||
|
Liam DeBeasi
|
dc2f55f0fb | chore: sync with main | ||
|
Liam DeBeasi
|
f8067819ee |
feat(a11y): add dynamic font scaling (#28314)
Issue number: resolves #24638, resolves #18592 --------- <!-- 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 have requested that Ionic Framework support the dynamic type feature on iOS for accessibility purposes. Ionic applications do not respond to font scaling on iOS which can create inaccessible applications particularly for users with low vision. Ionic apps on Android devices currently support the Android equivalent due to functionality in the Chromium webview. Developers have also requested a way of adjusting the fonts in their Ionic UI components consistently. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Ionic components now use `rem` instead of `px` where appropriate. This means devs can change the font size on `html` and the text in supported Ionic components will scale up/down appropriately - Add support for Dynamic Type on iOS (the iOS version of Dynamic Font Scaling) ## 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: Maria Hutt <thetaPC@users.noreply.github.com> Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com> Co-authored-by: Shawn Taylor <shawn@ionic.io> Co-authored-by: ionitron <hi@ionicframework.com> Co-authored-by: Sean Perkins <sean@ionic.io> Co-authored-by: Sean Perkins <13732623+sean-perkins@users.noreply.github.com> Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com> |
||
|
Liam DeBeasi
|
eee2115fd2 |
fix(select): do not focus disabled popover option (#28309)
Issue number: resolves #28284 --------- <!-- 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 focuses the first popover option when no value is provided. This means that the first option is focused even if it disabled. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Select focuses the first **enabled** popover option when no value is provided. ## 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: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com> |
||
|
Liam DeBeasi
|
4f43d5ce08 |
fix(menu) menus on the same side are not automatically disabled (#28269)
Issue number: resolves #18974 --------- <!-- 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 multiple menus on the same `side` are registered, all but the most recent menu are disabled. For example, if a user starts on PageA with a `start` menu and then navigates to PageB which also has a `start` menu, then the menu on PageA will be disabled. The problem is that if users navigates back to PageA they will be unable to open the menu on that view because it is still disabled. This behavior impacts any Ionic developer trying to open a menu whether by calling the `open` method on the menu itself or on the `menuController`. After discussing with the team, we believe the original intent of this behavior was to prevent users from accidentally opening the wrong menu when calling `menuController.open('start')`. This API allows developers to reference a menu by side, and since it's possible to have multiple menus on the same side it's also possible to open the wrong menu when referencing by side only. However, this API starts to break down pretty quickly in a navigation scenario. Sample Repo: https://github.com/liamdebeasi/multiple-menu-bug-repro ## Scenario 1: Referencing Menu by Side 1. On the "home" route click "Open 'start' menu". Observe that the home page menu opens. 2. Close the menu and click "Go to Page Two". 3. On the "page-two" route click "Open 'start' menu". Observe that the page two menu opens. 4. Go back to "home". 5. Click "Open 'start' menu". Observe that nothing happens. 6. Click "Enable and Open 'start'" Menu". Observe that the home menu opens. ## Scenario 2: Referencing Menu by ID 1. On the "home" route click "Open '#menu1' menu". Observe that the home page menu opens. 2. Close the menu and click "Go to Page Two". 3. On the "page-two" route click "Open '#menu2' menu". Observe that the page two menu opens. 4. Go back to "home". 5. Click "Open '#menu1' menu". Observe that nothing happens. 6. Click "Enable and Open '#menu1'" Menu". Observe that the home menu opens. ## Scenario 3: Using 3 or more menus even when enabling menus 1. On the "home" route click "Open 'start' menu". Observe that the home page menu opens. 2. Close the menu and click "Go to Page Two". 3. On the "page-two" route click "Open 'start' menu". Observe that the page two menu opens. 4. Close the menu and click "Go to Page Three" 5. On the "page-three" route click "Open 'start' menu". Observe that the page three menu opens. 6. Go back to "page-two". 8. Click "Open 'start' menu". Observe that nothing happens. 9. Click "Enable and Open 'start' Menu". Observe that nothing happens. The menu controller attempts to find an enabled menu on the specified side: |
||
|
Liam DeBeasi
|
8601977aa7 | chore: update to latest ionicons (#28315) | ||
|
Liam DeBeasi
|
c70432e693 |
fix(checkbox, radio, toggle): disabled elements are not interactive (#28294)
Issue number: resolves #28293 --------- <!-- 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. --> Disabled toggles, radios, and checkboxes can still be enabled by manually dispatching a click event on them. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Toggles, radios, and checkboxes no longer activate if `disabled` is set to `true` ## 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.4.4-dev.11696545130.1171e7a9` |
||
|
Liam DeBeasi
|
c37b3d8bf4 | fix(toast): toast does not warn when positionAnchor is undefined (#28312) | ||
|
Liam DeBeasi
|
b5261e0f41 | Merge remote-tracking branch 'origin/main' into sync-feature-7.5-109 | ||
|
Liam DeBeasi
|
a1690441e5 |
fix(menu): do not error if disabled or swipeGesture is changed mid-animation (#28268)
Issue number: resolves #20092, resolves #19676, resolves #19000 --------- <!-- 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. --> Menu is currently throwing errors because it expects no animations to be running when any state changes happen (such as changing `disabled` or `swipeGesture`). For example, if you set `swipeGesture="false"` mid-gesture then the menu will error. Alternatively, if you set `disabled="true"` mid-open animation then the menu will error also. This is undesirable because it can cause visual flickering and other undesirable behaviors as noted in the linked threads. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Any in-progress animation is cancelled if the state updates such that the animation is no longer relevant (i.e. `disabled` is set to `true` while the menu is opening) - Removed relevant assertions - Added tests ## 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.4.3-dev.11696264821.1755dd6a` |
||
|
Francisco Pladano
|
6da82aab81 |
feat(angular, react, vue, core): export openURL utility (#28295)
Issue number: resolves #27911 --------- <!-- 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 `openURL` utility is not available to developers. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Export `openURL` utilities from `@ionic/core`, `@ionic/angular`, `@ionic/react` and `@ionic/vue`. ## 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. --> |