MediaWiki talk:Gadget-site-tpl-copy.js

preventDefault?

@Krinkle: I think this might need event.preventDefault() for the click, because at the moment if 'Copy' is clicked in Realtime Preview then then whole editing form is submitted (because this is a button within the form, in that context). Perhaps this is something that RTP should handle more generally though. Sam Wilson 05:30, 27 January 2024 (UTC)

Thanks for raising this!

I'd prefer not to add awareness or integration with unrelated features. The need for this implies to me that we either have a breach of contract on the RTP side as you say (does it embed content in an incompatible way, by forcing non-standard expectations?), or that we have a portability issue on the side of the Copy gadget (does it fail to comply with a reasonable standard?).

In this case, I'd say it's the latter, but not due to lacking a preventDefault handler, but rather due to having a submit button outside a form in the first place. The mistake I made is using a submit button. This is an easy mistake to make given that HTML <button> unfortunately defaults to type=submit. Setting type=button removes the form-seeking behaviour and makes it a portable standalone no-op button. This solution is also usable when JS isn't involved (e.g. a server-rendered button in the content area outside a form), where adding a preventDefault handler would be much harder.

Fixed in edit. Krinkle (talk) 11:03, 6 February 2024 (UTC)

@Krinkle: Thanks, that's a better fix. And I agree that RTP is not doing the wrong thing by displaying the preview within the edit <form>. InputBox for example adds a form submit button, but it does it within its own form and so works as expected (although I guess one could argue that no forms within previews should work, but then the same should be said of other things in them that navigate away from the current page, and that quickly doesn't make sense). Sam Wilson 03:46, 7 February 2024 (UTC)