search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
44.65k stars 5.45k forks source link

Clone URL no longer displayed without javascript #20558

Closed u3shit closed 2 years ago

u3shit commented 2 years ago

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

wxiaoguang commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

u3shit commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.

silverwind commented 2 years ago

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.