file-viewer: overlapping buttons and duplicate download in unsupported fallback

[ha2818an]

After enabling allowDownload={true} on <limel-file-viewer> (BB PR #1432), two visual problems surfaced:

Problem 1: Toolbar buttons overlap with consumer-positioned UI

.buttons in file-viewer/partial-styles/ui-controls.scss is position: absolute; top: 0.25rem; right: 0.25rem. Any consumer that places its own controls in the top-right (e.g. limebb-summary-popover puts its close button at top: 0.125rem; right: 0.125rem) will collide. With more allow* flags enabled, more buttons stack down and the collision area grows.

There's no CSS ::part exposed on .buttons and no CSS variable for offset, so consumers can't reposition the toolbar.

Problem 2: Duplicate download button in renderText / renderEmail fallback

renderText (file-viewer.tsx:265-274) and renderEmail (file-viewer.tsx:276-291) render renderButtons() (the toolbar) AND wrap their <object> / <limel-email-viewer> with renderNoFileSupportMessage() as fallback. That message has its own inline download button (file-viewer.tsx:343). When the embedded view fails to render natively (observed for .json blob URLs in Chrome), both render → two download buttons.

Related

• BB PR that enabled allowDownload and surfaced these: https://github.com/Lundalogik/lime-crm-building-blocks/pull/1432
• The popover wrapping uses limebb-summary-popover via limebb-document-chips, which now renders attachment previews in the email composer.

[ha2818an]

@Kiarokh Do you have time to take a look at what you think the best approach is for the double button + "x" overlap? For background: https://lime-technologies.slack.com/archives/C02HTNQK2G0/p1778482077733339

Context:
limebb summary popover positions it's "x" aboslute top-right and file-viwer renders its own toolbar (.buttons at top: 0.25rem; right: 0.25rem per ui-controls.scss)

Options

1. BB-only: move the X based on file presence. In summary-popover.tsx, conditionally set closeButtonStyle to top-left (or further down on the right) when file is set. Smallest change, one repo, no upstream
   cascade. Trade-off: top-right close is convention; moving it may hurt discoverability. Sample change:

const closeButtonStyle = {
    position: 'absolute',
    top: '0.125rem',
    ...(this.file
        ? { left: '0.125rem' }
        : { right: '0.125rem' }),
};

2. lime-elements: expose a CSS var or ::part for .buttons top offset. BB summary-popover sets --limel-file-viewer-buttons-offset-top: 3rem (or similar) so the toolbar starts below the X. Trade-off: requires
   lime-elements release + BB bump + lime-webclient cascade.. slow, but doesn't move the X out of convention. Doesn't address the dedup issue.
3. lime-elements — dedup renderNoFileSupportMessage's inline button when called as fallback inside renderText/renderEmail, and expose the buttons-offset CSS var. Fixes both the duplicate and the overlap
   upstream. Biggest scope, but cleanest semantically. Note: dedup alone is not enough, the overlap on supported files (Problem 1 above) is independent of dedup.

Any other approach you might find is better is welcome :))

[Kiarokh]

sorry I never had time to get back to you. @LucyChyzhova do you think you can help during the cooldown?

[LucyChyzhova]

sure, i will take a look!