feat(components): Improve FormField Toolbar UX

[jdeichert]

Motivations

This PR aims to improve our UX around InputText when a toolbar is supplied.

The Problem

The InputText height grows upon focus to accommodate the toolbar. The problem with this is that it leads to lots of UI jumping around, causing a bad experience.

The Solution
Stop auto-expanding the textarea height and instead slide the toolbar up from the bottom of the input with absolute positioning so it doesn't affect the layout.

While making these adjustments, I also had to solve a number of bugs around scrollbar behaviours. I went through a few different iterations to land on the current solution and there are 2 very small firefox quirks I believe we should live with. These quirks are much more ideal than the alternatives I ran into while building towards this final solution. See this comment and this comment for before/after screen recordings and details.

Before / After

See comments for more screenshots/recordings of safari & firefox.

before.mov

after.mov

Changes

Changed

• InputText no longer auto-expands on focus when a toolbar is supplied
• The resize handle has moved back to the textarea input element
  • note: this was how it worked ~7 months ago

Fixed

• Fixed the safari scrollbar to no longer be offset from the right side and to not block the resize handle
• Fixed a double scrollbar appearing in some browsers
• Prevent showing the toolbar when the input is disabled

Testing

TODO: I'm working on a JO draft PR to fix tests next.

To test this:

• Pull this branch down, open the Toolbar story locally
• Focus the input field, observe the toolbar slides up from the bottom
• Blur the input field, observe the toolbar slides down to hide
• Focus the input, add a bunch of lines of text
  • As you continue typing new lines, they are always visible above the toolbar
• Scroll up and down, observe the text at the bottom should fade behind the gradient above the toolbar
• Click the toolbar buttons, observe their outline ring is not cut off
• Force scrollbars to be visible "Always" in the macOS Settings -> Appearance menu
  • Observe the input behaves as you would expect
• Repeat in other browsers
  • Safari
    • Test the scrollbar, verify the resize handle is not blocked/still functional
  • Firefox
    • Observe the fade/gradient above the toolbar is smaller (see comment)
    • Observe the resize handle is above the toolbar when focused (see comment)

Browserstack

I tested various browsers on windows.

Edge

windows.edge.mov

Firefox

windows.firefox.mov

Chrome

windows.chrome.mov

[cloudflare-workers-and-pages]

Deploying atlantis with    Cloudflare Pages

Latest commit:	ef61c4d
Status:	✅  Deploy successful!
Preview URL:	https://a1284850.atlantis.pages.dev
Branch Preview URL:	https://job-103669-improve-input-too.atlantis.pages.dev

View logs

[github-actions]

Published Pre-release for ef61c4d with versions:

  - @jobber/[email protected]+ef61c4d0

To install the new version(s) for Web run:

npm install @jobber/[email protected]+ef61c4d0

[jdeichert]

Moved this from line 106 to here, to make css lint happy. Note resize was moved back to the actual textarea element (.textarea .input).

See this comment.

[jdeichert]

Removing position:relative 3 lines above is too risky... it's 3 year old code and affects every form field input.

For now, I'm opting to make the safer change, only targeting multiline InputText.

[jdeichert]

All safari overrides have been removed! See this comment.

[jdeichert]

So here's where the implementations differ, due to Firefox's bugs around scroll-padding.

Chromium/Safari

When you add new lines to the bottom of the text input, chromium & safari take the scroll-padding-bottom into account and keep up with the new lines, ensuring they are always visible as you are typing.

chrome.mov

Firefox

In firefox, if you disable this .firefox class override, when you add new lines to the bottom they end up getting hidden behind the toolbar. This is because firefox isn't taking the scroll-padding-bottom into account.

To fix this, I ended up overriding the implementation to do this:

• shrunk the height of the childrenWrapper so there's space for the toolbar and the textarea doesn't scroll behind it, it only scrolls behind the gradient blend
• shrunk the height of the gradient so that MOST of the new line of text is visible, while still providing a decent smooth blending affect

So these are the 2 tradeoffs I think we should live with until firefox fixes this issue:

• a very small amount of the gradient covers the bottom of the new line of text, unless you scroll down further of course
• the right resize handle is ABOVE the toolbar

I think these 2 tradeoffs are much better than the alternative issues we had to work around. Chromium+Safari being great experiences, leaving FF to be slightly worse but still completely functional and accessible.

firefox.mov

[jdeichert]

BTW we had a useIsSafari hook which we don't need anymore, so I deleted it. Note we already had an isSafari function inside this util file ^

[jdeichert]

See comment at the bottom of this file for context!

[jdeichert]

This reverts back to behaviour we had prior to ~7 months ago and fixes a safari scrollbar issue we had been living with.

See this commit for details: d68d4a4

This actually reverts some changes made in an earlier PR: #1856

In that PR, the resize handle was moved to the "textarea" class, but that's multiple levels above the actual textarea input element. This was the cause of the safari scrollbar bug, where the scrollbar overlapped the resize handle, blocking it from being used. However, as far as I can tell, that was done to avoid the firefox bug where the resize handle is sitting slightly above the toolbar... which is now back.

This change allowed me to delete all of the safari-specific css which removed the bad bottom padding which allows the text to scroll/flow seamlessly below the bottom of the element, exactly like chrome.

Given the minefield of browser compatibility issues around scroll-padding, scrollbar behaviour, resize behaviour, etc... I think firefox having the resize handle above the toolbar actually isn't terrible and is the least problematic of the alternatives. One browser-specific quirk is better than two.

👉 Before/After: Safari

Before

Before this change, we had the scrollbar offset from the right edge to avoid overlapping the resize handle, which was blocking it from being used.

safari.before.mov

After

Because I restored the resize handle on the textarea input, Safari correctly handles the scrollbar overlapping it.

safari.after.mov

👉 Before/After: Firefox

Before

Firefox had a double scrollbar due to the old implementation. The good thing was that the resize handle was in a consistent spot, like other browsers.

firefox.before.mov

After

No more double scrollbar! But the resize handle sits above the toolbar now, and I think that's completely fine as a tradeoff.

firefox.after.mov

[jdeichert]

The toolbar height has to be explicitly set to a fixed value to work correctly. For now, it is set to --space-larger and we can easily extend this in the future via a prop to override this variable if we need it to be configurable.

[jdeichert]

when I put a Menu inside the toolbar in the webstory, the border bottom gets thinner than the other sides

@ZakaryH this is because the Menu component appears to have a larger button height (40px) than our normal Buttons (32px)

The toolbar height currently is hardcoded, but as I mentioned above we can make this a prop if necessary, so the consumer can set the height to be larger.

[MichaelParadis]

I noticed this when clicking on content that would be where to toolbar appears (happens on all browsers). Not sure if this is a must fix.

Toolbar.test.mov

CC: @jdeichert @chris-at-jobber

[ZakaryH]

when I put a Menu inside the toolbar in the webstory, the border bottom gets thinner than the other sides

code

toolbar: (
    <div
      style={{
        display: "flex",
        width: "100%",
        justifyContent: "space-between",
      }}
    >
      <Menu
        items={[
          {
            actions: [
              {
                label: "Edit",
                icon: "edit",
                onClick: () => {
                  alert("✏️");
                },
              },
            ],
          },
          {
            header: "Send as...",
            actions: [
              {
                label: "Text message",
                icon: "sms",
                onClick: () => {
                  alert("📱");
                },
              },
              {
                label: "Email",
                icon: "email",
                onClick: () => {
                  alert("📨");
                },
              },
            ],
          },
        ]}
      />
      <Button
        ariaLabel="Undo"
        size="small"
        icon="redo"
        type="tertiary"
        fullWidth={false}
      />
    </div>
  ),

[ZakaryH]

if you don't provide a rows prop which is optional, the toolbar overlaps with the typing area

this is using a Menu as the toolbar content + no rows

[jdeichert]

when I put a Menu inside the toolbar in the webstory, the border bottom gets thinner than the other sides

Interesting find.. I'll look into it.
EDIT: answered here https://github.com/GetJobber/atlantis/pull/2133/files#r1857039078

if you don't provide a rows prop which is optional, the toolbar overlaps with the typing area

Yes, I need to add min-height there likely.

[ZakaryH]

previously when you didn't provide a rows prop for a multiline, it doesn't grow. it'll always stay the same size. here's how it behaves on this branch for a standard mutliline with no rows.

same branch, with a toolbar

vs current master w/toolbar and no rows. it grows to fit the toolbar initially, but typing doesn't change it after that

[ZakaryH]

another small detail, when the toolbarVisibility is set to always there's still some change in the dimensions of the input when you start typing despite it looking like there's plenty of space to fit the new text

happens with both rows and no rows prop

[jdeichert]

previously when you didn't provide a rows prop for a multiline, it doesn't grow. it'll always stay the same size. here's how it behaves on this branch for a standard mutliline with no rows.

@ZakaryH good catch. That's due to me removing this line. When you don't supply rows, the default is min:3/max:3 so we never explicitly set the height in that case.

If I restore this, browsers will auto-expand the textarea to fit the toolbar.

I'm not sure I have a solution to address the issue you found yet.

[ZakaryH]

ah ok, I didn't have a chance to read over the code yet. I just wanted to do a few of the problematic flows I encountered on v1 of this.

yeah I'd be hesitant to remove the resize logic since that applies to normal, non toolbar multiline text inputs too. I can't remember if it's documented or not that we offer the not-growing behavior from omitting rows but I remember seeing a few instances like that in product which may be expecting or relying on that behavior

[jdeichert]

I'd be hesitant to remove the resize logic since that applies to normal, non toolbar multiline text inputs too

Great point here. This definitely could be fixed to not affect inputs without toolbars.

Yeah I think this is another example of the wall I hit here. The problems you're finding make me think we should stop going down this path.

[jdeichert]

another small detail, when the toolbarVisibility is set to always there's still some change in the dimensions of the input when you start typing despite it looking like there's plenty of space to fit the new text

happens with both rows and no rows prop

@ZakaryH that's also related to resizing in general. I don't have a solution yet... this might be my wall for the path I took to get to this solution.

[jdeichert]

We've reached the limits of this UI approach. We have a new ticket (JOB-110270) for a different direction.

[ericchernuka]

@jdeichert Let's also chat. I ran into some issues when attempting to deal with the toolbar ux with magic fields and can provide another perspective on use case!