Fairly new to Forgejo but I just ran into this when trying to create a couple repositories.
I noticed that the input field for the repository name in several areas of the UI is prone to have annoying auto-capitalization, spellchecking and other browser features which try to correct the user input.
I as a user would like to not have the browser interfere with my input especially in dialogs where I want to have something "custom".
For fields where the repo name is used to validate an action (Danger Zone) this is even more frustrating.
So, to me, this is a quality of live improvement fix.
I checked the docs for these three attributes and none of them seem to have a negative side effect for the user:
1. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/autocorrect
2. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/autocapitalize
3. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/spellcheck
## List of URLs where this applies:
1. `/repo/migrate`
2. `/repo/create`
3. `/<user>/<repo slug>/settings`
4. In general things in the "Danger zone" section where the repo name is used to validate the action
5. …
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12506
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
* migrate 17 strings related to repository migrations from INI to JSON
* changed templates to get rid of unhelpful prefix `repo`
* migrate 4 strings related to counters
* also changed templates to get rid of `repo`, but it had to be done anyway to use `TrPluralString`
* Unhardcode the header on migraiton type selector page, which I haven't noticed in https://codeberg.org/forgejo/forgejo/pulls/6795 or in two other PRs I did on this template since
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11879
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-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>
* Firefox thinks that this is a login form and that `clone_addr` is it's username field
* It would have been an easy fix with with `autocomplete="off"`, but there's an issue with that approach: Firefox plays a cat-mouse game with web developers and intentionally ignores `autocomplete="off"` "for users' security".
* Set it to the `url` autocompletion type, Firefox and maybe other browsers give actually somewhat relevant completion entries. They will not be always relevant, but they may be when a migration has to be re-done with different settings.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7377
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
This was [implemented](022820103d) almost 10 years ago in Gogs.
It was using `readonly` attribute instead of `disabled` on checkbox which was doing nothing. According to [MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/readonly), `readonly` attribute is not applicable to checkbox inputs. This bug was reported by mrwusel in Matrix room.
Fork page that has similar UI feature did not have this bug.
- replace `readonly` with `disabled`
- do not put info about the restriction directly into the checkbox title
### Before
### After
### In other case
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3786
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Don't really know a better name for this. I've gone through some Forms
and added missing HTML attributes (mostly `maxlength`). I tried to fill
the Forms with dummy Data and see if Gitea throws a Error (e.g. maximum
length). If yes, I added the missing HTML attribute.
While working on this, I discovered that the Form to add OAuth2 Apps
just silently fails when filled with invalid data, so I fixed that too.
To avoid duplicated load of the same data in an HTTP request, we can set
a context cache to do that. i.e. Some pages may load a user from a
database with the same id in different areas on the same page. But the
code is hidden in two different deep logic. How should we share the
user? As a result of this PR, now if both entry functions accept
`context.Context` as the first parameter and we just need to refactor
`GetUserByID` to reuse the user from the context cache. Then it will not
be loaded twice on an HTTP request.
But of course, sometimes we would like to reload an object from the
database, that's why `RemoveContextData` is also exposed.
The core context cache is here. It defines a new context
```go
type cacheContext struct {
ctx context.Context
data map[any]map[any]any
lock sync.RWMutex
}
var cacheContextKey = struct{}{}
func WithCacheContext(ctx context.Context) context.Context {
return context.WithValue(ctx, cacheContextKey, &cacheContext{
ctx: ctx,
data: make(map[any]map[any]any),
})
}
```
Then you can use the below 4 methods to read/write/del the data within
the same context.
```go
func GetContextData(ctx context.Context, tp, key any) any
func SetContextData(ctx context.Context, tp, key, value any)
func RemoveContextData(ctx context.Context, tp, key any)
func GetWithContextCache[T any](ctx context.Context, cacheGroupKey string, cacheTargetID any, f func() (T, error)) (T, error)
```
Then let's take a look at how `system.GetString` implement it.
```go
func GetSetting(ctx context.Context, key string) (string, error) {
return cache.GetWithContextCache(ctx, contextCacheKey, key, func() (string, error) {
return cache.GetString(genSettingCacheKey(key), func() (string, error) {
res, err := GetSettingNoCache(ctx, key)
if err != nil {
return "", err
}
return res.SettingValue, nil
})
})
}
```
First, it will check if context data include the setting object with the
key. If not, it will query from the global cache which may be memory or
a Redis cache. If not, it will get the object from the database. In the
end, if the object gets from the global cache or database, it will be
set into the context cache.
An object stored in the context cache will only be destroyed after the
context disappeared.
* Refactor `i18n` to `locale`
- Currently we're using the `i18n` variable naming for the `locale`
struct. This contains locale's specific information and cannot be used
for general i18n purpose, therefore refactoring it to `locale` makes
more sense.
- Ref: https://github.com/go-gitea/gitea/pull/20096#discussion_r906699200
* Update routers/install/install.go
This PR adds [GitBucket](https://gitbucket.github.io/) as migration source.
Supported:
- Milestones
- Issues
- Pull Requests
- Comments
- Reviews
- Labels
There is no public usable instance so no integration tests added.
