Size Change: +5.38 kB (0%)

Total Size: 1.39 MB

_{compressed-size-action}

Testing

Behaviors

• Drag-to-adjust functions correctly
• Up and down arrow keys increment and decrement correctly
• Spinner arrows increment and decrement correctly
• Manual number adjustment with the keyboard functions correctly

• Firefox
• Edge
• Chrome
• Safari

Note:
As mentioned by @stokesman, the behavior in Safari remains broken. The issue, however, appears to be distinct from the problem we're solving here.

Thanks for testing @jeyip!

I just realized that my version of Safari is 12.1.2 and https://caniuse.com/mdn-api_globaleventhandlers_onpointerdown says the pointer events aren't supported there. The newer version of react-use-gesture is all pointer events so apparently only supports Safari 13 and up. I don't know if Gutenberg has any policy for Safari support.

I just realized that my version of Safari is 12.1.2 and https://caniuse.com/mdn-api_globaleventhandlers_onpointerdown says the pointer events aren't supported there. The newer version of react-use-gesture is all pointer events so apparently only supports Safari 13 and up. I don't know if Gutenberg has any policy for Safari support.

That's a great question. According to this doc, we support the last two versions

According to this doc, we support the last two versions

I managed to test this in Safari 13.1 by way of Browserstack and gutenberg.run 😎 . The dragging feature worked there. Looks like the latest version is 14, so if my math is correct we can not sweat the lack of Safari 12 support (not that the lack of this feature actually busted anything).

Would it be possible to add unit tests for this?

Good question. I think it might not be since it's pretty specific to Firefox. The relief should be, I think, that before too long all InputControl based components will be phased out by something from g2 which will not be subject to this little quirk.

I think it might not be since it's pretty specific to Firefox.

What if we didn't make the test firefox specific, simulated a mousedown event on the input field, spied on the event.target.focus() method, and ensured that focus was invoked?

With that being said, I think you bring up a good point with the introduction of G2 components. I think there's value in the unit test preventing this bug from being reintroduced, but, depending on the time horizon, I'm comfortable skipping it, especially if these components will be phased out.

Thanks for the nudge @jeyip. I'd totally thought a test like that would never fail but it does indeed without the change in this PR. For minutiae, I couldn't see a way to spy on event.target.focus. I did find it worked to assert event.target === activeElement but that felt unnecessarily explicit when the simper test I've pushed here does the trick.

Everything looks good to me! Feel free to merge when ready @stokesman 🚀

Thanks again for the help with this 🙏