Page MenuHomePhabricator

OOUI HTMLFormFieldCloner focusses on the incorrect field when that field has been added by JS
Open, Needs TriagePublic


A kind-of-but-not-entirely-regression from T171666: Implement HTMLFormFieldCloner in OOUIHTMLForm:

Known issue with the patch:

There is also one problem with the functionality: all of the fields added in JS are generated with identical "id" attributes, so clicking their labels will focus the first one, rather than the correct one. This is a bit hard to explain, so here's a video:

(I used this code for testing, based on the one you gave me:

I'm not sure how to fix this. You might be able to do it with some clever replacing in cloner.js (like with the 'uniqueId'), but that seems very unreliable.

The proper way to do this would be to not use HTML "templates" for OOUI widgets, but instead construct new widgets from the config options. But at a glance, that would require a lot of refactoring in HTMLFormField (there's no way to get the config options out of it). :/

In my opinion this is not a severe enough problem to block the patch from being merged (although it may be severe enough to discourage you from using HTMLFormFieldCloner in your OOUIHTMLForm).

Event Timeline

Is this issue still a problem? I haven't found any relevant-looking code changes since it was filed, but I also can't reproduce it - as far as I have found, new fields added by JS have unique IDs and are focusing correctly when clicking on labels.

I can still reproduce this issue, each .mw-htmlform-cloner-row added by the script contains a div with the same id as the template, and the second rendered field (after clicking on Add more twice).