My recent plugin submission got rejected because the UI has some overlapping elements as shown by the reviewer:
He is using MAC OS 10.14, so I guess there’s an issue with flexbox in UXP?
For me and 2 other clients who tried out the product, everything looks perfectly fine (I assume they’re on windows, too). For reference, this is how it’s supposed to look:
The layout really isn’t too complicated, here’s the general structure:
<div class="panel">
<header></header>
<main></main>
<footer></footer>
</div>
with the following CSS:
.panel {
display: flex;
flex-direction: column;
}
main {
overflow-y: scroll;
flex-grow: 1;
}
header, footer {
flex-shrink: 0;
}
As you can see, it’s quite a standard setup with header, main & footer, while the main content in the middle expands via flex-grow:1
.
The panel kinda depends on that layout and I can neither influence or change that behavior nor test it, since I don’t have a Mac.
Any ideas or recommendations for what I could do to get my plugin through the submission process?
It’s frustrating to get rejected when it’s not even my fault
Are those "4"s attached to other fields below the “Type” field? If so, I think you’re getting bit by a Ps bug where sometimes items that are in a scrollable area will still appear. It’s usually pretty sporadic though, so if it’s consistent, something else may be going on.
What’s the plugin ID? We can take a look at the build and see what’s going on.
@kerrishotts thanks for the quick reply. I’m not fully sure what you mean by “attached to other fields”, but if you mean that it’s conditionally rendered content, then yes. If in the “type” dropdown something other than “none” is selected, the respective fields will be rendered.
The plugin ID is d209554c.
I submitted a “fix” (can’t really know if it does fix it since I can’t test it) with the following approach:
I’ve added a max-height of 100vh-headerHeight-footerHeight to always give the main container the correct size. But if the height wasn’t the problem and the bug simply ignores the overflow by showing the elements this won’t fix it I guess.
Was hoping I could download the plugin internally, but it’s not working. Could you DM me the ccx that you submitted?
Apologies for slow response here, but I do have a workaround that should work for you.
Essentially, whenever you expand one of the items, you’ll want to do this to force UXP to update the scroll position, which forces UXP to hide any elements that might have been accidentally revealed. In my (quick) tests, I didn’t see any visual jumpiness.
function hideExposedElements(inContainer) {
setTimeout( () => {
const currentScrollPosition = inContainer.scrollTop;
inContainer.scrollTop = (currentScrollPosition === 0) ? 1 : 0;
setTimeout( () => inContainer.scrollTop = currentScrollPosition, 1);
}, 1);
}
Then in your event handler:
function toggleVisibility(evt) {
/* toggle the visibility of your elements...
... then: */
hideExposedElements(evt.target.parentElement);
}
Thanks @kerrishotts. The plugin got accepted in the meantime (so maybe my fix with the static height worked), but if this issue occurs again or any users report it, I’ll make sure to try out that workaround.
Interesting though that it only happens on Mac