Skip to content

fix(action-strip): Assign parent to not destroy on DOM move. #16270

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.

Sign up for GitHub

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

Merged
dkamburov merged 10 commits into from
Oct 27, 2025
Merged

fix(action-strip): Assign parent to not destroy on DOM move. #16270

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
5ac7a0d
fix(action-strip): Assign parent to not destroy on DOM move.
Jun 16, 2025
01683e7
chore(*): Move strip handling after parentComponentRef is populated.
Jun 16, 2025
fbd1785
fix(action-strip): Fix timing issues.
Jun 20, 2025
a8642fd
fix(igxGridRow): On destroy check for still shown action strip.
Oct 9, 2025
ec11d6d
chore(action-strip,elements): minor new lines formatting
damyanpetev Oct 10, 2025
7201841
fix(igxGrid): On detach also check for still shown action strip.
Oct 13, 2025
89b1eb8
Merge branch 'mkirova/fix-15768-20.1.x' of https://github.com/IgniteU…
Oct 13, 2025
f18b2f4
chore(*): Add null check.
Oct 13, 2025
9399e0b
chore(*): Add angular tests.
Oct 23, 2025
a0e57de
chore(*): Add elements test for actionstrip.
Oct 23, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions projects/igniteui-angular-elements/src/app/custom-strategy.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -131,6 +131,7 @@ class IgxCustomNgElementStrategy extends ComponentNgElementStrategy {
parentComponentRef = await parent?.ngElementStrategy[ComponentRefKey];
parentAnchor = parentComponentRef?.instance.anchor;
}

Comment thread
damyanpetev marked this conversation as resolved.
Outdated
} else if ((parent as any)?.__componentRef) {
this.angularParent = (parent as any).__componentRef;
parentInjector = this.angularParent.injector;
Expand Down
3 changes: 3 additions & 0 deletions projects/igniteui-angular/src/lib/action-strip/action-strip.component.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -279,6 +279,9 @@ export class IgxActionStripComponent implements IgxActionStripToken, AfterConten
* ```
*/
public show(context?: any): void {
if(!this._originalParent) {
Copy link
Copy Markdown
Member

@damyanpetev damyanpetev Oct 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, if every workflow goes through show we might even move the caching of the original parent here ngAfterViewInit where it was originally, so both cache and return are on the show/hide pair.

Anyway, I'm assuming this fixes the disappearing strip if it inits in some case as detached, but still is attached before showing.

this._originalParent = this._viewContainer.element.nativeElement?.parentElement;
}
this.hidden = false;
if (!context) {
return;
Expand Down
2 changes: 1 addition & 1 deletion ...ects/igniteui-angular/src/lib/action-strip/grid-actions/grid-editing-actions.component.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -147,7 +147,7 @@ export class IgxGridEditingActionsComponent extends IgxGridActionsBaseDirective
const context = this.strip.context;
const grid = context.grid;
grid.deleteRow(context.key);

this.grid.cdr.detectChanges();
Copy link
Copy Markdown
Member

@damyanpetev damyanpetev Oct 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, the original parent bit I get, but do we really need this? Any context why a full grid change detection is needed/doing?

Copy link
Copy Markdown
Member

@damyanpetev damyanpetev Oct 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Surely the deletion and CRUD service will also do that if needed, so this one would be extra even.

Copy link
Copy Markdown
Contributor Author

@MayaKirova MayaKirova Oct 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

deleteRow removes the record from the data, but the actual removal of the DOM element happens on the next change detection. This creates a bit of a timing issue.

I no longer remember the details, since it has been a while, however I can confirm that the code does not work without the change detection (the issue reproduces without the change detection and is fixed with the change detection).

Copy link
Copy Markdown
Contributor Author

@MayaKirova MayaKirova Oct 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@damyanpetev Here are a few observation.

The issue is specifically when you delete the last row and there's no next row in the grid, for example you have a grid with only 2 rows and you delete the second one. So this means that the RowComponent associated with the row will be destroyed. The issue happens when the moment the row is destroyed the action strip is still inside it:

image

Hence the destroy and removal of the row, also removes and destroys the action strip.

To me it seems that the logic that moves the action strip back to the root of the grid, the one inside the hide API:

  this.renderer.appendChild(this._originalParent, this._viewContainer.element.nativeElement);

Happens asynchronously - so it does not immediately move it to the root in time, before angular goes and destroys the parent. So regardless of the order:

        this.strip.hide();
        grid.deleteRow(context.key);

or

 grid.deleteRow(context.key);
 this.strip.hide();

It never manages to move the strip out of the row in time.

Also another fun observation - if you debug the deleteRowHandler code or the one inside the hide method, the issue stops reproducing as then the code executes synchronously and moves the strip to the root just fine.

Adding a change detection somewhere in the deleteRowHandler (doesn't matter where - before, between or after the other actions) seems to force it to resolve the operation and causes it work again.

Copy link
Copy Markdown
Member

@damyanpetev damyanpetev Oct 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MayaKirova you're right to suspect something async happening, sure, except it's not the appendChild being async (that one is very much synchronous for the dom version). The The actual delete calls markForCheck and the actual re-render happens on next cycle so order of calls in that location doesn't change the outcome.

What I'm actually observing is quite interesting:

this.strip.hide();

works exactly as it should and moves the strip back to the grid element (can confirm with a simple log to avoid messing with timing during debug). Except something else moves the strip back to the row and gets it deleted permanently from the DOM by destroying the row. That's why the detectChanges() helps, cuz it forces the deletion to happen first, so the return to DOM on hide() sticks.

Logpoint at the end of hide like so
image
and one on renderer.removeChild yields the following when I hit the delete on a single row:
image

So the actual issue which I haven't dug out yet - why on earth is the action strip returning to its row just before it gets destroyed so it can deleted along with its DOM host.

Copy link
Copy Markdown
Contributor Author

@MayaKirova MayaKirova Oct 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@damyanpetev It seems to me that the show gets called after the hide, so it moves it back:
image
Probably because the row is not yet deleted and the mouse is still over it.

Copy link
Copy Markdown
Member

@damyanpetev damyanpetev Oct 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image Yeah, was just going to note that there's a secondary show()

this.strip.hide();
Comment thread
damyanpetev marked this conversation as resolved.
}

Expand Down
Loading