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. -->
Prettier is configured to ignore the `proxies.ts` file in the `src`
directory only. This means it is adjusting whitespace/commas/etc on the
`proxies.ts` file in the `standalone` directory which we do not want
because we will always get diffs whenever `npm run build` is run in
`core`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updated prettier config to ignore all `proxies.ts` files in the
`angular` package
- Re-generated the proxies file
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: 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>
Issue number: resolves#28358
---------
<!-- 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. -->
28f2ec9c62
exposed a (possible) `ng-packagr` bug where the form control components
were being re-assigned, which breaks treeshaking. These components were
considered side effects and were always being pulled into the bundle.
This resulted in a higher than expected bundle size. This issue appears
to be caused by using 2 decorators **and** referring to the class in
`useExisting` (for providers). Doing just one of these does not
reproduce the issue.
The compiled output looks something like this:
```typescript
let IonToggle = IonToggle_1 = /*@__PURE__*/ class IonToggle extends ValueAccessor {
constructor(c, r, z, injector) {
super(injector, r);
this.z = z;
c.detach();
this.el = r.nativeElement;
proxyOutputs(this, this.el, ['ionChange', 'ionFocus', 'ionBlur']);
}
writeValue(value) {
this.elementRef.nativeElement.checked = this.lastValue = value;
setIonicClasses(this.elementRef);
}
handleIonChange(el) {
this.handleValueChange(el, el.checked);
}
};
/** @nocollapse */ IonToggle.ɵfac = i0.ɵɵngDeclareFactory({ minVersion: "12.0.0", version: "14.2.12", ngImport: i0, type: IonToggle, deps: [{ token: i0.ChangeDetectorRef }, { token: i0.ElementRef }, { token: i0.NgZone }, { token: i0.Injector }], target: i0.ɵɵFactoryTarget.Component });
/** @nocollapse */ IonToggle.ɵcmp = i0.ɵɵngDeclareComponent({ minVersion: "14.0.0", version: "14.2.12", type: IonToggle, isStandalone: true, selector: "ion-toggle", inputs: { checked: "checked", color: "color", disabled: "disabled", enableOnOffLabels: "enableOnOffLabels", justify: "justify", labelPlacement: "labelPlacement", legacy: "legacy", mode: "mode", name: "name", value: "value" }, host: { listeners: { "ionChange": "handleIonChange($event.target)" } }, providers: [
{
provide: NG_VALUE_ACCESSOR,
useExisting: IonToggle_1,
multi: true,
},
], usesInheritance: true, ngImport: i0, template: '<ng-content></ng-content>', isInline: true, changeDetection: i0.ChangeDetectionStrategy.OnPush });
IonToggle = IonToggle_1 = __decorate([
ProxyCmp({
defineCustomElementFn: defineCustomElement$1i,
inputs: TOGGLE_INPUTS,
})
], IonToggle);
```
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed the `ProxyCmp` usage in favor of manually calling proxyInputs
and proxyMethods.
- Also saw that select was missing a form control test, so I added one
The compiled code now looks something like this:
```typescript
class IonToggle extends ValueAccessor {
constructor(c, r, z, injector) {
super(injector, r);
this.z = z;
defineCustomElement$1i();
proxyInputs(IonToggle, TOGGLE_INPUTS);
c.detach();
this.el = r.nativeElement;
proxyOutputs(this, this.el, ['ionChange', 'ionFocus', 'ionBlur']);
}
writeValue(value) {
this.elementRef.nativeElement.checked = this.lastValue = value;
setIonicClasses(this.elementRef);
}
handleIonChange(el) {
this.handleValueChange(el, el.checked);
}
}
/** @nocollapse */ IonToggle.ɵfac = i0.ɵɵngDeclareFactory({ minVersion: "12.0.0", version: "14.2.12", ngImport: i0, type: IonToggle, deps: [{ token: i0.ChangeDetectorRef }, { token: i0.ElementRef }, { token: i0.NgZone }, { token: i0.Injector }], target: i0.ɵɵFactoryTarget.Component });
/** @nocollapse */ IonToggle.ɵcmp = i0.ɵɵngDeclareComponent({ minVersion: "14.0.0", version: "14.2.12", type: IonToggle, isStandalone: true, selector: "ion-toggle", inputs: { checked: "checked", color: "color", disabled: "disabled", enableOnOffLabels: "enableOnOffLabels", justify: "justify", labelPlacement: "labelPlacement", legacy: "legacy", mode: "mode", name: "name", value: "value" }, host: { listeners: { "ionChange": "handleIonChange($event.target)" } }, providers: [
{
provide: NG_VALUE_ACCESSOR,
useExisting: IonToggle,
multi: true,
},
], usesInheritance: true, ngImport: i0, template: '<ng-content></ng-content>', isInline: true, changeDetection: i0.ChangeDetectionStrategy.OnPush });
```
## 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. -->
Ryan provided some context on a related Stencil bug where doing
reassignments broke treeshaking in Webpack. While the source of this bug
is not Stencil, understanding the Stencil bug helped me better
understand this issue:
https://github.com/ionic-team/stencil/issues/3191https://github.com/ionic-team/stencil/pull/3248https://github.com/ionic-team/stencil/pull/4188 (fixes an issue
introduced in the above stencil PR)
Dev build: `7.5.1-dev.11697480817.10fa2601`
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:
feda7a0e96/core/src/components/item-option/item-option.scss (L20-L30)
The rendered markup for a sliding item looks like the following:
```html
<ion-item-sliding>
<ion-item-options side="start">
<ion-item-option>
Archive
</ion-item-option>
</ion-item-options>
<ion-item class="in-list">
<ion-label>
Sliding Item
</ion-label>
</ion-item>
</ion-item-sliding>
```
Since `ion-item-options` never gets the `in-list` class added to it, and
`ion-item` never contains options, the above CSS is never used.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed the CSS that is not used, the correct CSS for safe area
padding has already been added here:
feda7a0e96/core/src/components/item-options/item-options.scss (L57-L67)
- Added screenshot tests to verify the safe area padding is applied to
the proper side
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
## Other information
I could add additional tests that make sure there is not padding added
when opening the opposite side on each direction but since this problem
was happening when changing from `ltr` to `rtl` I did not.
[FW-5174]:
https://ionic-cloud.atlassian.net/browse/FW-5174?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
---------
Co-authored-by: ionitron <hi@ionicframework.com>
1) Wraps the label text and other content in an item when there is not enough room for everything to fit, instead of truncating the label with an ellipsis. Does not apply to items containing legacy inputs.
2) Passes the legacy property up to item from checkbox, input, radio, range, select, textarea and toggle. Item adds classes for all of these and does not wrap its contents if that class exists. If a developer is using a legacy input without the legacy property on it then they will need to add the legacy property to prevent the wrapping.
3) If a developer does not want the text to wrap for labels in modern items, the `ion-text-nowrap` class can be added to the label.
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 Ionicons in Ionic is currently difficult. Developers need to a)
create a dev build of Ionicons, b) create a branch in Ionic, c) install
the dev build in Ionic core, d) push the branch, and e) create a draft
PR to watch the CI process run.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Introduces a workflow dispatch option for our CI process. This allows
developers to run the CI process for any branch without creating PR.
- I also added an optional input so devs can specify the ionicons
version if they want to pass a special version.
## 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. -->
Bumps [@axe-core/playwright](https://github.com/dequelabs/axe-core-npm)
from 4.8.0 to 4.8.1.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/dequelabs/axe-core-npm/blob/develop/CHANGELOG.md"><code>@axe-core/playwright</code>'s
changelog</a>.</em></p>
<blockquote>
<h1>Change Log</h1>
<p>All notable changes to this project will be documented in this file.
See <a href="https://conventionalcommits.org">Conventional Commits</a>
for commit guidelines.</p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/dequelabs/axe-core-npm/commits">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
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="3049d99bc8"><code>3049d99</code></a>
cherry-pick(<a
href="https://redirect.github.com/microsoft/playwright/issues/27555">#27555</a>):
chore: composed->merge</li>
<li><a
href="ae31f58b43"><code>ae31f58</code></a>
chore: mark 1.39.0 (<a
href="https://redirect.github.com/microsoft/playwright/issues/27550">#27550</a>)</li>
<li><a
href="5313514995"><code>5313514</code></a>
cherry-pick(<a
href="https://redirect.github.com/microsoft/playwright/issues/27549">#27549</a>):
docs: update release notes for 1.39</li>
<li><a
href="0d168dc8d0"><code>0d168dc</code></a>
chore: release notes for 1.39 (<a
href="https://redirect.github.com/microsoft/playwright/issues/27537">#27537</a>)</li>
<li><a
href="4f9b285c07"><code>4f9b285</code></a>
chore: update WebKit version to 17.4 (<a
href="https://redirect.github.com/microsoft/playwright/issues/27536">#27536</a>)</li>
<li><a
href="d11380e911"><code>d11380e</code></a>
docs: improve test.step documentation (<a
href="https://redirect.github.com/microsoft/playwright/issues/27535">#27535</a>)</li>
<li><a
href="9edb811434"><code>9edb811</code></a>
feat(chromium-tip-of-tree): roll to r1158 (<a
href="https://redirect.github.com/microsoft/playwright/issues/27533">#27533</a>)</li>
<li><a
href="d05c865389"><code>d05c865</code></a>
test: unflake a few tests (<a
href="https://redirect.github.com/microsoft/playwright/issues/27519">#27519</a>)</li>
<li><a
href="2776d8446b"><code>2776d84</code></a>
docs: how to update playwright in python (<a
href="https://redirect.github.com/microsoft/playwright/issues/27527">#27527</a>)</li>
<li><a
href="2407041090"><code>2407041</code></a>
fix(chromium): avoid premature continue of redirects (<a
href="https://redirect.github.com/microsoft/playwright/issues/27520">#27520</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/microsoft/playwright/compare/v1.38.1...v1.39.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: ionitron <hi@ionicframework.com>
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>
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:
dcbf45101f/core/src/utils/menu-controller/index.ts (L14)
This means that since there are two different controllers,
`menuController` B does not know about the menus in `menuController` A.
The end result is that the menu controller used in developer
applications did not have references to the registered menus, which gave
the impression that the menu controller did not work.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updated the architecture of `MenuController` in Ionic Angular to
accept a `menuController` instance. This allows `@ionic/angular` to pass
the `menuController` from `@ionic/core` and for
`@ionic/angular/standalone` to pass the `menuController` from
`@ionic/core/components`.
Note: Overlay controllers don't **need** this change per-se since they
don't cache references to overlays internally (they just query the DOM).
However, I think it would be good to have a consistent architecture
here, so I'll put up a separate PR that makes this change for overlays
too.
## 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
Dev build: `7.5.1-dev.11697123035.1ee6b4a2`
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: Resolves#28186
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Ionic lifecycle hooks do not execute a cleanup function when the
underlying `useEffect` is unmounted.
```ts
useEffect(() => {
return () => {
console.log('cleanup'); // called
};
});
useIonViewWillEnter(() => {
return () => {
console.log('cleanup'); // never called
};
});
```
Ionic's implementation registers the lifecycle callback to be handled at
a later time, by the page managers. However, it does not keep a
reference to the returned callback, so it cannot execute it when the
`useEffect` is unmounted.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Ionic lifecycle hooks execute dev-specified cleanup functions
## 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.11696956070.1faa3cfe`
This PR builds on the changes in #28316.
---------
Co-authored-by: Maria Hutt <maria@ionic.io>
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
Issue number: N/A
Resolves feedback identified here:
baa37ef1e3 (r1356414362)
---------
<!-- 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 lifecycle interfaces are not exported from
`@ionic/angular/standalone`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Lifecycle interfaces are exported from `@ionic/angular/standalone`.
## 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. -->
Bumps [@capacitor/core](https://github.com/ionic-team/capacitor) from
5.4.2 to 5.5.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/ionic-team/capacitor/releases"><code>@capacitor/core</code>'s
releases</a>.</em></p>
<blockquote>
<h2>5.5.0</h2>
<h1><a
href="https://github.com/ionic-team/capacitor/compare/5.4.2...5.5.0">5.5.0</a>
(2023-10-11)</h1>
<h3>Features</h3>
<ul>
<li><strong>android:</strong> allow developers to provide logic for
onRenderProcessGone in WebViewListener (<a
href="https://redirect.github.com/ionic-team/capacitor/issues/6946">#6946</a>)
(<a
href="34b724a4cf">34b724a</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/ionic-team/capacitor/blob/5.5.0/CHANGELOG.md"><code>@capacitor/core</code>'s
changelog</a>.</em></p>
<blockquote>
<h1><a
href="https://github.com/ionic-team/capacitor/compare/5.4.2...5.5.0">5.5.0</a>
(2023-10-11)</h1>
<h3>Features</h3>
<ul>
<li><strong>android:</strong> allow developers to provide logic for
onRenderProcessGone in WebViewListener (<a
href="https://redirect.github.com/ionic-team/capacitor/issues/6946">#6946</a>)
(<a
href="34b724a4cf">34b724a</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="280e404f00"><code>280e404</code></a>
Release 5.5.0</li>
<li><a
href="34b724a4cf"><code>34b724a</code></a>
feat(android): allow developers to provide logic for onRenderProcessGone
in W...</li>
<li>See full diff in <a
href="https://github.com/ionic-team/capacitor/compare/5.4.2...5.5.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
While debugging #28186, Maria and I identified that Ionic's lifecycle
event listeners (`ionViewWillEnter`, etc.) were being registered
multiple times on the same `.ion-page` element. This resulted in
problematic behavior, where a user's implementation of our lifecycle
hooks, would execute their callback multiple times.
```ts
useIonViewWillEnter(() => {
// This is called 2x for every time the `ionViewWillEnter` event is emitted (in React 18, dev mode)
console.log('hello world');
});
```
When the Ionic lifecycle event listeners are registered in React, we
bind the scope of the class to the callback function. When removing the
event listener we additional use the `.bind` syntax.
```tsx
componentDidMount() {
element.addEventListener('ionViewWillEnter', this.ionViewWillEnter.bind(this));
}
componentWillUnmount() {
// This creates a new instance of the function to remove! It doesn't remove the original event listener.
element.removeEventListener('ionViewWillEnter', this.ionViewWillEnter.bind(this));
}
```
The `.bind` method returns a new instance of the function. This means in
the implementation we are creating a new instance of the function when
both adding and removing the event listener - resulting in the
`removeEventListener` to never remove the original event listener.
This behavior only occurred in React 18 in dev mode, as a result of the
mount/unmount behavior running 2x for `useEffect` hooks.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Ionic lifecycle event listeners are removed from element references
when they are unmounted.
- User's lifecycle callback methods are only invoked once per event
emission.
|Before|After|
|----|----|
|<img alt="CleanShot 2023-10-09 at 18 32 08@2x"
src="https://github.com/ionic-team/ionic-framework/assets/13732623/53f2ef5d-5900-4a84-b427-fa6c9d35d081">|<img
alt="CleanShot 2023-10-09 at 18 29 37@2x"
src="https://github.com/ionic-team/ionic-framework/assets/13732623/c8a9a657-a0bf-4d6d-9f21-a41a686de490">|
## 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 <maria@ionic.io>
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
Issue number: N/A
"Owning" a test didn't really work out like I expected/hoped. A lot of
changes to the test files were minor, so I ended up just getting
assigned to more-or-less random PRs. It wasn't really hurting anything,
but I might as well just let the bot assign me.
---------
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
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>
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>
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. -->
**1. Bundle Size Reductions**
All Ionic UI components and Ionicons are added to the final bundle of an
Ionic Angular application. This is because all components and icons are
lazily loaded as needed. This prevents the compiler from properly tree
shaking applications. This does not cause all components and icons to be
loaded on application start, but it does increase the size of the final
app output that all users need to download.
**Related Issues**
https://github.com/ionic-team/ionicons/issues/910https://github.com/ionic-team/ionicons/issues/536https://github.com/ionic-team/ionic-framework/issues/27280https://github.com/ionic-team/ionic-framework/issues/24352
**2. Standalone Component Support**
Standalone Components are a stable API as of Angular 15. The Ionic
starter apps on the CLI have NgModule and Standalone options, but all of
the Ionic components are still lazily/dynamically loaded using
`IonicModule`. Standalone components in Ionic also enable support for
new Angular features such as bundling with ESBuild instead of Webpack.
ESBuild does not work in Ionic Angular right now because components
cannot be statically analyzed since they are dynamically imported.
We added preliminary support for standalone components in Ionic v6.3.0.
This enabled developers to use their own custom standalone components
when routing with `ion-router-outlet`. However, we did not ship
standalone components for Ionic's UI components.
**Related Issues**
https://github.com/ionic-team/ionic-framework/issues/25404https://github.com/ionic-team/ionic-framework/issues/27251https://github.com/ionic-team/ionic-framework/issues/27387
**3. Faster Component Load Times**
Since Ionic Angular components are lazily loaded, they also need to be
hydrated. However, this hydration does not happen immediately which
prevents components from being usable for multiple frames.
**Related Issues**
https://github.com/ionic-team/ionic-framework/issues/24352https://github.com/ionic-team/ionic-framework/issues/26474
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Ionic components and directives are accessible as Angular standalone
components/directives
## 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. -->
Associated documentation branch:
https://github.com/ionic-team/ionic-docs/tree/feature-7.5
---------
Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
Co-authored-by: Sean Perkins <sean@ionic.io>
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
Co-authored-by: Maria Hutt <maria@ionic.io>
Co-authored-by: Sean Perkins <13732623+sean-perkins@users.noreply.github.com>
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:
a04a11be35/core/src/utils/menu-controller/index.ts (L79C12-L79C12)
Step 6 is where this breaks down. In this scenario, the menus on "home"
and "page-two" are disabled. This leads menu controller to use its
fallback which tries to get the first menu registered on the specified
side:
a04a11be35/core/src/utils/menu-controller/index.ts (L86)
This means that the menu controller would attempt to open the "home"
menu even though the user is on "page-two" (because the start menu on
"home" was the first to be registered).
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Menus are no longer automatically disabled when a new menu on the same
side is registered
- Referencing menus by side when multiple menus with that side exist in
the DOM will cause a warning to be logged
This change has a couple implications:
1. Developers no longer need to manually enable a menu as noted in
https://ionicframework.com/docs/api/menu#multiple-menus. Note that
continuing to manually enable the menus will not cause any adverse side
effects and will effectively be a no-op.
2. Developers using the menuController to open a menu based on "side"
may end up having the wrong menu get opened.
Example before to this change:
1. Start on PageA with a `start` menu. Calling
`menuController.open('start')` opens the menu on PageA.
2. Go to PageB with a `start` menu. Calling
`menuController.open('start')` opens the menu on PageB because the menu
on PageA is disabled.
Example after to this change:
1. Start on PageA with a `start` menu. Calling
`menuController.open('start')` opens the menu on PageA.
2. Go to PageB with a `start` menu. Calling
`menuController.open('start')` attempts to opens the menu on PageA
because both menus are enabled. However, since PageA is hidden nothing
will appear to happen.
## 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. -->
I manually verified that removing the Angular Universal code does not
regress the behavior fixed in
https://github.com/ionic-team/ionic-framework/pull/27814. The menu is
never automatically disabled, so the bug does not happen.
This is a partial fix for
https://github.com/ionic-team/ionic-framework/issues/18683. Properly
fixing this requires another change which is out of scope for this work.
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`
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`
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. -->
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 trying to fix
https://github.com/ionic-team/ionic-framework/issues/20092, I discovered
that
ac2c8e6c22/core/src/components/menu/menu.tsx (L483)
was never resolving when the animation was aborted in
ac2c8e6c22/core/src/components/menu/menu.tsx (L699).
This can happen if `menu.disabled` is set to `true` mid-animation.
In order to fix the menu bug, I need this promise to resolve when the
animation is stopped.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The `play` method now correctly resolves when the animation is
cancelled.
## 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 `play` method resolves when a particular run of the animation is
finished. The `stop` method ensures that this run never finishes which
is why I've chosen to have `play` resolve. Note that `onFinish`
callbacks should not be fired because the animation run did not
complete.
Issue number: resolves#28303
---------
<!-- 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?
- Swipe back gesture is inconsistently clobbered by ion-item-sliding's
gesture.
## What is the new behavior?
- Swipe back gesture now has a higher priority than ion-item-sliding
-
-
## 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
This patch has been in use in
[Voyager](https://github.com/aeharding/voyager) for the past couple
months to great success!
---------
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
when the stencil team wants to test a dev build of stencil against the
framework team's ci, they push a branch to this repo that overrides the
stencil nightly job's npm tag (replacing 'nightly' with the dev build
version) and manually kick off the nightly workflow. this commit would
eliminate the need for that first step there
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
update the stencil nightly job to accept any npm release tag, rather
than always default to 'nightly'. doing so allows the stencil team to
reuse this workflow for cases where we'd like to test a _dev_ build of
stencil by running it through the framework's ci process, without
landing the feature in stencil first.
I was able to test that `nightly` gets set by default (and the field is
required) by running the workflow from this branch.
I then also tested this against a dev build of Stencil:
Interestingly enough, it helped me catch something to consider if we
were to accept the PR this dev build is accepted!
## 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
I considered making a separate workflow for this (rather than
override/use nightly) - it didn't quite seem worth the maintenance
effort 🤷
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: resolves#27060
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The main header is controlled by the header with `collapse="condense"`
set:
a04a11be35/core/src/components/header/header.tsx (L144)
The collapse header will hide the main header and then show it once the
user has scrolled enough. However, if the main header is rendered before
the collapse header is rendered, then the main header will be visible
for a brief moment before being hidden by the collapse header. This
gives the perception of flicker that is reported on the linked issue.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The main header will be hidden on load if it loads before the collapse
header
The selector was written in a way such that once the collapse header
loads, this CSS no longer applies (since the collapse header will add
`.header-collapse-main` to the main header)
| `main` | branch |
| - | - |
| <video
src="https://github.com/ionic-team/ionic-framework/assets/2721089/3cb11a57-e084-435a-89c2-e1c2afba04b1"></video>
| <video
src="https://github.com/ionic-team/ionic-framework/assets/2721089/c5caeb5e-3b33-4598-986f-bf097c46251c"></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: `:has` browser compat is still fairly new. However, it is
available on both Chromium and WebKit browsers (and has been for at
least a year): https://caniuse.com/?search=%3Ahas
Given that this bug is a fairly minor UI glitch (as opposed to something
that would cause an app to crash or otherwise malfunction), I think this
is an acceptable tradeoff. As time goes on this will become less of a
concern as more users update their devices.
Dev build: `7.4.3-dev.11696365694.156f41d3`
