Closed bdryanovski closed 4 years ago
With the deprecation of ClrAriaLiveService for internal use, we won't have this issue anymore
Hi there 👋, this is an automated message. To help Clarity keep track of discussions, we automatically lock closed issues after 14 days. Please look for another open issue or open a new issue with updated details and reference this one as necessary.
Describe the bug
clr-error
when into the context ofclr-input-container
is rendered and then hidden. This is preventingAriaLiveService
of updating and announcing the message inside the error. Also preventing the native angular lifecycles of firing.How to reproduce
clr-control-error
will be rendered andaria-live
container will be createdclr-control-error
is now visibleclr-control-error
so thearia-live
container is still inside the DOMclr-control-error
is visible - no update to thearia-live
is made so no new annoncement fromAriaLiveService
The only way to remove the
aria-live
DOM element is to detachclr-input-container
from the DOM.Content Projection is rendering the components before moving them inside the
clr-input-container
template. This is making some of the lifecycles behave in a strange way. For exampleonDestroy
is not called when a component is hidden/shown with*ngIf
. Angular is keeping the components alive until the parent is destroyed and reusing the same instance.Expected behavior
Error content must be read from SR when it's rendered on the screen. As many times as the error happens.
Versions
All versions are affected.
Additional notes
A solution could be the use of
ngTemplateOutlet
but this will result in a breaking change. Another option could be providing a service that will provide both the container and the error with a message when the error is visible and when not, to forceAriaLiveService
to announce the message or remove it.