Skip to content

#7159 - Top toolbar doesn't fit the frame in case of two ketcher instanses - #11919

Open
mariam-khutuashvili wants to merge 1 commit into
masterfrom
7159-top-toolbar-doesnt-fit-the-frame-in-case-of-two-ketcher-instanses
Open

mariam-khutuashvili wants to merge 1 commit into
masterfrom
7159-top-toolbar-doesnt-fit-the-frame-in-case-of-two-ketcher-instanses

Conversation

@mariam-khutuashvili

@mariam-khutuashvili mariam-khutuashvili commented Sep 17, 2026

Copy link
Copy Markdown
Collaborator

How the feature works? / How did you fix the issue?

(Screenshots, videos, or GIFs, if applicable)
The top toolbar collapsed its external-function buttons only below a fixed 650 px, a threshold last tuned in 2022. Buttons were added since, and the expanded toolbar now needs 732 px in the narrow layout, so every width between 650 and 732 px overflowed — which is exactly the width each instance gets on the duo page, pushing the zoom control outside the frame.

  • getExpandedToolbarWidth computes the width the expanded toolbar actually needs from what is rendered: visible top-toolbar buttons at the icon size of the current container-query regime (28/32/40 px), the three dividers, the mode switcher (icon-only or labelled from 900 px), the zoom control and custom buttons. TopToolbar collapses when the panel is narrower than that.
  • Hidden buttons are subtracted, so the toolbar no longer collapses early with hiddenControls — this also resolves Buttons are collapsed in the top toolbar because hidden buttons are not taken into account #3840.
  • The old CUSTOM_BUTTON_ADDITIONAL_WIDTH = 40 is gone: custom buttons share the icon-button styles and are counted as such.

No rendering or test ids change. Verified in the browser: the duo page at 1498 px collapses both toolbars with no overflow; the single page swept from 1100 down to 560 px never overflows and collapses exactly where the buttons stop fitting; the #3840 URL at 690 px keeps its remaining buttons inline; the popup dialog (800 px) stays expanded as before, so no screenshot baselines move. Unit-tested against the measured widths of the three layout regimes.

Check list

  • unit-tests written
  • e2e-tests written
  • documentation updated
  • PR name follows the pattern #1234 – issue name
  • branch name doesn't contain '#'
  • PR is linked with the issue
  • base branch (master or release/xx) is correct
  • task status changed to "Code review"
  • reviewers are notified about the pull request

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

1 participant