Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ResizeObserver callback is not running in zone #45105

Closed
bene-starzengruber opened this issue Feb 16, 2022 · 4 comments
Closed

ResizeObserver callback is not running in zone #45105

bene-starzengruber opened this issue Feb 16, 2022 · 4 comments

Comments

@bene-starzengruber
Copy link

bene-starzengruber commented Feb 16, 2022

Which @angular/* package(s) are the source of the bug?

core, zone

Is this a regression?

I dont think so, same behaviour as in Angular 12

Description

The callback of a ResizeObserver is not running in the ngZone and does therefore not trigger change detection, even if .markForCheck() is called manually

Please provide a link to a minimal reproduction of the bug

angular 13: https://stackblitz.com/edit/angular-ivy-cuegz9?file=src/app/app.component.ts
(have a look at the comments in ngOnInit and resize the preview tile on the right to see the effect)

angular 12: https://stackblitz.com/edit/base-angular-12-app-uh71an?file=src/app/app.component.ts

Anything else?

there are issues regarding the ResizeObserver and fakeAsync but I'm not sure if this is related
#31695

also there are efforts vom Jia but it seemed that this did not find its way into Angular
angular/zone.js#1011

@JoostK
Copy link
Member

JoostK commented Feb 16, 2022

This is indeed essentially the same as #31695; ResizeObserver is not patched by zone.js and therefore requires manually entering the zone within the resize callback.

@JoostK JoostK closed this as completed Feb 16, 2022
@Timebutt
Copy link

Timebutt commented Mar 15, 2022

Hi @JoostK, I'm just running into this exact same issue in some code I'm developing and started digging into code. I did indeed find out that the ResizeObserver is not patched by default by zone.js, but oddly enough there is an implementation for just that present in the zone.js codebase.

If I add an import 'zone.js/dist/zone-patch-resize-observer'; to my polyfills.ts, the ResizeObserver callback is correctly patched as I would expect, and needs no explicit zone.run() anymore. Furthermore, if I add below code to zone.js:

Zone.__load_patch('ResizeObserver', (global: any, Zone: ZoneType, api: _ZonePrivate) => {
  patchClass('ResizeObserver');
});

similar to the implementation here, it also just works.

I'm trying to understand why that code is provisioned if it isn't used by default? Is there a reasoning in which we incur a performance hit by patching ResizeObserver using the existing implementation and so applying the patch is left to the developer in need, or is this just an oversight and as such a bug in zone.js?

@JoostK
Copy link
Member

JoostK commented Mar 15, 2022

I don't know, TBH. Maybe @JiaLiPassion recalls.

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Apr 15, 2022
atscott added a commit to atscott/angular that referenced this issue Mar 30, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Mar 30, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 8, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 8, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 12, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 12, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 12, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
atscott added a commit to atscott/angular that referenced this issue Apr 16, 2024
…zone

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.
alxhub pushed a commit that referenced this issue Apr 17, 2024
…zone (#55102)

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes #55238
fixes #53844
fixes #53841
fixes #52610
fixes #53566
fixes #52940
fixes #51970
fixes #51768
fixes #50702
fixes #50259
fixes #50266
fixes #50160
fixes #49940
fixes #49398
fixes #48890
fixes #48608
fixes #45105
fixes #42241
fixes #41553
fixes #37223
fixes #37062
fixes #35579
fixes #31695
fixes #24728
fixes #23697
fixes #19814
fixes #13957
fixes #11565
fixes #15770
fixes #15946
fixes #18254
fixes #19731
fixes #20112
fixes #22472
fixes #23697
fixes #24727
fixes #47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.

PR Close #55102
iteriani pushed a commit to iteriani/angular that referenced this issue Apr 18, 2024
…zone (angular#55102)

When Angular receives a clear indication that change detection should
run again, this should not be ignored, regardless of what Zone it
happened in. This change updates the default change detection scheduling
approach of Zone-based applications to ensure a change detection will
run when these events happen outside the Angular zone (which includes,
for example, updating a signal that's read in a template, setting an
input of a `ComponentRef`, attaching a view marked for check, calling
`ChangeDetectorRef.markForCheck`, etc.).

This does not apply to applications using `NoopNgZone` or those which
have a custom `NgZone` implementation without ZoneJS.

The impact of this change will most often be seen in existing unit tests. Tests
execute outside the Angular Zone and this can mean that state in the
test is not fully recognized by Angular. Now that Angular will ensure
change detection _does_ run, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior. Often, this should be seen
as more correct and the test should be updated, but in cases where it is
too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

fixes angular#55238
fixes angular#53844
fixes angular#53841
fixes angular#52610
fixes angular#53566
fixes angular#52940
fixes angular#51970
fixes angular#51768
fixes angular#50702
fixes angular#50259
fixes angular#50266
fixes angular#50160
fixes angular#49940
fixes angular#49398
fixes angular#48890
fixes angular#48608
fixes angular#45105
fixes angular#42241
fixes angular#41553
fixes angular#37223
fixes angular#37062
fixes angular#35579
fixes angular#31695
fixes angular#24728
fixes angular#23697
fixes angular#19814
fixes angular#13957
fixes angular#11565
fixes angular#15770
fixes angular#15946
fixes angular#18254
fixes angular#19731
fixes angular#20112
fixes angular#22472
fixes angular#23697
fixes angular#24727
fixes angular#47236

BREAKING CHANGE:

Angular will ensure change detection runs, even when the state update originates from
outside the zone, tests may observe additional rounds of change
detection compared to the previous behavior.

This change will be more likely to impact existing unit tests.
This should usually be seen as more correct and the test should be updated,
but in cases where it is too much effort to debug, the test can revert to the old behavior by adding
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the `TestBed` providers.

Similarly, applications which may want to update state outside the zone
and _not_ trigger change detection can add
`provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})`
to the providers in `bootstrapApplication` or add
`schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the
`BootstrapOptions` of `bootstrapModule`.

PR Close angular#55102
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants