Set top toolbar size dynamically #53526
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
draganescu
added
[Type] Enhancement
|
Size Change: +393 B (0%) Total Size: 1.51 MB
ℹ️ View Unchanged
|
This was referenced Aug 10, 2023
draganescu
added
[Type] Bug
|
Changed the labels from enhancement to bug, because although the behavior is an enhancement the enhancement's only purpose is to fix the bugs in the current top toolbar implementation. |
|
Nice! Big improvement. Before the toolbar would quickly cover the publish button:
After, it never does, it adds horizontal scroll:
This is an improvement in 80% of cases, however I do still think that horizontal scroll of the block toolbar is something to mostly avoid. And to that end around the 782 breakpoint ($break-medium), we should still hide the publish/save area like we do today. So a mix of the trunk, and this. What do you think? |
|
Yes @jasmussen good catch losing the |
|
Flaky tests detected in 9c709844020d65b2e88f4996d4d8504626a4f56a. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5855181140
|
getdave
reviewed
Aug 11, 2023
| return; | ||
| } | ||
|
|
||
| const blockToolbar = document.querySelector( |
There was a problem hiding this comment.
I wonder as we're consuming classnames here whether we could/should add an e2e tests that simply asserts those classes are in the DOM. That way if they get removed this won't break.
There was a problem hiding this comment.
This might be a bit far-fetched but could we instead of querying the DOM check for the same conditions that allow the contextual toolbar to render? And then pass the styles to the contextual toolbar component instead of setting them directly below?
Otherwise, can we reuse this blockToolbar const below instead of repeating the query?
There was a problem hiding this comment.
We need to know if the toolbar is visible here so we can apply the styles to it depending on the width of all the pinned items. From settings we can know the toolbar should show, but we don't know if it is actually in the dom, and then we get a problem when trying to set the dynamic width.
I will reuse the variable though 🙏🏻
There was a problem hiding this comment.
Thanks for the PR!
The overflow changes are breaking things a little when scrollbars are always visible:
On mac:
On windows 11:
With text labels enabled, the overflow is there even if scollbars are set to auto:
And weirdly if you click outside of the block toolbar, it goes under the top toobar:
|
The visible scrollbars are causing havoc @tellthemachines - I wonder how could I fix that ... |
|
When scrollbars are auto/text labels are enabled, removing 
I'm not sure why that rule was added in the first place, so might break something else if it's removed 😅 but perhaps a local override would work? With fixed scrollbars I'm not sure what to do 😬 |
|
@tellthemachines I've added a specific fix for when the block toolbar is fixed and show icon labels is active so that the collapse button stays on its row. Thanks for the trick! :) I don't know of any way to solve the scrollbar when visible issue. If I could detect when they're always on maybe some height adjustment of the toolbar to make buttons and scrollbar fit into the header would be nice. But alas, no such flag. @jasmussen should we go ahead with this situation until we figure out a better solution? Should I fiddle with the height of the toolbar and buttons? It's worth noting that even if the toolbar were implemented as a flex container inside the header, if the user had the scrollbars visible at all times they would still show, since in that case the behavior done by this PR would be forced by the browser. |
The height should stay locked in place. I agree there's a great deal to consider for labels only mode, I have on my todo to give that one some love, and I expect in a huge amount of cases we will have to build an overflow system for dropdowns (a la Google Docs responsive). I would also think it shouldn't hold up this PR, because it was also an issue with the stacked toolbar, and the original labels only mode was merged in spite of that. |
|
@jasmussen about holding up the PR I meant to say about the overflowing scrollbar when scrollbars are always on:
|
|
Ah, thanks for the clarification. Hrm. I'll take a quick look |
|
Took it for a spin, and I'm having trouble getting the horizontal scrollbar to show up at all. It's easy enough to get into a situation that should invoke the scrollbar, just enable text-labels, and that feels like an obvious case of getting things to scroll. I think we can get the scrollbars to remain and fit within those boundaries. There's a new mixin for more compact scrollbars, and I'm happy to help fiddle the CSS to get it just right: It's in use on the site editor page, and feels perfect for this. |
draganescu
force-pushed
the
toptoolbar/fix-sizing-for-plugins
branch
from
9c70984
to
68c99ca
Compare
|
@jasmussen looks like it works :/ top-scroll.mp4also, I added the mixin in the video but that makes the scrollbars always show ... |
|
I'm still having trouble reproducing the horizontal scrollbar, my viewport is around 1000px wide and I'm testing with text labels on. I would think that the way we land this is:
|
You need to have scrollbars set to always show in your system settings on mac, or else test on Windows where they always show by default 😄 I can see it at 1200px with icon buttons: 
The other issue with the text labels is fixed, thanks Andrei! |
|
I pushed a tweak to get it working decently well:
Have a look and let me know what you think. In general it seems like the positioning CSS could be simplified a bit. Instead of using a top padding of 7px to perfectly overlay the icons, we can ensure the height of the top toolbar is the same height as the toolbar it's covering, and then use flex center alignment, that simplifies a couple of things. |
There was a problem hiding this comment.
This is working really well after the latest changes, thanks @draganescu and @jasmussen!
Just one comment below about the DOM querying behaviour, but apart from that code LGTM.
| return; | ||
| } | ||
|
|
||
| const blockToolbar = document.querySelector( |
There was a problem hiding this comment.
This might be a bit far-fetched but could we instead of querying the DOM check for the same conditions that allow the contextual toolbar to render? And then pass the styles to the contextual toolbar component instead of setting them directly below?
Otherwise, can we reuse this blockToolbar const below instead of repeating the query?
draganescu
force-pushed
the
toptoolbar/fix-sizing-for-plugins
branch
from
5922177
to
4c3b612
Compare
…n, no block selected, icon labels height
draganescu
added
Backport to WP Minor Release
Closed
ramonjd
added a commit
that referenced
this pull request
Aug 31, 2023
|
I just cherry-picked this PR to the bugfixes/wp-6.3.2 branch to get it included in the next minor release 🤞🏻 . |
ramonjd
removed
the
Backport to WP Minor Release
ramonjd
pushed a commit
that referenced
this pull request
Aug 31, 2023
* fix the top toolbar size in the space remaining after plugin items are pinned * only resize above the tablet breakpoint * fix fixed block toolbar collapse button when icon labels are shown * Update height and scroll behavior * move the layout effect to the affected component, fixes for fullscreen, no block selected, icon labels height --------- Co-authored-by: jasmussen <joen@automattic.com>
tellthemachines
added a commit
that referenced
this pull request
Sep 1, 2023
* Update document title buttons radius (#53221) * Fix: Sync status overlaps for some languages in Patterns post type page (#53243) * Image block: Fix stretched images constrained by max-width (#53274) * Fix dragging to resize from stretching image in the frontend * Add image block v7 deprecation * Update deprecation comment * Prevent image losing its aspect ratio at smaller window dimensions * Revert "Prevent image losing its aspect ratio at smaller window dimensions" This reverts commit 8ac9f8c. --------- Co-authored-by: scruffian <ben@scruffian.com> * Image Block: Don't render `DimensionsTool` if it is not resizable (#53181) * Fix missing Replace button in content-locked Image blocks (#53410) * Revert "don't display BlockContextualToolbar at all in contentonly locking (#53110)" This reverts commit 5efce0e. * Alternative fix to hide BlockContextualToolbar when there are no controls * fix the go to for non pages by showing it only for pages (#53408) * Site Editor: Fix document actions label helper method (#52974) * Site Editor: Fix document actions label helper method * Add missing useSelect dep * Fix e2e tests * Move the label map at the file level to avoid recreating the object on every render * Image: Clear aspect ratio when wide aligned (#53439) * RichText: Remove 'Footnotes' when interactive formatting is disabled (#53474) Introduce a new 'interactive' setting for format types * Preserve block style variations when securing theme json (#53466) * Preserve block style variations when securing theme json Valid and safe block style variations were being removed by `WP_Theme_JSON_Gutenberg::remove_insecure_properties` when securing the theme.json. When this was a problem varied depending upon site configuration, but out-of-the-box it was a problem for administrators on multi-site installs. This change adds explicit processing of variations in `remove_insecure_properties` so that they won't get removed. * Add another variation sanitisation test This test checks that when removing insecure properties an unknown/unsupported property is removed from the variation. * Site editor: add missing i18n in `HomeTemplateDetails` (#53543) * Site editor: add missing i18n in `HomeTemplateDetails` * Lint fix * Fix: Snack bar not fixed on certain pages in the Site Editor (#53207) * Fix document title alignment in command palette button (#53224) * Fallback to default max viewport if layout wide size is fluid. (#53551) * Link Control: persist advanced settings toggle state to preferences if available (#52799) * Link Control: Create a preference for whether the advanced section is open * move the useSelect to the component that uses it * Supply preference setter via settings * Pass setter to Post Editor * Provide local state fallbacks in absence of preference store settings * Conditionalise display of settings drawer to “edit” mode only * Extract to constant to improve comprehension * Fix bug in preferences resolution * Improve comments * Add e2e scaffold * Fix e2e test to correctly assert on feature * Remove focused test * Reinstate original logic to hide settings when not required * Scaffold documentation * Revert providing prefs via settings * Refactor to use `core/block-editor` as preference scope * Update docs * Reinstate remaining original conditional * tentative fix for the e2e test * Try a different syntax for shiftAlt * another attempt to fix the e2e test --------- Co-authored-by: Dave Smith <getdavemail@gmail.com> Co-authored-by: MaggieCabrera <maggie.cabrera@automattic.com> * Add tests for fluid layout + typography (#53554) * Fix support of sticky position in non-iframed post editor (#53540) * Fix support of sticky position in non-iframed post editor * Revert "Footnotes: Fix recursion into updating attributes when attributes is not an object (#53257)" This reverts commit ab04074. * Fix: indicator style when block moving mode (#53972) * Fix post editor top toolbar with custom fields in Safari (#53688) * Set top toolbar size dynamically (#53526) * fix the top toolbar size in the space remaining after plugin items are pinned * only resize above the tablet breakpoint * fix fixed block toolbar collapse button when icon labels are shown * Update height and scroll behavior * move the layout effect to the affected component, fixes for fullscreen, no block selected, icon labels height --------- Co-authored-by: jasmussen <joen@automattic.com> * Roll back camelCase change in 96b6b1e --------- Co-authored-by: James Koster <james@jameskoster.co.uk> Co-authored-by: Aki Hamano <54422211+t-hamano@users.noreply.github.com> Co-authored-by: Alex Lende <alex+github.com@lende.xyz> Co-authored-by: scruffian <ben@scruffian.com> Co-authored-by: Robert Anderson <robert@noisysocks.com> Co-authored-by: Andrei Draganescu <me@andreidraganescu.info> Co-authored-by: George Mamadashvili <georgemamadashvili@gmail.com> Co-authored-by: Dean Sas <dean.sas@automattic.com> Co-authored-by: Pascal Birchler <pascalb@google.com> Co-authored-by: Dave Smith <getdavemail@gmail.com> Co-authored-by: MaggieCabrera <maggie.cabrera@automattic.com> Co-authored-by: Mitchell Austin <mr.fye@oneandthesame.net> Co-authored-by: jasmussen <joen@automattic.com> Co-authored-by: ramon <ramonjd@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Dinamycally adjusts the top toolbar to fit in the remaining visual space between the left hand tools and the right hand pinned items.
Why?
Because the current situation will overal various UI elements depending on the number of plugins installed.
How?
Using a layout effect I measure what's on the right side in the post editor and the site editor and deduct it from total toolbar width. It's, again, a small patch for a big wound - but it's perfectly possible if it becomes a big problem.
Testing Instructions
Testing Instructions for Keyboard
N/A
Screenshots or screencast
top-toolbar-layout-effect.mp4