Regression: Fix U2F modal bug - backport introduced issue into 1.15

[fnetX]

although double check that 1.15 is actually affected.

Originally posted by @zeripath in #18040 (comment)

---

Well ... The backport #18042 seems to have introduced the bug it was about to fix in Gitea 1.15. As far as I can reproduce locally, Gitea 1.15 was not affected before that PR was merged, but starting with the merge (commit 91f5be8), I can reproduce the issue / all modals pop up.

Reverting the backport appears to be fine.

Noticed this a few days ago, but was bumped by a user reporting this on Codeberg after 1.15.8+ was deployed.

[fnetX]

The report is about the application tab, but "Security" (U2F) and "Applications" tab functionality seems to be affected equally.

[lunny]

The report is about the application tab, but "Security" (U2F) and "Applications" tab functionality seems to be affected equally.

Opposite, I can reproduce it before #18042 but cannot after it.

[zeripath]

Looking at release/v1.15:

https://github.com/go-gitea/gitea/blob/6eaebda1b58040376d002b7e593dd6a2fc255030/web_src/js/index.js#L2959-2986

The id of the modal to look for should be on the modal-id attribute which matches the form.

The only place that there is a form with the id delete-registration is in security_u2f.tmpl is only ever loaded once in security.tmpl.

To my eyes that looks right and I can't see how #18042 is incorrect.

[fnetX]

I just checked git.disroot.org which also runs Gitea 1.15.8, and I can reproduce the bug there, too.

I can't say much about the code or the background of this bug, only that I can reproduce on different instances including local development and that it's not only my machine, because we got a user report, too. The issue wasn't present for me before. I doubt I can provide more information, as I'm not that familiar with web frontend stuff. 🤷

[fnetX]

Just to clarify in case this lead to confusion: I'm only talking about the 1.15 branch. I can confirm that the bug is fixed on current main, but the backport seems unnecessary / broken to me.

[zeripath]

If I download a copy of 1.15.8 direct from gitea.io I can't reproduce this bug - my worry is that because the Javascript file changed we're seeing yet another issue with cached javascript resources.

I can't reproduce this bug on codeberg right now on chrome or firefox.

[wxiaoguang]

Is Codeberg behind some CDN? Is there any cache policy?

[fnetX]

Hmm, but why would this allow for local reproducibility by switching back and forth between resources? Or on Disroot Gitea which I only opened to confirm?
No, Codeberg has no special caching policy, and it's not specific to Codeberg anyway.