merge release-8.8.8#31161
Merged
Merged
Conversation
Release 8.8.7 --------- Co-authored-by: ionitron <hi@ionicframework.com>
…#31148) Issue number: resolves #29413 --------- <!-- 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? In `viewStacks.ts`, `unmountLeavingViews` and `mountIntermediaryViews` walk the outlet's view stack using `startIndex - delta` (or `startIndex + delta`) as the loop end, with no bound on `viewStack.length`. `delta` comes from the popstate event's history delta. Apps that mount `<ion-tabs>` at the root with no outer `<ion-router-outlet>` only have one outlet registered, so `usingLinearNavigation` is true and these helpers actually run. Each tab switch adds a browser history entry but reuses existing view items, so `|delta|` can easily exceed the stack depth above the entering view. The loop then reads `viewStack[i]` as `undefined` and throws `TypeError: viewItem is undefined` from `viewItem.mount = false`. The navigation aborts mid-transition, which is what surfaces the secondary `enteringEl is undefined` warning and leaves that route stuck ## What is the new behavior? Both helpers bail when the entering view item isn't in the stack (`startIndex === -1`) and clamp the loop end to `Math.min(viewStack.length, ...)`, so a delta that overruns the stack stops at the last real view item instead of indexing past the end. A new Vitest spec at `packages/vue/test/base/tests/unit/tabs-single-outlet.spec.ts` mounts `<ion-tabs>` as the app root with flat routes, builds up history across tabs and sub-pages, then calls `router.go(-6)`. Without the fix the spec catches the unhandled `TypeError` from `viewStacks.ts` ## 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. --> Main-branch counterpart of #31145. Source change is byte-identical to the source portion of that PR so the merge back into `major-9.0` collapses to a no-op. There are no tests here, but there are in the v9 version because the v9 testing setup is better.
…31154) Issue number: resolves #25470 --------- <!-- 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? When an `<ion-tab-button>` declares an `href` with a query string or fragment, activating the tab drops both. In Angular, `IonTabs.select` navigates to `tabsPrefix/tab` and never reads the button's `href`. In Vue, the router splits the path on `?` and discards everything after it, and `IonTabBar` compares the raw href against the pathname so a tab with query params never shows as selected. In React, this issue has been fixed as part of the RR6 migration. ## What is the new behavior? Tab activation forwards the `href`'s query and fragment as navigation extras. A saved view's previously-captured extras still win when re-selecting a tab with prior history, so mid-stack state isn't clobbered. `IonTabBar`'s selection check now compares pathnames only, so a tab with a query string still highlights when its pathname is active. Added Playwright coverage in `@ionic/angular` and Cypress coverage in `@ionic/vue` for first visit, switching tabs, switching back, and re-clicking the active tab. The Vue tests will cause a conflict on merging into major-9.0, but I volunteer to fix that issue when it comes up. ## 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 Preview pages: - Angular: https://ionic-framework-git-fw-7146-ionic1.vercel.app/angular/standalone/tabs-search-params/tab1?foo=bar - Vue: https://ionic-framework-git-fw-7146-ionic1.vercel.app/vue/tabs-search-params/tab1?foo=bar - React: This was fixed in the RR6 migration in V9. Unfortunately this won't be coming to 8.8 at this time.
…31159) Issue number: resolves #27843 --------- ## What is the current behavior? `createInlineOverlayComponent` renders inline overlays (modal, popover, etc.) inside a `<template>` at their declared JSX position. When the overlay presents, `CoreDelegate` teleports the DOM node into `ion-app`, but React's synthetic event delegation root stays at the original JSX parent. Once the overlay lives outside that subtree, React no longer dispatches events to children inside it, so `onClick`, `onChange`, and other handlers inside an `IonModal` rendered within an `IonNav` silently stop firing ## What is the new behavior? Top-level inline overlays now render through `createPortal` into the same `ion-app` container that `CoreDelegate` teleports into, so React's event root follows the DOM ## Does this introduce a breaking change? - [ ] Yes - [x] No ## Other information This issue also reports the same problem in Vue, but that was fixed in #30227 Preview: [navigation-modal](https://ionic-framework-git-fw-6314-ionic1.vercel.app/react/navigation-modal) Dev build: ``` 8.8.8-dev.11779302602.17decfbf ```
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release 8.8.8