I’ve seen an issue with the spacebar and enter key triggering buttons in UXP plugins. I’m not using any key events and they shouldn’t be triggering buttons. For sp button, it will trigger the last button used. For native HTML buttons, it will trigger the button in the case where you started to click the button before but then changed your mind and pulled the mouse away.
The space bar seems to trigger on key up. The enter key seems to trigger on key down. I have seen this in multiple plugins and I don’t believe there is anything wrong with the plugin coding to cause this.
So based on that first link, it seems this is intended button behavior for the space or enter with an sp action button? However, it does do the same thing with a normal sp button too.
Do you know if there is a way to just tell it to not link the keyboard to the button at all? I don’t want the buttons to be triggered by anything except the user clicking on them.
To this day, unfortunately, I haven’t found a way to break that link programmatically. You can break that link and give back KB focus to PS by for ex double-click on a Layer Opacity value and hit Enter… or anything that gives the KB focus back to the user. It’s really annoying.
Literally the first thing I did in my first plugin was to move to a div with class ‘button’ instead (and style it accordingly).
This behavior was super annoying and distracting and If I already notice it during development, I don’t want users to deal with it
OK, thanks. I may have to go to native HTML button until the sp buttons are fixed. Although native buttons are being deprecated eventually.
The native buttons do still have the issue when the user starts to click and changes their mind as I show in the end of the video. However, that is not the usual case so much better than how it is with the sp button.
Right now I have users who try to use the space bar for the hand tool just to have it click a button and perform a task they don’t want it to.
to replace sp-buttons. SP buttons are limited (that’s OK) for some styling, div are fine
However, I think you have to use tabindex=“1” on that div (no matter the number as long as something is there). On Mac, I still have the KB focus issue. I’m using Vanilla JS. No React. @simonhenke have you got that div working on a Mac too?
The reason I am using sp buttons is because of the native buttons being deprecated in the future. But I may just have to switch to native buttons and deal with updating all 10 of my plugins when the times comes for that.
I don’t use tabindex on the Button-Div… Does the click event not fire without it on Mac? Can’t test it since I only have windows system, but I’d assume that people who use my plugins would have told me about such a critical bug - or they just all use windows, too
I’m hoping that Adobe builds in a way to opt-out of the space or enter key behavior. Even when the bugs are fixed and focus shifts back and forth properly, I still don’t want the buttons to be linked to the keys, even when the focus is on the plugin.
I can see in certain cases where it could be beneficial. However, for the case where there are 20 buttons in the plugin, I just don’t see it being beneficial. It is more confusing than anything.
At least I think there needs to be an option to use this button behavior or not.
Oh, yes the event is fired no problem.
Here’s the thing:
The div-button trick works in the case of Space Bar and Enter keys. That is, if you use a div element instead of a button or sp-button, Space Bar and Enter keys are not tied to the button anymore. That’s the workaround and it works fine. At least for these two keys.
Now if you have to hit the delete key, after clicking any button on a UXP panel, either way, button or div-button, it’s not going to work. The panel still seems to “steal” keyboard focus albeit releasing focus for Space Bar and Enter keys. For other keys… nope.
I’ve made these observations on Mac and Win. I tried few React panels and observed the same behavior. @simonhenke could you possibly check that from your end? Cheers
Yes, I’ve also noticed this behavior before. But as you’ve already mentioned it’s a general bug related to the focus switch between plugins and the Photoshop interface.
So I guess using a Div-Button is still the best option right now, as it doesn’t have the enter / space bug.
LOL… I’m not a web designer and was not even aware you could make a button from a div tag. I’m sure it is easy enough. I will just google it.
However, I wonder if that will be deprecated in the future Photoshop? Div tags themselves are not being deprecated but the native buttons eventually are being deprecated. That is why I used sp buttons in the fist place. I don’t to have to go back and updated all of the plugins later if I can avoid it. I’m trying to build them to work in the future and not break down the road as elements are deprecated.
I’m not sure why listening to a click on a div would get deprecated. However, styling a div and dress it up like a button is much more “flexible” than with button or sp-button. You’d see that quite quickly especially with width and css border props.
If you feel in need to gain the focus of Space Bar and Enter key, and want more styling flexibility, then div-button is a good option
I don’t need or want focus from the space bar or enter key. So it sounds like the div button is a good option.
Regarding CSS, how are you handling the different UI interface color theme options? I started playing with CSS styling before but didn’t know how to switch it with the UI color theme. Is there a class that is automatically attached to the UI theme?
Just FYI on items being deprecated…
I asked at the developer roundtable event about HTML elements being deprecated. Kerri Shots said that only HTML elements that are for layout such as DIV tags are are being kept. Anything dynamic such as buttons and dropdowns are all being deprecated in the future.
Where did you find out about using @media for the themes? Is there another website section this is shown on?
I had been to that page that you posted in the past but I gave up because I couldn’t figure out how to add custom css to each themes. That page only lists the “built-in” styling. It doesn’t mention anything about @media. It sounds like that is the answer I needed.
(and style it accordingly).
