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

Closed
opened 2025-11-02 08:00:57 -06:00 by GiteaMirror · 15 comments
Owner

Originally created by @fnetX on GitHub (Dec 24, 2021).

although double check that 1.15 is actually affected.

Originally posted by @zeripath in https://github.com/go-gitea/gitea/issues/18040#issuecomment-997990906


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 91f5be889a), 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.

Originally created by @fnetX on GitHub (Dec 24, 2021). > although double check that 1.15 is actually affected. _Originally posted by @zeripath in https://github.com/go-gitea/gitea/issues/18040#issuecomment-997990906_ --- 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 91f5be889af4081b05d63aadecb1373689e1f57c), 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](https://codeberg.org/Codeberg/gitea/issues/30) after 1.15.8+ was deployed.
GiteaMirror added the type/bug label 2025-11-02 08:00:57 -06:00
Author
Owner

@fnetX commented on GitHub (Dec 24, 2021):

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

@fnetX commented on GitHub (Dec 24, 2021): The report is about the application tab, but "Security" (U2F) and "Applications" tab functionality seems to be affected equally.
Author
Owner

@lunny commented on GitHub (Dec 25, 2021):

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.

@lunny commented on GitHub (Dec 25, 2021): > 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.
Author
Owner

@zeripath commented on GitHub (Dec 25, 2021):

Looking at release/v1.15:

6eaebda1b5/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.

@zeripath commented on GitHub (Dec 25, 2021): 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.
Author
Owner

@fnetX commented on GitHub (Dec 25, 2021):

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. 🤷

grafik

@fnetX commented on GitHub (Dec 25, 2021): 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. :shrug: ![grafik](https://user-images.githubusercontent.com/19634137/147387253-67d3a899-6cb2-49c6-9782-360014e138c6.png)
Author
Owner

@fnetX commented on GitHub (Dec 25, 2021):

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.

@fnetX commented on GitHub (Dec 25, 2021): 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.
Author
Owner

@zeripath commented on GitHub (Dec 26, 2021):

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.

@zeripath commented on GitHub (Dec 26, 2021): 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.
Author
Owner

@wxiaoguang commented on GitHub (Dec 26, 2021):

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

@wxiaoguang commented on GitHub (Dec 26, 2021): Is Codeberg behind some CDN? Is there any cache policy?
Author
Owner

@fnetX commented on GitHub (Dec 26, 2021):

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.

@fnetX commented on GitHub (Dec 26, 2021): 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.
Author
Owner

@fnetX commented on GitHub (Dec 26, 2021):

I can reproduce on all mentioned instances (Codeberg, Disroot, local) with both recent Firefox 95.0.2 and Chromium 90.0.4430.212.

@fnetX commented on GitHub (Dec 26, 2021): I can reproduce on all mentioned instances (Codeberg, Disroot, local) with both recent Firefox 95.0.2 and Chromium 90.0.4430.212.
Author
Owner

@fnetX commented on GitHub (Dec 26, 2021):

Is there any further info I can try to provide?

@fnetX commented on GitHub (Dec 26, 2021): Is there any further info I can try to provide?
Author
Owner

@zeripath commented on GitHub (Dec 26, 2021):

Maybe press CTRL-F5 to forcibly reload js resources. Or check in your console what the function looks like.

If I go to codeberg and look index.js (prettified) for delete-button I see:

                $(".delete-button").on("click", Tu),

which maps to

            function Tu() {
                const e = $(this);
                let t = "";
                e.attr("modal-id") && (t += `#${e.attr("modal-id")}`);
                const i = $(`.delete.modal${t}`);
                return i.find(".name").text(e.data("name")),
...

Whereas on 1.15.7 I see:

            function Tu() {
                const e = $(this);
                let t = "";
                e.attr("id") && (t += `#${e.attr("id")}`);
                const i = $(`.delete.modal${t}`);
                return i.find(".name").text(e.data("name")),
...

My suspicion is that the JS you're seeing is still the 1.15.7 version and that's the cause of the problem.

@zeripath commented on GitHub (Dec 26, 2021): Maybe press CTRL-F5 to forcibly reload js resources. Or check in your console what the function looks like. If I go to codeberg and look index.js (prettified) for delete-button I see: ```js $(".delete-button").on("click", Tu), ``` which maps to ```js function Tu() { const e = $(this); let t = ""; e.attr("modal-id") && (t += `#${e.attr("modal-id")}`); const i = $(`.delete.modal${t}`); return i.find(".name").text(e.data("name")), ... ``` Whereas on 1.15.7 I see: ```js function Tu() { const e = $(this); let t = ""; e.attr("id") && (t += `#${e.attr("id")}`); const i = $(`.delete.modal${t}`); return i.find(".name").text(e.data("name")), ... ``` My suspicion is that the JS you're seeing is still the 1.15.7 version and that's the cause of the problem.
Author
Owner

@lunny commented on GitHub (Dec 26, 2021):

Not the u2f UI, but others: emails, tokens, and etc. in user setting. @zeripath

@lunny commented on GitHub (Dec 26, 2021): Not the u2f UI, but others: emails, tokens, and etc. in user setting. @zeripath
Author
Owner

@zeripath commented on GitHub (Dec 26, 2021):

Ah. I see. We should revert then!

@zeripath commented on GitHub (Dec 26, 2021): Ah. I see. We should revert then!
Author
Owner

@zeripath commented on GitHub (Dec 26, 2021):

Revert PR approved @lunny

@zeripath commented on GitHub (Dec 26, 2021): Revert PR approved @lunny
Author
Owner

@zeripath commented on GitHub (Dec 28, 2021):

Fixed by #18107

@zeripath commented on GitHub (Dec 28, 2021): Fixed by #18107
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#8285