@Volker_E: Sure, where do you want me to check this?

Checked the new changes, on desktop VE, on mobile site with desktop browser and on iPhone5s.
Everything looks good, the touch precision to move and resize a map even on a tiny device as iPhone5s is perfect!

In T206534#4751923, @matmarex wrote:

After this new patch is merged, undoing the changes to an image caption or alt text, or to the gallery caption, or to the order of images, or removing a previously added image, will now disable the "Apply" button again.

The following cases will *not* disable the button again, and it is not feasible to implement them:

• Re-adding a previously removed image with identical options
• Changing any caption to the old value by other means than "Undo"
• Changing image caption or alt text to the old value after switching to a different image and then back

Checked all the design changes. Looks good to me. However, found the following two small issues while doing some exploratory testing on this today.
T210559 and T210555
But this task can be closed.

This is actually a regression from wmf.4, since I can replicate it on en.wiki by following the exact same steps.

@matmarex: Actually, remember this one from last week: T209542. Basically it's the same issue, except it's now happening on Chrome as well.

@greg: Yeah you are right, this was spotted, fixed and verified before wmf.4 roll-out, but no one marked it as resolved from our Product owner review column. I will go ahead and close it. Thanks for bringing this to our attention! :)

I was able to replicate it this morning, but not anymore. I think this was related to T209451. So maybe it's now fixed.

Sure! Also, I just found out that this is happening on Firefox only.

In T206534#4750696, @Tchanders wrote:

In T206534#4745136, @Ryasmeen wrote:

2. Sometimes I am seeing the "Apply changes" button staying enabled even if there hasn't been any changes (Haven't found the exact steps yet for this, trying to).

@Ryasmeen I can help you here! I think you should find that everything in the Options tab[1] behaves as you would expect, whereas in the Images tab, once a change has made the action stays enabled, even if you undo. This is essentially because the Options tab[1] relates to attributes on the gallery node itself, whereas the Images tab relates to descendant nodes (the gallery caption is also a descendant of the gallery).

It's not ideal, but I think it's better than what went before... I guess the task should arguably remain open until fixed properly, but having to check changes to the gallery's descendant nodes is a bit more complicated.

[1] except for the gallery caption

@matmarex: Did you try on Firefox? This is specific to Firefox browser.

@Tchanders: I see, yeah I rechecked for the extension dialogs and all of them have "Apply changes" button except the one for Graph. It's still showing "Done" for me.

In T208720#4746932, @matmarex wrote:

What template is this?

Looks like https://en.wikipedia.org/wiki/Template:Infobox_film

Checked on Beta cluster since the replication step requires saving the edit. Looks fixed on Beta cluster.

Fixed, thanks!

@matmarex: another regression: T209542, possibly related with this?

Changing the test priority for this one, a change that has already caused a regression needs thorough testing imho.

Ok, there are at-least two workflows that are broken now :(

@matmarex: Assuming this is not on Beta cluster yet? Since, I see the "Apply changes" button being enabled, if I just open the dialog for an existing gallery.

@Esanders: On Beta cluster, pasting "Vision : Wikipedia and the future of free culture" into Automatic tab isn't showing multiple results anymore for some reason.

@JTannerWMF/@matmarex I need clearer QA steps to understand what to test here.