- Replace the [Monaco Editor](https://microsoft.github.io/monaco-editor/)
with [CodeMirror 6](https://codemirror.net/). This editor is used to
facilitate the 'Add file' and 'Edit file' functionality.
- Rationale:
- Monaco editor is a great and powerful editor, however for Forgejo's
purpose it acts more like a small IDE than a code editor and is doing
too much. In my limited user research the usage of editing files via
the web UI is largely for small changes that does not need the
features that Monaco editor provides.
- Monaco editor has no mobile support, Codemirror is very usable on mobile.
- Monaco editor pulls in large dependencies (for language support) and
by replacing it with Codemirror the amount of time that webpack needs
to build the frontend is reduced by 50% (~30s -> ~15s).
- The binary of Forgejo (build with `bindata` tag) is reduced by 2MiB.
- Codemirror is much more lightweight and should be more usable on
less powerful hardware, most notably the lazy loading is much faster
as codemirror uses less javascript.
- Because Codemirror is modular it is much easier to change the
behavior of the code editor if we wish to.
- Drawbacks:
- Codemirror is quite modular and as seen in `package.json` and in
`codeeditor.ts` we have to supply a lot more of its features to have
feature parity with Monaco editor.
- Monaco editor has great integrated language support (features that
an lsp would provide), Codemirror only has such language support to an
extend.
- Monaco editor has its famous command palette (known by many as its
also available in VSCode), this is not available in code mirror.
- Good to note:
- All features that was added on top of the monaco editor (such as
dynamically changing language support depending on the filename)
still works and the theme is based on the VSCode colors which largely
resembles the monaco editor.
- The code editor is still lazy-loaded (this is painfully clear by
reading how imports are passed around in `codeeditor.ts`).
- This change was privately tested by a few people, a few bugs were
found (and fixed) but no major drawbacks were noted for their usage of
the web editor.
- There's a "search" button in the top bar, so that search can be used
on mobile. It is otherwise only accessible via
<kbd>Ctrl</kbd>+<kbd>f</kbd>.
Co-authored-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10559
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: Beowulf <beowulf@beocode.eu>
Replace the anti-CSRF token with a [cross origin protection by Go](https://go.dev/doc/go1.25#nethttppkgnethttp) that uses a stateless way of verifying if a request was cross origin or not. This allows is to remove al lot of code and replace it with a few lines of code and we no longer have to hand roll this protection. The new protection uses indicators by the browser itself that indicate if the request is cross-origin, thus we no longer have to take care of ensuring the generated CSRF token is passed back to the server any request by the the browser will have send this indicator.
Resolvesforgejo/forgejo#3538
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9830
Reviewed-by: oliverpool <oliverpool@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
- Switched from jQuery class functions to plain JavaScript `classList`
- Tested the repository branch settings functionality and it works as
before
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
(cherry picked from commit 2b3f7d3e966ab60cb147115303d1992e8b50d4df)
This pattern comes of often during review, so let's fix it once and for
all. Did not test, but changes are trivial enough imho.
(cherry picked from commit 8fe26fb314f1710139728d9118b455fc6a16cce2)
- Switched from jQuery `.attr` to plain javascript `getAttribute` and
`setAttribute`
- Tested the collaborator access mode change, team search box, and
branch protection form. They all work as before
---------
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
(cherry picked from commit 26dbca741114587f4191050a76ee1a36282a2018)
To keep blame info accurate and to avoid [changes like
this](https://github.com/go-gitea/gitea/pull/29977/files#diff-c3422631a14edbe1e508c4b22f0c718db318be08a6e889427802f9b6165d88d6R359),
it's good to always have a trailing comma, so let's enforce it in JS.
This rule is completely automatically fixable with `make lint-js-fix`
and that's what I did here.
(cherry picked from commit 3d751b6ec18e57698ce86b79866031d2c80c2071)
Conflicts:
web_src/js/components/DashboardRepoList.vue
trivial context conflict because of '3b7b899afa fix commit_status'
- Removed all jQuery AJAX calls and replaced with our fetch wrapper
- Tested the repo collaborator mode dropdown functionality and it works
as before
# Demo using `fetch` instead of jQuery AJAX
---------
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 15d071f4f81a0ad09f260de83cb6402875b4de27)
Fixes#27114.
* In Gitea 1.12 (#9532), a "dismiss stale approvals" branch protection
setting was introduced, for ignoring stale reviews when verifying the
approval count of a pull request.
* In Gitea 1.14 (#12674), the "dismiss review" feature was added.
* This caused confusion with users (#25858), as "dismiss" now means 2
different things.
* In Gitea 1.20 (#25882), the behavior of the "dismiss stale approvals"
branch protection was modified to actually dismiss the stale review.
For some users this new behavior of dismissing the stale reviews is not
desirable.
So this PR reintroduces the old behavior as a new "ignore stale
approvals" branch protection setting.
---------
Co-authored-by: delvh <dev.lh@web.de>
This PR is to allow users to specify status checks by patterns. Users
can enter patterns in the "Status Check Pattern" `textarea` to match
status checks and each line specifies a pattern. If "Status Check" is
enabled, patterns cannot be empty and user must enter at least one
pattern.
Users will no longer be able to choose status checks from the table. But
a __*`Matched`*__ mark will be added to the matched checks to help users
enter patterns.
Benefits:
- Even if no status checks have been completed, users can specify
necessary status checks in advance.
- More flexible. Users can specify a series of status checks by one
pattern.
Before:
After:
---------
Co-authored-by: silverwind <me@silverwind.io>
* Remove customized (unmaintained) dropdown, improve aria a11y for dropdown
* fix repo permission
* use action instead of onChange
* re-order the CSS selector
* fix dropdown behavior for repo permissions, make elements inside menu item non-focusable
* use menu/menuitem instead of combobox/option. use tooltip(data-content) for aria-label, prevent from repeated attaching
* click menu item when pressing Enter
* code format
* fix repo permission
* repo setting: prevent from misleading users when error occurs
* fine tune the repo collaboration access mode dropdown (in case the access mode is undefined in the template)
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Reusing `/api/v1` from Gitea UI Pages have pros and cons.
Pros:
1) Less code copy
Cons:
1) API/v1 have to support shared session with page requests.
2) You need to consider for each other when you want to change something about api/v1 or page.
This PR moves all dependencies to API/v1 from UI Pages.
Partially replace #16052
In the case of misuse or misunderstanding from a developer whereby,
if `sel` can receive user-controlled data, jQuery `$(sel)` can lead to the
creation of a new element. Current usage is using hard-coded selectors
in the templates, but nobody prevents that from expanding to
user-controlled somehow.
