That seems sensible to me

Thanks, I've uploaded https://github.com/metabrainz/musicbrainz-server/pull/3331 to highlight updated names in the tracklist editor. I don't think that highlighting is needed anywhere else, since the button is only updating a single input that's right next to it (but let me know if you disagree).

Highlighting the entire field after changing is indeed useful for stuff like releases with 60+ tracks where the preview doesn't fit on screen (and it's also not sensible to go track by track). This would mean I can guess case, then review only what has actually changed.

Agreed that derat's (amazing!) fix doesn't solve this ticket (I think I mentioned that on the PR as well), but it's no big deal, we can reopen it.

Yes, guess punctuation highlights the entire field after changes have been done.

Apologies if it would've been better to create a new ticket about displaying previews. (I have to admit that I sometimes try to minimize my interactions with Jira...)

I don't think that there's any non-incredibly-hacky/fragile way to highlight individual changed characters in an <input type="text">. I don't have a userscript manager installed, but from looking at https://github.com/kellnerd/musicbrainz-scripts/blob/main/dist/guessUnicodePunctuation.user.js, I believe that it highlights entire fields after they've been changed – is that right, aerozol?

From my first morning of using previews on the beta server, I'm doubtful that I'd get much additional value from highlighting fields after they've been modified, but I tend to click the per-track "Aa" buttons rather than the "Guess case" buttons for the entire medium or release since there are usually some track titles that would be incorrectly changed by the latter.

If highlighting changed fields (just in the tracklist editor?) still seems useful to someone, I can look into adding that – I think it'd probably just be a matter of making the various case-guessing code add a new CSS class to fields that it changes and then removing that if/when they're manually changed later. I'm a bit worried it could be confusing from a UX perspective if the fields are being highlighted both on hover and after click. I'm not sure if using different highlight colors would make that better or worse.

FWIW, derat’s changes seem great, but they don’t address this ticket. derat’s changes allows you to preview the changes being made, but doesn’t highlight what’s been changed after the changes have been made, so pushing that(/those) PR(s) to production shouldn’t mark this ticket as Closed/Fixed.

The text drag fix from derat (https://github.com/metabrainz/musicbrainz-server/pull/3330) has been deployed to beta.

Thanks for the quick report, chaban. I think that this can be fixed by just not showing the preview if a mouse button is held. I'll upload a change soon to do that.

The hover function interferes with text selection. For example, on the standalone recording creation page the guess case button is right next to the title field. When the input text overflows and I wanted to select a portion of it until the end by drag-select every time the mouse pointer passes the button the selection is canceled.

I think hover might not totally close this specific ticket as Tom Crocker envisaged it , but is an invaluable improvement nonetheless!