Clone URL no longer displayed without javascript

[u3shit]

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:

And the same in elinks:

A screenshot from my instance which is still running 1.16.9, also without javascript:

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

[wxiaoguang]

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

[u3shit]

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

[eeyrjmr]

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

[u3shit]

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.

[eeyrjmr]

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.

[u3shit]

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

[wxiaoguang]

That's a long story about the refactoring of the clone link/buttons (#19028 and #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.

• Remove Pull Request button on repo homepage #20375 (comment)
• Clean up and fix clone button script #20415 (comment)

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

[silverwind]

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.