Thank you. A problem with the markup or something was my first thought too. But native HTML input sliders wouldn’t work as well. I think this is really related to executeAsModal. It won’t get out of modal state as long the mousebutton is held down. I also tried to “hack” this behaviour by firing a mouseup and mousedown event on every increment of the slider. But even that won’t work.
1 Like
@Karmalakas @kerrishotts i have to correct myself. The error will not be thrown when using the function with standard HTML markup
<input type="range" class="rtSlider" id="testSlider" min="-100" max="100" value="0" step="1">
</input>
But… it still won’t fire in real time but “on change”. What makes it even more weird.
As an explanation why i had this misunderstanding that <sp-slider> and <input type="range"> act the same is, that i didn’t check the console. I only checked behaviour in the Panel/PS app when i changed the element type when i was searching for the culprit.
edit: it will throw the error when using oninput but it will not when using onmousemove. Using sp-slider will always cause throwing the modal state error.
I have no great news news for you at this time.
- I see no mechanism for live updates anymore with
executeAsModal. Unless @heewoo or @samgannaway can add support inexecuteAsModal, there’s nothing you can do. You may have to live with updates occurring only when the mouse button is released.interactive: trueis not a solution here – it’s just there to prevent the Ps progress dialog from showing up (interactive here implies that your plugin may be presenting some other interactive UI) - I see no way to “hack” Ps here – that Ps goes into a modal state when the mouse button is pressed is way outside of the plugin’s (and UXP’s) control, and faking events like mouseup/mousedown do not go through the same event layers that real events do, so you can’t get around it this way.
Therefore:
You should use change events for sliders when you want to invoke batchPlay commands. The change event fires late enough in the handling process that you’re always out of Ps’ modal state. input can sometimes fire while Ps is still in modal state, leading to your batchPlay command not working. (You could have a setTimeout in there, though, and that should work… but more work than just using change)
(As to why going back to ap version 1 & manifest v4 can still cause the issue – I’m guessing that Ps is being more aggressive with modal states from mouse button presses, and it does so without regard to the API version in the plugin manifest… but that’s only a guess – I don’t have a good understanding of the C++ code that Ps uses outside of extensibility.)
1 Like
Thank you for confirming Kerri.
Oof… So it seems that someone really did this on purpose for preventing a laggy UI or something. Although there are pretty ways of implementing real time changes.
I’m still hoping that Adobe wanted to do something good for us and this is just a negative side effect that can be reverted. I mean when i look at competitors developing plugins for C1 or Affinity, my plugin would have this major drawback.
And besides, it will be hard to create plugins that really extend PS’ editing functionality in a productive/intuitive way. At least unless we got something like pixel access in our panels.
It would be great to have some feedback/confirmation on this matter from the PS team. I heard i’m not the only one with this problem and several thousands (!) of customers are really unhappy with this situation…
IMHO this must be reverted ASAP, because it apparently completely broke live interaction, which was working and as I understand quite a few plugins were making use of it
1 Like
@Karmalakas i agree so much i can’t even express it with words. Removing such a feature would mean to bind us to user interaction like back in 1995.
What are you suggesting with rolling back? If you are suggesting that Photoshop just reverts back to API 1 then don’t agree with that. If anything, keep API 1 and API 2 both available and switchable in the manifest, but don’t roll back away from execute as modal.
Execute as modal is needed and fixed a bunch of things. I don’t think just “reverting” PS back to how it was in API 1 is an option. A lot of developers, including myself, are relying on API 2 and execute as modal in their plugins. Most of my plugins are batch automation plugins and don’t use live updates. For my plugins personally, API 2 and execute as modal was a much needed update.
I agree that live updates is a needed capability. However, I don’t believe this can come at a cost of rolling back the things that were added with API 2 and execute as modal.
You should also keep in mind that executeAsModal prevents other plugins to run their commands right in the middle of your own execution. So it prevents to interfere with other plugins and also with user. So there is a reason for its existence. But right now it is enforced to be used for any document change.
Definitely not 
Apparently there was some change in v23.3 that affected both v1 and v2. AT least that’s what I understood from this discussion. So whatever they changed somewhere in Ps core, it affected modal behaviour and live interaction. My suggestion (well, more of a request maybe) would be to revert whatever they did to break UXP. It doesn’t look like this breaking change has anything to do with UXP directly and was a negative side effect
Completely agree and it should stay. I understood live interaction was working fine on API v2 before v23.3
3 Likes
OK, I see. Yes, I agree with that, if it is possible. Maybe the change was to fix a bug in execute as modal and it is a needed change. It is impossible to speculate. So there is no way to know if rolling back is possible.
Yes this is correct. Live changes were working fine with V2. As far as i understand with 23.3.0 UXP 6.0 was introduced. And 6.0 is using the same functionality as the latest V5.x, but broke the live changes for some reason.
1 Like
Ah, so maybe it’s not Ps core, but actually a UXP change. Anyway…
1 Like
Just speculation. Kerri wrote the problem is out of UXP’s scope. Maybe they adapted the core to new UXP 6. Who knows…
So where should i make noise now? Or to whom should i reach out?
The issue is kind of urgent as it costs me money every day and i don’t feel like PS core developers are following this forum on a regular basis.
I already started a post in the prerelease group but i think noone behind the core steering wheel notices.
Even if the issue is out of the UXP scope, I’m hoping that Kerri or someone else from the team can reach out (or mediate the contact) to some PS Core devs - especially since we can pin down the problem to that specific update, so this should really narrow things down when looking for the root of the issue.
Doing steps backwards in terms of functionality / UX would be quite frustrating for plugin developers as well as customers and would probably lead to less trust in the overall plugin ecosystem. What if more currently available features will stop working in future updates due to PS core changes which aren’t aligned with UXP…
I’m still surprised that your customers are that unforgiving though. Couldn’t you just move to onChange listeners for now? Sure, it’s way worse UX, but maybe an immediate refund isn’t necessary if the plugins still work somehow.
I’m wondering if there’s any way to work around this issue…
Since the function we call with executeAsModal is async, couldn’t you do something like:
- start modal context
- return a promise which doesn’t resolve for now
- read/poll some descriptors to execute via batchPlay (you’d have to push them to that “source” on every change/input)
- resolve the promise on mouse-up
Or maybe Photoshop is blocking UI-updates in general when a mouse-down is still active?
1 Like
Hi @Michel77. The next minor Photoshop update 23.4 will have a fix that should resolve this issue. If it still persists, try guarding to ensure that only one execute modal scope is pending at any moment in time - and report back with any improvements or findings then.
Thanks everyone above for chiming in and offering insights / workarounds. Yes, this problem should have begun in 23.3.
4 Likes
QQ – is that available in pre-release yet?
What a relief! Thank you soooo much @heewoo and the rest of the team for your response on this matter.
@simonhenke my customers are in fact forgiving. But i didn’t want to make promises i maybe couldn’t resolve later.
1 Like
No, it did not make the last pre-release build. It will be in the next one being announced on 2022-05-13, though.
1 Like
Maybe it’s a good idea to have something like “best practice” for real time changes in the docs. At best with an example of how to fire only one modal request at PS core for the time of execution. (@kerrishotts ?)
As far as i can see now, the promises are resolved when the batch play is fired and not when it finishes. The only hint from core i’ve seen so far is the modalscope exit event that we could use.
BTW the modalscope enter event will fire after(!) execution together with the enter event.
I was going to say make some noise in the Photoshop prerelease group, but maybe you already did? (The link will only work if you’re in the Photoshop prerelease. If you’re not, email Pete.)
1 Like