fix(tooltip/snackbar): use overlay service size registry to set initial size - master

[RivaIvanova]

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

[wnvko]

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.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

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

[RivaIvanova]

@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).

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).

However, the result is the following:

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.

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)

And the igx-overlay__content had no styles at all, e.g., style="width: 200px".

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.