Skip to content

Conversation

@RivaIvanova
Copy link
Member

Closes #16458

Additional information (check all that apply):

  • Bug fix
  • New functionality
  • Documentation
  • Demos
  • CI/CD

Checklist:

  • All relevant tags have been applied to this PR
  • This PR includes unit tests covering all the new code (test guidelines)
  • This PR includes API docs for newly added methods/properties (api docs guidelines)
  • This PR includes feature/README.MD updates for the feature docs
  • This PR includes general feature table updates in the root README.MD
  • This PR includes CHANGELOG.MD updates for newly added functionality
  • This PR contains breaking changes
  • This PR includes ng update migrations for the breaking changes (migrations guidelines)
  • This PR includes behavioral changes and the feature specification has been updated with them

This comment was marked as outdated.

@RivaIvanova RivaIvanova added the ❌ status: awaiting-test PRs awaiting manual verification label Jan 30, 2026
@RivaIvanova RivaIvanova changed the title fix(overlay): conditionally cache element size fix(overlay): conditionally cache element size - master Jan 30, 2026
@RivaIvanova RivaIvanova requested a review from wnvko January 30, 2026 16:33
Copy link
Contributor

@wnvko wnvko left a comment

Choose a reason for hiding this comment

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

So we know this PR is breaking the tooltip. What is the reason this happening? Can we revert the change that made this happen?
Adding this additional property to the overlay settings and use it in this way in the tooltip looks like a breaking change. IMO it will be better to find out what happened in the above mentioned PR and to revert it.

@RivaIvanova RivaIvanova added 🛠️ status: in-development Issues and PRs with active development on them and removed ❌ status: awaiting-test PRs awaiting manual verification labels Feb 4, 2026
@RivaIvanova RivaIvanova changed the title fix(overlay): conditionally cache element size - master fix(tooltip/snackbar): use overlay service size helpers - master Feb 6, 2026
@RivaIvanova RivaIvanova requested a review from Copilot February 6, 2026 14:26
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

@RivaIvanova RivaIvanova requested a review from Copilot February 9, 2026 14:36
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.

Comment on lines +1006 to +1018
/**
* Measures the element's initial size and controls *when* the element is moved into the overlay outlet.
*
* The elements inherit constraining parent styles, so
* for some of them (e.g., Tooltip, Snackbar) their pre-move size is incorrect.
* Those can **override** this method to measure **after** moving to get an accurate size.
*
* - **Default**: Measures in-place (current parent), then moves to the overlay.
*
* @param info OverlayInfo for the content being attached.
* @param moveToOverlay Moves the element into the overlay.
*/
private setInitialSize(info: OverlayInfo, moveToOverlay: () => void): void {
Copy link

Copilot AI Feb 9, 2026

Choose a reason for hiding this comment

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

The doc/comment claims consumers can “override this method”, but setInitialSize is private, so it can’t be overridden. The actual extension mechanism is OverlaySizeRegistry.register(...). Reword the comment to reflect the registry-based override (e.g., “Components can register an override via OverlaySizeRegistry to measure after moving”).

Copilot uses AI. Check for mistakes.
AbsolutePosition, ConnectedFit, HorizontalAlignment, OffsetMode, OverlayAnimationEventArgs, OverlayCancelableEventArgs, OverlayClosingEventArgs,
OverlayCreateSettings, OverlayEventArgs, OverlaySettings, Point, PositionSettings, RelativePosition, RelativePositionStrategy, Size, VerticalAlignment, Util,
IgxOverlayOutletDirective
IgxOverlayOutletDirective, OverlayInfo, OverlaySizeRegistry
Copy link

Copilot AI Feb 9, 2026

Choose a reason for hiding this comment

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

OverlaySizeRegistry is introduced in utilities.ts with @hidden @internal JSDoc, but it’s now re-exported from the core public API. This is inconsistent and may unintentionally expose an internal hook to library consumers. Either (1) keep it public and remove/adjust the @internal marker + add minimal API docs, or (2) avoid re-exporting it from the public entrypoint and instead consume it via an internal/shared entrypoint intended for cross-package internals.

Suggested change
IgxOverlayOutletDirective, OverlayInfo, OverlaySizeRegistry
IgxOverlayOutletDirective, OverlayInfo

Copilot uses AI. Check for mistakes.
@RivaIvanova
Copy link
Member Author

@wnvko The linked PR does not break the tooltip. This PR was merged in version 20.1.0, but the behavior is observed in version 15.0.x too (maybe even before that, but I tested with that version).
tooltip-inside-icon-button

The PR adds a lot of changes, but the one that is related to the current behavior is adding this CSS:

min-width: rem(24px);
max-width: rem(200px);
width: fit-content;

The new styles did not break the tooltip, but revealed the already broken behavior.

Overall, it is due to the element's size (width) being measured before being moved to the overlay content. If the element does not have a specific width set, like 100px, its size is affected by the styles that come from the parent container.

For example, consider this template:

<div style="background: red; text-transform: uppercase; letter-spacing: 8px;" [igxTooltipTarget]="themeTooltipRef4">
    Parent Element
    <div #themeTooltipRef4="tooltip" igxTooltip>Click to toggle between dark/light themes</div>
</div>

The parent element (red div) has these styles text-transform: uppercase; letter-spacing: 8px; and I would expect the igx-overlay__content to look somewhat like in the image, with a width of 194.99px (the size of the tooltip).
tooltip-inside-parent-with-styles-expect

However, the result is the following:
tooltip-inside-parent-with-styles-actual

That's because the tooltip/element is measured and then moved to the overlay. While being measured, the tooltip is affected by the styles of the parent, and a bigger size is set as the initialSize.width.
tooltip-inside-parent-with-styles-reason

The snackbar behavior is due to this PR. Not exactly breaking it, since before this PR, the snackbar had no size (perhaps because it was not present in the view yet)
image
And the igx-overlay__content had no styles at all, e.g., style="width: 200px".
image

I removed the additional property from the overlay settings and implemented a different approach, but similar to the previous one, it requires moving the element to the overlay and then getting its size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Tooltip/Snackbar]: overlay content size is not properly reflected when component is placed inside another element

2 participants