mirror of
https://github.com/ionic-team/ionic-framework.git
synced 2026-03-13 10:22:08 +08:00
814c2e5ccd6d5bfda12bdf13a566cd66ff830d5b
246 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
José Rio
|
49f96d7f1e |
fix(overlays,picker): remove invalid aria-hidden attribute (#30563)
Issue number: resolves #30040 --------- ## What is the current behavior? - The usage of `aria-hidden="true"` attributes both on overlay and picker components was causing some console error/warnings messages. - This was being caused due the fact of the activeElement (focused element) was inside those elements with this attribute that's equal to true in all cases.  ## What is the new behavior? - There is no need of making usage of this attribute due the facts: - 1. Once overlay is closed the focus will be redirect to the element that triggers the overlay, this way screen readers will be also redirected to the same context of focused element. - 2. After overlay is closed, it will be set as a `display: none;` through the selector `:host(.overlay-hidden)`, which by itself will disable overlay content for the screen readers. - Removed overlay tests since they were basically checking about `aria-hidden` attribute. - Updated PickerColumn and PickerColumnOption structure in order to fit the a11y needs. - Added a focus management system to better drive users when making usage of keyboard navigation inside picker. - Skip A11Y test validation when reported violation is color contrast related. ### ⚠️ NOTE: - Reported devTools issue/warning when selecting picker is **from now on** expected due to focus an input that's set with `tabIndex="-1"` and `aria-hidden="true"` - Which turns into an A11Y violation when it gets focused. It happens that it gets focused dynamically in order to open the native numeric keyboard **once user selects highlighted picker values zone**, in order to allow users to insert numeric values through the keyboard. If this `aria-hidden` and `tabindex` are removed/updated, the existing functionality will be lost since ScreenReaders will start to ignore the updated value through the PickerChange and will be focused onto the focused input. This mentioned input has an onChange event that's used to update the `aria-valuetext` on each `picker-column` which is being capture by the ScreenReader. That said, this new devTools reported issue/warning is a false positive since A11Y behaviour is being covered through a different perspective. ## Does this introduce a breaking change? - [ ] Yes - [X] No ## Testing: - ✅ [ActionSheet Preview](https://ionic-framework-git-rou-11368-to-main-ionic1.vercel.app/src/components/action-sheet/test/a11y) - ✅ [Alert Preview](https://ionic-framework-git-rou-11368-to-main-ionic1.vercel.app/src/components/alert/test/a11y) - ✅ [DateTime Preview](https://ionic-framework-git-rou-11368-to-main-ionic1.vercel.app/src/components/datetime/test/basic) - ✅ [DateTime Button Preview](https://ionic-framework-git-rou-11368-to-main-ionic1.vercel.app/src/components/datetime-button/test/basic) - ✅ [Modal Preview](https://ionic-framework-git-rou-11368-to-main-ionic1.vercel.app/src/components/modal/test/a11y) - ✅ [Popover Preview](https://ionic-framework-git-rou-11368-to-main-ionic1.vercel.app/src/components/popover/test/basic) - ✅ [Select Preview](https://ionic-framework-git-rou-11368-to-main-ionic1.vercel.app/src/components/select/test/basic) - ✅ [Picker, PickerColumn and PickerColumnOption Preview](https://ionic-framework-git-rou-11368-to-main-ionic1.vercel.app/src/components/picker/test/basic) - ✅ [Toast Preview](https://ionic-framework-git-rou-11368-to-main-ionic1.vercel.app/src/components/toast/test/a11y) ## Other Information Dev build: `8.7.4-dev.11756388042.1a103a79` --------- Co-authored-by: ionitron <hi@ionicframework.com> Co-authored-by: Brandy Smith <6577830+brandyscarney@users.noreply.github.com> Co-authored-by: Brandy Smith <brandyscarney@users.noreply.github.com> |
||
|
renovate[bot]
|
dd68369338 |
chore(deps): update dependency @stencil/core to v4.36.1 (#30524)
This PR contains the following updates: | Package | Change | Age | Confidence | |---|---|---|---| | [@stencil/core](https://stenciljs.com/) ([source](https://redirect.github.com/stenciljs/core)) | [`4.33.1` -> `4.36.0`](https://renovatebot.com/diffs/npm/@stencil%2fcore/4.33.1/4.36.0) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | --- ### Release Notes <details> <summary>stenciljs/core (@​stencil/core)</summary> ### [`v4.36.0`](https://redirect.github.com/stenciljs/core/blob/HEAD/CHANGELOG.md#-4360-2025-07-15) [Compare Source](https://redirect.github.com/stenciljs/core/compare/v4.36.0...58bc2b5403312dd227b0c5d6f1de167559f2b015) ##### Bug Fixes * contructable stylesheets with older immutable spec (chrome <99) ([#6332](https://github.com/stenciljs/core/issues/6332)) ([2f363dd]( |
||
|
Colin Bares
|
db915bf6c7 |
docs(methods): update component method documentation #4145 (#30495)
Issue number: resolves ionic-team/ionic-docs#4145 --------- ## What is the current behavior? Some component methods are missing param tags in the JSDoc comments. Some comments are out of order and the method description is below the last param description. Some back ticks are misplaced around words resulting in incorrect formatting in the docs site. ## What is the new behavior? Method documentation in app, action-sheet, alert, datetime, loading, menu, modal, popover, reorder-group, router, searchbar, and toast now include descriptions for all params, all method descriptions are placed above param descriptions, and back ticks are formatted correctly. All changes are within JSDoc comments so will result in a change to the docs site but no functional change to any components. ## Does this introduce a breaking change? - [ ] Yes - [x] No ## Other information In order to preview these changes I took the JSON generated from the build on this branch and used it in the docusaurus script in place of the fetch from unpkg. I set up a preview from my fork on Vercel - https://ionic-docs-git-temptotestdocs-soundproofboots-projects.vercel.app/docs/components . The change I made to the docusaurus script to use this temp data is here - https://github.com/soundproofboot/ionic-docs/pull/1/files. tempDocs.json is the output of the framework build after making these changes. --------- Co-authored-by: Brandy Smith <brandyscarney@users.noreply.github.com> Co-authored-by: Brandy Smith <6577830+brandyscarney@users.noreply.github.com> Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com> |
||
|
renovate[bot]
|
8ef79cf4fb |
chore(deps): update playwright (#30367)
This PR contains the following updates: | Package | Change | Age | Adoption | Passing | Confidence | Type | Update | |---|---|---|---|---|---|---|---| | [@playwright/test](https://playwright.dev) ([source](https://redirect.github.com/microsoft/playwright)) | [`^1.51.1` -> `^1.52.0`](https://renovatebot.com/diffs/npm/@playwright%2ftest/1.51.1/1.52.0) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | devDependencies | minor | | mcr.microsoft.com/playwright | `v1.51.1` -> `v1.52.0` | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | final | minor | --- ### Release Notes <details> <summary>microsoft/playwright (@​playwright/test)</summary> ### [`v1.52.0`](https://redirect.github.com/microsoft/playwright/compare/v1.51.1...471930b1ceae03c9e66e0eb80c1364a1a788e7db) [Compare Source](https://redirect.github.com/microsoft/playwright/compare/v1.51.1...v1.52.0) </details> --- ### Configuration 📅 **Schedule**: Branch creation - "every weekday before 11am" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Never, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://redirect.github.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/ionic-team/ionic-framework). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4yNDguNCIsInVwZGF0ZWRJblZlciI6IjM5LjI1Ny4zIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119--> --------- Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: ionitron <hi@ionicframework.com> |
||
|
Brandy Smith
|
d52fca084c |
fix(config): allow LogLevel to work with isolatedModules and update all warns and errors to respect logLevel (#30350)
Issue number: internal --------- ## What is the current behavior? - `LogLevel` throws error `Error: Cannot access ambient const enums when 'isolatedModules' is enabled` - Several existing console warns and errors are not calling the function that respects the `logLevel` config ## What is the new behavior? - Remove `const` from the `enum` to work with `isolatedModules` - Update `console.warn`s to `printIonWarning` - Update `console.error`s to `printIonError` ## Does this introduce a breaking change? - [ ] Yes - [x] No ## Other information Dev build: `8.5.5-dev.11744729748.174bf7e0` --------- Co-authored-by: Brandy Smith <6577830+brandyscarney@users.noreply.github.com> |
||
|
renovate[bot]
|
c63ec2e98d |
chore(deps): update playwright (#29840)
This PR contains the following updates: | Package | Change | Age | Adoption | Passing | Confidence | Type | Update | |---|---|---|---|---|---|---|---| | [@axe-core/playwright](https://redirect.github.com/dequelabs/axe-core-npm) | [`^4.10.0` -> `^4.10.1`](https://renovatebot.com/diffs/npm/@axe-core%2fplaywright/4.10.0/4.10.1) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | devDependencies | patch | | [@playwright/test](https://playwright.dev) ([source](https://redirect.github.com/microsoft/playwright)) | [`^1.46.1` -> `^1.51.0`](https://renovatebot.com/diffs/npm/@playwright%2ftest/1.46.1/1.51.0) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | devDependencies | minor | | mcr.microsoft.com/playwright | `v1.46.1` -> `v1.51.0` | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | final | minor | --- ### Release Notes <details> <summary>dequelabs/axe-core-npm (@​axe-core/playwright)</summary> ### [`v4.10.1`](https://redirect.github.com/dequelabs/axe-core-npm/blob/HEAD/CHANGELOG.md#4101-2024-10-29) [Compare Source](https://redirect.github.com/dequelabs/axe-core-npm/compare/v4.10.0...v4.10.1) ##### Bug Fixes - Update axe-core to v4.10.1 ([#​1124](https://redirect.github.com/dequelabs/axe-core-npm/issues/1124)) ([099818b]( |
||
|
Maria Hutt
|
845071c97a |
fix(menu): hide from screen readers while animating (#30036)
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 the menu is presented on an Android device, TalkBack's focus rings may appear in the wrong position due to the transition (specifically `transform` styles). This occurs because the focus rings are initially displayed at the starting position of the elements before the transition begins. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - When an overlay is being animated (presenting or dismissing), the overlay will hide from screen readers. This allows Talkback to display the focus rings on the correct position. ## 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/docs/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: `8.4.1-dev.11732305980.19d90e1c` Related to https://github.com/ionic-team/ionic-framework/pull/29951 |
||
|
Brandy Carney
|
ee2fa19a1e |
feat(menu): pass role to ionWillClose and ionDidClose events (#29954)
- Adds the `MenuCloseEventDetail` interface which includes an optional `role` property - The `ionWillClose` and `ionDidClose` emit the `role` property for the following scenarios: - A role of `'gesture'` when dragging the menu closed - A role of `'backdrop'` when clicking on the backdrop to close the menu - A role of `'backdrop'` when the the menu is closed using the escape key - A role of `undefined` when the menu is closed from a button inside of the menu |
||
|
renovate[bot]
|
a745c6f4bc |
chore(deps): update playwright (#29750)
[](https://renovatebot.com) This PR contains the following updates: | Package | Change | Age | Adoption | Passing | Confidence | Type | Update | |---|---|---|---|---|---|---|---| | [@playwright/test](https://playwright.dev) ([source](https://togithub.com/microsoft/playwright)) | [`^1.45.3` -> `^1.46.0`](https://renovatebot.com/diffs/npm/@playwright%2ftest/1.45.3/1.46.0) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | devDependencies | minor | | mcr.microsoft.com/playwright | `v1.45.3` -> `v1.46.0` | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | final | minor | --- ### Release Notes <details> <summary>microsoft/playwright (@​playwright/test)</summary> ### [`v1.46.0`](https://togithub.com/microsoft/playwright/compare/v1.45.3...99a36310570617222290c09b96a2026beb8b00f9) [Compare Source](https://togithub.com/microsoft/playwright/compare/v1.45.3...v1.46.0) </details> --- ### Configuration 📅 **Schedule**: Branch creation - "every weekday before 11am" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Never, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://togithub.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View the [repository job log](https://developer.mend.io/github/ionic-team/ionic-framework). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40NDAuNyIsInVwZGF0ZWRJblZlciI6IjM4LjIwLjEiLCJ0YXJnZXRCcmFuY2giOiJtYWluIiwibGFiZWxzIjpbXX0=--> --------- Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: ionitron <hi@ionicframework.com> Co-authored-by: Maria Hutt <maria@ionic.io> |
||
|
Christian Bromann
|
bf7f6f6acf |
fix(test): fix Stencil Nightly build (#29780)
## What is the current behavior? The Playwright test for `core/src/components/menu/test/safe-area/menu.e2e.ts` started to fail after introducing the following patch to Stencil: [#5926](https://github.com/ionic-team/stencil/pull/5926). After debugging the situation it turns out that the test overwrites the first style in the `<head />` tag which turns out to be a component style that caused all screenshot test to fail. ## What is the new behavior? Overwrite the existing style by adding a new style tag at the bottom of the page. ## 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/docs/CONTRIBUTING.md#footer for more information. --> ## Other information n/a |
||
|
Brandy Carney
|
2007a44a27 |
test(many): fix failing tests that CI was not reporting (#29485)
Code checks were passing even though these tests were failing because the docker script was not exiting with the correct exit code. This PR fixes the tests so that they pass, then PR https://github.com/ionic-team/ionic-framework/pull/29425 can be merged so CI will properly fail again when tests fail. --------- Co-authored-by: Sean Perkins <sean.perkins@outsystems.com> |
||
|
Brandy Carney
|
0124f3b0b3 |
test(many): replace ionic buttons in e2e tests with native html buttons (#29422)
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? The `ion-button` component is used in several tests to navigate or show overlays. This causes screenshot diffs in unrelated tests any time the UI of the `ion-button` is updated. ## What is the new behavior? Removes the `ion-button` elements from unrelated tests. Did not remove the `ion-button`s from the following tests: - All `ion-button`s in an `ion-buttons` component - An `ion-button` inside of a menu - breadcrumbs/test/basic (uses a clear button in a list header, needs to be moved) - input/test/slot - item/test/buttons - item/test/colors - item/test/dividers - item/test/inputs - item/test/media - list-header/test/basic - ripple-effect/test/basic - router/test/basic - router/test/guards - router-outlet/test/basic - select/test/slot - textarea/test/slot Updates the icon/basic test to use the right icon names by comparing against the v3 names: https://ionicframework.com/docs/v3/ionicons/ ## Does this introduce a breaking change? - [ ] Yes - [x] No --------- Co-authored-by: ionitron <hi@ionicframework.com> |
||
|
Liam DeBeasi
|
6e8bf4914f |
chore(theming): remove Sass default flags (#29401)
Issue number: N/A --------- ## What is the current behavior? Currently, every Sass variable in Ionic has the `!default` flag added to the end. From the [Sass variables documentation](https://sass-lang.com/documentation/variables/): > Normally when you assign a value to a variable, if that variable already had a value, its old value is overwritten. But if you’re writing a Sass library, you might want to allow your users to configure your library’s variables before you use them to generate CSS. > > To make this possible, Sass provides the `!default` flag. This assigns a value to a variable only if that variable isn’t defined or its value is [null](https://sass-lang.com/documentation/values/null). Otherwise, the existing value will be used. In past versions of Ionic Framework, developers wrote Sass variables to rebuild Ionic Framework using their own values. In the latest versions of Ionic Framework, this is not possible. ## What is the new behavior? Removes the `!default` flag from all Sass variables. ## Does this introduce a breaking change? - [ ] Yes - [x] No ------- Co-authored-by: brandyscarney <brandyscarney@users.noreply.github.com> |
||
|
Liam DeBeasi
|
ff7fa0b2e2 | chore: sync with main | ||
|
Liam DeBeasi
|
487ffca11e |
chore: fix typo with close watcher const (#29146)
The variable was spelled incorrectly. |
||
|
Sean Perkins
|
03d26702f6 |
feat(menu): apply strict type for menu type (#28982)
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. --> `ion-menu` currently accepts any `string` to the `type` property, even though only `overlay`, `push` and `reveal` are only supported. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Adds more explicit types to the `type` property on `ion-menu` ## 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. --> |
||
|
Liam DeBeasi
|
05e721db1c |
refactor(item): do not automatically delegate focus (#29091)
resolves #21982 BREAKING CHANGE: - Item no longer automatically delegates focus to the first focusable element. While most developers should not need to make any changes to account for this update, usages of `ion-item` with interactive elements such as form controls (inputs, textareas, etc) should be evaluated to verify that interactions still work as expected. |
||
|
Liam DeBeasi
|
1091534397 | chore: sync with main | ||
|
Liam DeBeasi
|
219e630ed5 | chore: sync with main | ||
|
ionitron
|
b7c2b662ae | chore(): add updated snapshots | ||
|
Liam DeBeasi
|
74de16f862 | chore(): sync | ||
|
Liam DeBeasi
|
76f6362410 |
fix(menu): menu can be encapsulated in a component (#28801)
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` |
||
|
Liam DeBeasi
|
15e368c378 |
feat(theme): improved color contrast with color palette (#28791)
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> |
||
|
Liam DeBeasi
|
4fde5f07f6 |
chore: add strong types in several places (#28781)
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. --> |
||
|
Liam DeBeasi
|
658d1caccd |
feat: add experimental hardware back button support in browsers (#28705)
resolves #28703 |
||
|
Liam DeBeasi
|
878eec6ea2 |
fix(nav, router-outlet): ios page transition does not cover menu on larger screens (#28745)
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]( |
||
|
Liam DeBeasi
|
7cec5337a4 | chore: sync | ||
|
Brandy Carney
|
8ee23d20d5 |
fix(menu): allow styling of the box shadow and transform when visible inside of a split pane (#28691)
Issue number: resolves #21530 --------- ## What is the current behavior? The `box-shadow` and `transform` properties cannot be styled on a menu when it is inside of a split pane and visible due to the following: 1) The `box-shadow` and `transform` properties are set to `none` with `!important` 2) The menu itself is not on "top" of the split pane content so the content hides any box shadow ## What is the new behavior? - Removes all uses of `!important` in split pane and menu - Developers will need to change the `z-index` from `0` to `1` on the `ion-menu` so the menu will sit on top of the split pane and show the `box-shadow` ## Does this introduce a breaking change? - [ ] Yes - [x] No ## Other information I considered putting the test for this in `split-pane` but I thought since it was styling the `ion-menu` it should go in menu. I can move this if others think it makes more sense in `split-pane`. --------- Co-authored-by: ionitron <hi@ionicframework.com> |
||
|
Liam DeBeasi
|
2509d565b2 | chore: sync | ||
|
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> |
||
|
Sean Perkins
|
7ba939fb94 |
fix(overlays): prevent scroll gestures when the overlay is presented (#28415)
Issue number: Resolves #23942 --------- <!-- Please do not submit updates to dependencies unless it fixes an issue. --> <!-- Please try to limit your pull request to one type (bugfix, feature, etc). Submit multiple pull requests if needed. --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying. --> When an overlay is created (inserted in the DOM), but not presented, the scroll gesture is prevented. This behavior comes from the `connectedCallback` of `ion-backdrop`, where the gesture is prevented as soon as the backdrop is inserted in the DOM. This means in situations where a developer creates an overlay, but does not present it immediately, the user cannot scroll. This is not desired. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Scroll blocking behavior tied to the gesture has been removed from `ion-backdrop` and implemented into the overlays directly. - When an overlay is presented, scroll blocking is enabled on the `body` element (the user cannot scroll on the main content). - When the last presented overlay is dismissed, scroll blocking is disabled on the `body` element (the user can scroll on the main content). ## Does this introduce a breaking change? - [x] Yes - [ ] No `ion-backdrop` no longer prevents scrolling on the main content when the backdrop is either inserted into the DOM or removed from the DOM. Developers using Ionic overlays do not need to migrate their implementations. Developers with custom overlays using `ion-backdrop` internally can either use Ionic's gesture controller to disable scrolling when their overlay is presented/dismissed or can manually add the `backdrop-no-scroll` Ionic global class to the `body` element. <!-- If this introduces a breaking change, please describe the impact and migration path for existing applications below. --> ## Other information <!-- Any other information that is important to this PR such as screenshots of how the component looks before and after the change. --> --------- |
||
|
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. --> |
||
|
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> |
||
|
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
|
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
|
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` |
||
|
Liam DeBeasi
|
81714d45bd |
fix(overlays): correctly re-add root to accessibility tree (#28183)
Issue number: resolves #28180 --------- <!-- 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 presenting an overlay, we remove the root (usually `ion-router-outlet`) from the accessibility tree. This makes it so you cannot accidentally focus elements behind the overlay. When dismissing an overlay we re-add the root to the accessibility tree. However, we fail to consider if there are multiple presented overlays. For example, if you present a modal, then an alert, then dismiss the alert, then the root is re-added to the accessibility tree even though the modal is still presented. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - The root is now re-added to the accessibility tree only if it is the last presented 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.4.1-dev.11694783260.13da477f` |
||
|
Maria Hutt
|
574d762594 |
test(menu): safe area and proper var reset (#28177)
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. --> - There are no tests for menu when safe area is applied. - The safe area variables on menu weren't being reset properly to allow easy local customization. Currently, some of the variables are being set to `env()`. This is the same structure that is being used in core. However, this doesn't prevents users from mocking the safe area when using `--ion-safe-area-left: 50px` on `html`. It makes it hard to create tests to validate that padding is being applied to the safe area. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Tests have been added. - The safe area variables on menu are now being reset to use the values from `:root`. The variables are being `unset` in order for the variables to [default to parent styles](https://stackoverflow.com/a/69491310/5374225). Since core styles has already declared the variables, then developers can use `--ion-safe-area-left: 50px` on `html`. ## 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> |
||
|
Maria Hutt
|
e0542a7867 |
fix(menu): remove app dir from safe area padding (#28123)
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-safe-area-left` and `--ion-safe-area-right` variables in `ion-menu` are being set as if they use the app's direction. It's been determined that safe area is not logical and uses the device's direction. The current implementation is adding padding in the wrong sides for `ion-toolbar` and `ion-content` within a `ion-menu`. Additionally, `ion-menu` does not use the entire screen so the safe area only needs to be applied to the side that is touching the device screen. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Set the `--ion-safe-area-left` and `--ion-safe-area-right` variables to the correct values based on the device's direction. - Padding is only added to the side that is not in the safe area. - `ion-toolbar` is adding `--ion-safe-area-left` and `--ion-safe-area-right` based on the device's direction. - `ion-toolbar` can now inherit the correct values from `--ion-safe-area-left` and `--ion-safe-area-right`. - `ion-content` can now inherit the correct values from `--ion-safe-area-left` and `--ion-safe-area-right`. ## 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.3.4-dev.11694015543.18bc484f |
||
|
Liam DeBeasi
|
fa4113117d |
fix(menu): emit ionMenuChange when re-mounted (#28049)
Issue number: resolves #28030
---------
<!-- 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-menu` registers itself with the menu controller when
`connectedCallback` fires and then unregisters itself when
`disconnectedCallback` fires. When the menu was removed from the DOM,
`disconnectedCallback` was not always being fired due to
https://github.com/ionic-team/stencil/issues/4070.
`ion-menu-button` checks to see if it should be visible by grabbing the
current menu in
|
||
|
Sean Perkins
|
2cf1a0bcae |
fix(angular): menu button is enabled with Angular Universal builds (#27814)
Issue number: Resolves #27524 #22206 --------- <!-- 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. --> After destructive hydration from an Angular Universal build, the `ion-menu` is disabled. This results in a few problematic behaviors: - If used with an `ion-split-pane`, the split pane will not render with the menu. - If used with an `ion-menu-button`, the menu icon will not render and the menu will not be accessible. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Removes automatically disabling the `ion-menu` when in a server environment. - Prevents setting an `ion-menu` that no longer exists in the DOM, as an active menu. This allows the most recent menu to be enabled when rendered from Angular Universal builds. Loom recording overviewing the change: https://www.loom.com/share/5a149218adc84cc2af435fc1b1f45124?sid=249028f4-be3d-4d4a-948a-597da83be95a ## 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.1.4-dev.11689625795.1d16532b` |
||
|
Liam DeBeasi
|
6fab2a98b3 | chore(): sync with main | ||
|
Sean Perkins
|
e75fa582c4 |
fix(header, footer): resolve CSP violations with box shadow (#27560)
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. --> The `ion-header` and `ion-footer` use a base64 encoded image for a box shadow instead of using the CSS box-shadow property directly. The use of the background image creates CSP violations. The historic reasoning of using an image instead of box shadow was to improve scroll performance. Browsers and devices have improved a lot since that was implemented (5 years ago). ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Updates the usage of `ion-header` and `ion-footer` to use a box shadow. The value comes from Material's web implementation: https://material-components.github.io/material-components-web-catalog/#/component/top-app-bar ## 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> |
||
|
Sean Perkins
|
10d2c75f8d | Merge remote-tracking branch 'origin/main' into chore/sync-with-main-5-3 | ||
|
Liam DeBeasi
|
f62ba3e8a6 |
test(menu): migrate to generators (#27330)
Issue number: N/A --------- <!-- Please refer to our contributing documentation for any questions on submitting a pull request, or let us know here if you need any help: https://ionicframework.com/docs/building/contributing --> <!-- Some docs updates need to be made in the `ionic-docs` repo, in a separate PR. See https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#modifying-documentation for details. --> <!-- 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 sliding tests use legacy syntax ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Menu sliding tests use modern syntax ## 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
|
4826a3d9f5 |
test(config): introduce legacy and modern playwright projects (#27228)
Issue number: N/A --------- <!-- Please refer to our contributing documentation for any questions on submitting a pull request, or let us know here if you need any help: https://ionicframework.com/docs/building/contributing --> <!-- Some docs updates need to be made in the `ionic-docs` repo, in a separate PR. See https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#modifying-documentation for details. --> <!-- 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. --> This is the first PR to introduce the infrastructure required to add test generators to the Ionic Framework project. This PR introduces the file name changes necessary to support two playwright configs, so I recommend reviewing the PR by commit: |
||
|
Liam DeBeasi
|
0ac451998c |
test(many): do not await page.locator (#27267)
Issue number: N/A --------- <!-- Please refer to our contributing documentation for any questions on submitting a pull request, or let us know here if you need any help: https://ionicframework.com/docs/building/contributing --> <!-- Some docs updates need to be made in the `ionic-docs` repo, in a separate PR. See https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#modifying-documentation for details. --> <!-- 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. --> `page.locator` is synchronous, but we were `await`ing the calls: https://playwright.dev/docs/api/class-page#page-locator We were also doing `page.locator(...).click()` when we can just do `page.click([selector])` directly, ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Removes `await` usage from `page.locator` - Removes `page.locator().click()` usage in favor of `page.click()` ## 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. --> |
||
|
Maria Hutt
|
0a0345a84a | refactor(many): use utils import (#27160) | ||
|
Liam DeBeasi
|
b81b0d1425 |
fix(menu): refs are not destroyed on unmount (#27141)
<!-- Please refer to our contributing documentation for any questions on submitting a pull request, or let us know here if you need any help: https://ionicframework.com/docs/building/contributing --> <!-- Some docs updates need to be made in the `ionic-docs` repo, in a separate PR. See https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#modifying-documentation for details. --> <!-- 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. --> <!-- Issues are required for both bug fixes and features. --> Issue URL: resolves https://github.com/ionic-team/ionic-framework/issues/24907 `ion-menu` currently clears the `menuInnerEl` and `backdropEl` refs created by Stencil when `disconnectedCallback` is fired. If the `ion-menu` component is re-mounted but _not_ re-rendered, those refs will still be `undefined` when the `open` method is called, resulting in the linked issue. Note that if the `ion-menu` re-renders before `open` is called then this issue does not reproduce. This clearing behavior was added ~6 years ago before we utilized Stencil refs: |
