I don't see any difference, with or without the patch. Can you supply a screen shot showing what to look for?

I don't see any difference, with or without the patch. Can you supply a screen shot showing what to look for?

Same for me. In both cases without and with this PR I have the popup message above the search box.

@ceford I think I found our both mistake: It is not the search box in the toolbar of the list view we have to check, it is the search box at the right bottom place of the edit dialogue when creating a new override or editing an existing one ;-)

thats why screenshots are so helpful ;)

thats why screenshots are so helpful ;)

Agree.

Beside that, this status message seems to be a tricky thing. Currently it doesn't show up at all, whatever I do.

Ahhh .. you have to clear the cache in the list view so the message about cache recreation is shown when entering the search box in the edit view.

was just typing that info for you ;)

I have tested this item ✅ successfully on ed26f38

Very tricky to reproduce the issue.

1. It is the search box at the bottom right corner of the edit dialog when creating a new language override or modifying an existing one, not the one in the list view like I first thought.
2. The status message about cache rebuild only appears if cache cleared in the list view and then logged out and in again, or if using another language and site combination which hasn't been used before.
3. It needs a very large display to reproduce the issue with the message appearing beside the search field and so making it shrink.

But I can confirm that this PR solves that issue.

I am fairly certain that this breaks the accessibility by putting the message in a new div instead of inside the input div

Even with aria-hidden="true" for the message?

that is on the icon not on the text. You want the text to be accessible and connected to the input

I have not tested this item.

Changing back to not tested until some feedback from an accessibility expert.

Below the Search Text Field I see a brief message: 'Please Wait while the cache is recreated' on the first click only, with an without the patch. It most vanishes instantly. Clearing the cache in the list view does not make it reappear. It does reappear if I select a different client or language. As far as I can tell the patch does nothing!

@ceford What is your monitor's resolution? On 1920x1080, this can be reproduced.

Updated with screenshots in the original post.

I am using a Macbook Pro - a screen grab is 2880 x 1498 but I think the horizontal resolution is really 1440. I only see the message below the Search Text field so I guess it has already wrapped - mystery solved.

@Quy Regarding Brian's comment about accessibility: Would it be an alternative solution to leave HTML markup like it is, i.e. a span, and add some css for block display? This should be still accessible.

Not sure if it is a a11y issue. IBut also for sighted users it would be nice to hide the input group while the search is going on.

@Quy There is no need to put the span .help-block in a new div outside div .input-group.
It seems that .input-group is styled with display: flex;flex-wrap: wrap;.
Just add add flex-basis: 100% to .help-block the issue is solved.
Can you adjust your PR with this change?

Run npm build:css after applying the patch to test the change.

Just add add flex-basis: 100% to .help-block the issue is solved.

With reverting your changes the className .help-block is gone too.
Please adjust your PR to a flex-basis on #refresh-status only.

I always prevent touching with id's and try to work with classNames instead.
But using id #refresh-status is consistent with the rest of the css document.

Done. Thanks!

For those who want to test this issue.
After applying the patch you have to run npm run build:css.
After reverting the patch you should run the same command again.

I have tested this item ✅ successfully on a11e80e

run command npm run build:css after applying the page to see the change

I have tested this item ✅ successfully on a11e80e

rtc

Tks