Clone URL no longer displayed without javascript #9290

Closed
opened 2025-11-02 08:34:12 -06:00 by GiteaMirror · 8 comments
Owner

Originally created by @u3shit on GitHub (Jul 30, 2022).

Description

The clone url display was changed in 1.17.0, and it no longer works without javascript, in only displays an empty field. In 1.16.x and below at least it displayed the default protocol (it was still impossible to switch between HTTPS and SSH though).

Screenshots

A random project on try.gitea.org, in chromium:
a
And the same in elinks:
b

A screenshot from my instance which is still running 1.16.9, also without javascript:
c
The copy button doesn't work, but at least it's possible to select the url from the text field manually.

Gitea Version

1.17.0

Can you reproduce the bug on the Gitea demo site?

Yes

Operating System

Linux

Browser Version

ungoogled-chromium 103.0.5060.134

Originally created by @u3shit on GitHub (Jul 30, 2022). ### Description The clone url display was changed in 1.17.0, and it no longer works without javascript, in only displays an empty field. In 1.16.x and below at least it displayed the default protocol (it was still impossible to switch between HTTPS and SSH though). ### Screenshots A random project on try.gitea.org, in chromium: ![a](https://user-images.githubusercontent.com/17014489/181994462-00c23def-b90a-4d8b-b7b8-fd4f59ec4d31.png) And the same in elinks: ![b](https://user-images.githubusercontent.com/17014489/181994466-dfb2eee0-53da-43df-ae82-3c96a28622cd.png) A screenshot from my instance which is still running 1.16.9, also without javascript: ![c](https://user-images.githubusercontent.com/17014489/181994520-cf8d58fc-6bf8-46cc-836d-08a750a14cbd.png) The copy button doesn't work, but at least it's possible to select the url from the text field manually. ### Gitea Version 1.17.0 ### Can you reproduce the bug on the Gitea demo site? Yes ### Operating System Linux ### Browser Version ungoogled-chromium 103.0.5060.134
GiteaMirror added the topic/uitype/bug labels 2025-11-02 08:34:12 -06:00
Author
Owner

@wxiaoguang commented on GitHub (Jul 31, 2022):

More and more Gitea UI elements require JS now. Without JS, you can not merge, can not switch branches, can not comment, can not edit, can not update your settings, etc.

I can not imagine a reason why the JS must be disabled in modern days when users want rich features on the UI (instead of just seeing static contents)

If the disabling JS is necessary, then it's a totally new topic: how to make Gitea work without JS (I do not think it is the future).

@wxiaoguang commented on GitHub (Jul 31, 2022): More and more Gitea UI elements require JS now. Without JS, you can not merge, can not switch branches, can not comment, can not edit, can not update your settings, etc. I can not imagine a reason why the JS must be disabled in modern days when users want rich features on the UI (instead of just seeing static contents) If the disabling JS is necessary, then it's a totally new topic: how to make Gitea work without JS (I do not think it is the future).
Author
Owner

@u3shit commented on GitHub (Jul 31, 2022):

I mean, it worked in a previous version, and all that would be needed to fix is to give repo-clone-url some initial value (like it was before 1.17). I don't care about fancy useless featuress, like reactions, but basic read-only operations should work. Otherwise I recommend changing the This website works better with JavaScript. message to something like This website doesn't work without JavaScript, welcome to the modern internet.

I can not imagine a reason why the JS must be disabled in modern days

Not everyone wants to run a botnet or a browser fuzzer when he visits a random webpage, want to greatly expand the fingerprinting capabilities of the sites, or wants to halve their remaining battery capacity because some broken JS code use 100% of their CPU. There are also cases when you have to repair some broken server and all you have is elinks/w3m to download/find some info. And 90%+ of webpages could function perfectly fine without any kind of JS code (no, google analytics is not an essential functionality for site visitors.)

@u3shit commented on GitHub (Jul 31, 2022): I mean, it worked in a previous version, and all that would be needed to fix is to give `repo-clone-url` some initial value (like it was before 1.17). I don't care about fancy useless featuress, like reactions, but basic read-only operations should work. Otherwise I recommend changing the `This website works better with JavaScript.` message to something like `This website doesn't work without JavaScript, welcome to the modern internet.` >I can not imagine a reason why the JS must be disabled in modern days Not everyone wants to run a botnet or a browser fuzzer when he visits a random webpage, want to greatly expand the fingerprinting capabilities of the sites, or wants to halve their remaining battery capacity because some broken JS code use 100% of their CPU. There are also cases when you have to repair some broken server and all you have is elinks/w3m to download/find some info. And 90%+ of webpages could function perfectly fine without any kind of JS code (no, google analytics is not an essential functionality for site visitors.)
Author
Owner

@eeyrjmr commented on GitHub (Jul 31, 2022):

Have you cleaned cache since upgrading?

I can disable js and still see the download url on my home instance but yes try.gitea.io does not show the url

2022-07-31_17-07-1659283480

@eeyrjmr commented on GitHub (Jul 31, 2022): Have you cleaned cache since upgrading? I can disable js and still see the download url on my home instance but yes try.gitea.io does not show the url ![2022-07-31_17-07-1659283480](https://user-images.githubusercontent.com/4564448/182035153-e9d40766-4b67-4536-88ed-99e83d3025e0.jpg)
Author
Owner

@u3shit commented on GitHub (Jul 31, 2022):

I've tried it in incognito, that should get rid of any caches.
But are you sure you disabled javascript? You should see a This website works better with JavaScript. bar at the top of the page.

@u3shit commented on GitHub (Jul 31, 2022): I've tried it in incognito, that should get rid of any caches. But are you sure you disabled javascript? You should see a `This website works better with JavaScript.` bar at the top of the page.
Author
Owner

@eeyrjmr commented on GitHub (Jul 31, 2022):

Correction, I had blocked js but I had "disable for this url"

Basically the <input id="repo-clone-url" ... has been replaced by a small bit of inline js. I guess to offload some of the page rendering.

@eeyrjmr commented on GitHub (Jul 31, 2022): Correction, I had blocked js but I had "disable for this url" Basically the <input id="repo-clone-url" ... has been replaced by a small bit of inline js. I guess to offload some of the page rendering.
Author
Owner

@u3shit commented on GitHub (Jul 31, 2022):

I don't really think it has anything to do with offloading rendering, if you look at the template: https://github.com/go-gitea/gitea/blob/main/templates/repo/clone_buttons.tmpl it already adds the url to the HTTPS/SSH buttons as a data-link property, it would just have to give some initial value to the repo-clone-url's value property (in fact, I set it to {{$.CloneButtonOriginLink.HTTPS}} and it works, but a real solution would need to check HTTPS/SSH availability and choose accordingly).

@u3shit commented on GitHub (Jul 31, 2022): I don't really think it has anything to do with offloading rendering, if you look at the template: https://github.com/go-gitea/gitea/blob/main/templates/repo/clone_buttons.tmpl it already adds the url to the HTTPS/SSH buttons as a `data-link` property, it would just have to give some initial value to the `repo-clone-url`'s `value` property (in fact, I set it to `{{$.CloneButtonOriginLink.HTTPS}}` and it works, but a real solution would need to check HTTPS/SSH availability and choose accordingly).
Author
Owner

@wxiaoguang commented on GitHub (Aug 1, 2022):

That's a long story about the refactoring of the clone link/buttons (https://github.com/go-gitea/gitea/pull/19028 and https://github.com/go-gitea/gitea/pull/19208)

In short, I do not think it's worth to "fix" it for no-JS, because eventually the clone link/buttons will be moved into a popup, just like GitHub.

I think use the "This website doesn't work without JavaScript, welcome to the modern internet." prompt is better.

@wxiaoguang commented on GitHub (Aug 1, 2022): That's a long story about the refactoring of the clone link/buttons (https://github.com/go-gitea/gitea/pull/19028 and https://github.com/go-gitea/gitea/pull/19208) In short, I do not think it's worth to "fix" it for no-JS, because eventually the clone link/buttons will be moved into a popup, just like GitHub. * https://github.com/go-gitea/gitea/pull/20375#issuecomment-1195988136 * https://github.com/go-gitea/gitea/pull/20415#issuecomment-1189735703 I think use the "This website doesn't work without JavaScript, welcome to the modern internet." prompt is better.
Author
Owner

@silverwind commented on GitHub (Aug 1, 2022):

We can probably render a default value into DOM. Long-term, I would like this logic to move out of localStorage and into backend-backed userSettings that can render the user's preference directly without JS involved, but switching the protocol will still need JS of course.

@silverwind commented on GitHub (Aug 1, 2022): We can probably render a default value into DOM. Long-term, I would like this logic to move out of `localStorage` and into backend-backed `userSettings` that can render the user's preference directly without JS involved, but switching the protocol will still need JS of course.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#9290