[Chrome] Fix extension truncation

[Dosant]

Summary

In #82015 we introduced new extension point for chrome that allows externally append an element to the last breadcrumb.

That is needed for future send to background UI: #81004
Mocks https://whimsical.com/LMKSnR7vmPrmAypPXYuA8T

I noticed a bug, that extension is not visible in case last breadcrumb is truncated (for example on a mobile device inside a dashboard app with a long dashboard title).

This pr attempt to fix it:

Checklist

Delete any items that are not applicable to this PR.

• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[pgayvallet]

In #82015 (review) we discussed about a future improvement to allow plugins to mutate the breadcrumb. I think it would be easier to migrate to it later if you were altering the last breadcrumb element instead of creating a flexGroup around it.

Would somethink like

lastCrumb.text = (
    <EuiFlexGroup responsive={false} gutterSize={'none'} className="eui-textTruncate">
      <EuiFlexItem grow={false} className="eui-textTruncate">
        {lastCrumb.text}
      </EuiFlexItem>
      <EuiFlexItem grow={true} className="chrHeaderNavBreadcrumbs__appendExtensionContainer">
        <HeaderExtension extension={breadcrumbsAppendExtension.content} />
       </EuiFlexItem>
    </EuiFlexGroup>
);

solves the truncation on small width, or are you forced to have the extension outside of the breadcrumb element?

[Dosant]

That've almost worked:

Just no ... after the title :(

[pgayvallet]

text-overflow is always a pain to use properly. Anyway, as @kibana-design has been requested for review, maybe they could take a look. Else, keeping it as it is would be fine.

[MichaelMarcialis]

The reason the text-overflow: ellipsis; isn't being honored here is because the EuiFlexItem components have a style of display: flex;. Changing the offending EuiFlexItem to display: block; should remedy it (if this is a path you would prefer to take).

[Dosant]

@MichaelMarcialis, thanks for the tip! it helped and I made it this way.

[MichaelMarcialis]

Hello. I've left two small comments for your review.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 29e6c97

Metrics [docs]

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
core	547.3KB	547.4KB	+151.0B

History

• 💚 Build #87043 succeeded fbfa07215d9e5e3b57f338090669d04f9d0edb35
• 💚 Build #86896 succeeded 70d67dbb3bab69803f911ea6898bc4d0a057c6c9
• 💔 Build #86888 failed 5876f16c50fdfbdf12a499c851405019b7e8983d

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[pgayvallet]

LGTM!

[pgayvallet]

NIT: isn't bool(crumbs[crumbs.length - 1]) just bool(crumbs.length) but harder to read 😅 ?

[MichaelMarcialis]

This appears to work as advertised. Before giving my stamp of approval, CCing @cchaos for her opinions regarding:

1. Is this usage of EuiFlexGroup without subsequent EuiFlexItem acceptable? I don't see why it wouldn't be, but thought I'd ask, as this is the first time I'm seeing it used this way.
2. Would this pushing of the modified last breadcrumb markup into the breadcrumb component's markup be frowned upon?

[cchaos]

@MichaelMarcialis To answer your specific questions:

1. It's ok to not use EuiFlexItem so long as the layout your creating is intended with EuiFlexGroup
2. It is less that appending a custom breadcrumb is frowned upon than that this is causing some render issues.

For instance the text alignment is not quite right

And in the new Amsterdam theme, the styles are especially off.

We can merge this for now, but most likely, EUI will have to provide something on the component side to support this directly.