Duotone: Duotone filter button should always be at the end

[jasmussen]

The Duotone button should always be at the end. Right now it starts as the first button, then if you deselect the block and select it again, it moves to the end:

This ticket has been updated to focus on just the one remaining item.

[jasmussen]

@ajlende want to pair with me on this one?

[ajlende]

I'll get a branch going for the setup state first. There's a chance that fixing that will fix the reordering issue since the first render will happen when the rest of the toolbar buttons are added. 🤞

[jasmussen]

In case it's related to the order in which it shows up and in the placeholder, I'm noticing a jumpy toolbar when applying the filter:

Alex do you know what this might be caused by?

[walbo]

This enhancement should also be added to the cover block. Doutone should only be visible when you have added a background image. Right now it shows when background color is selected istead of an image and the duotone controls doesn't do anything.

[jasmussen]

@ajlende I updated this ticket to be checklist format. I also have some initial mockups for a longer term filter menu redesign that both revisits the shadow/highlight buttons, and adds the non-destructive text. The mockups need a bit more thought, but consider it a snapshot of work in progress:

[jasmussen]

Created a new separate issue for adding a duotone shortcut to the Gallery block: #34950

[jasmussen]

I've edited the title and description of this issue:

• One issue — a description to note the filter is non destructive is already fixed
• The other issue, that duotone should not be available in the setup state, was recently made intentional for the Featured Image block, so it's clear that a filter will be applied. There are opportunities to expand that for the Image block itself, but I removed it from this one for now to focus this ticket.

The remaining issue: always showing the filter button at the end, is now the focus of this ticket.

[richtabor]

I'm noticing this more and more — @ajlende is this a big lift?

[richtabor]

The other issue, that duotone should not be available in the setup state, was recently made intentional for the Featured Image block, so it's clear that a filter will be applied.

I made a separate issue (reference the Cover block) for this here: #48804

[ajlende]

I'm noticing this more and more — @ajlende is this a big lift?

It isn't so much a duotone problem as a problem with the slot/fill system that can't guarantee rendering order. My suspicion is that, for the first render, the duotone code is being run first which places it at the beginning of the slot, and then on subsequent renders it falls later for some reason.

Removing duotone from the setup state for the cover block was a potential way to sidestep the issue by never calling that first render because fixing the root of the issue seemed much more difficult.

[richtabor]

Removing duotone from the setup state for the cover block was a potential way to sidestep the issue by never calling that first render because fixing the root of the issue seemed much more difficult.

Gotcha. I don't think that would clear it though — on trunk at least it's consistently first.

[Mamaduka]

This is a general problem with SlotFills and will be fixed once we have a solution for #15641.

[richtabor]

This is a general problem with SlotFills and will be fixed once we have a solution for #15641.

Would this result affect block controls as well? How do you suggest we move forward?

If anything, if we can at least keep the "Align" icon control, that would be acceptable. That's the inconsistency with all other blocks that support alignment.

Is there a temporary fix we could put in to do that you think? cc @ajlende

[Mamaduka]

The general fix will benefit both since block/inspector controls are rendered using SlotFills.

There're some "hacky" workarounds for the bug, but I don't think we can apply it here.

I think the Duotone control position is more consistent on the current trunk than when the issue was initially reported. We can close this duplicate of #15641.

[richtabor]

I think the Duotone control position is more consistent on the current trunk

Yes, but it's consistently where the Align control should be, which is consistently first in blocks that don't support duotone.

[richtabor]

I think it's fine to keep this separate/open perhaps, as it's more specific.

[ajlende]

Is there a temporary fix we could put in to do that you think?

@Mamaduka is right, the hacks he's mentioning are for fixing asynchronous rendering by creating a placeholder element in the DOM that can get swapped when the async part resolves.

The only hack I can think of is to purposely delay duotone rendering by a fixed amount so it pops in half a second after opening the toolbar or something, but that sounds worse than what we have to me. Furthermore, if you try to do that for a second toolbar item, the problem will pop up again.

[Mamaduka]

I think it's fine to keep this separate/open perhaps, as it's more specific.

Sure. But the details here aren't related to the actual problem, just symptoms of it.

[Mamaduka]

I can no longer reproduce the issue on Gutenberg trunk; the Duotone filter is always the first item in the toolbar.

It's still an issue on WP 6.2.2.

[richtabor]

the Duotone filter is always the first item in the toolbar.

It needs to be the last one though, or at least after alignment.

[Mamaduka]

I mean first from the left 😅

[richtabor]

Yea, it's consistently the first from the left, but it should be anywhere else ha — at the end would be best I think.

[Mamaduka]

The issue is back if I move it at the end by rendering the block edit component first and then Duotone controls.