Regression of #2507, which switched the HEAD from `pr.GetGitRefName()`
to `pr.HeadCommitID` but it had to be `prInfo.HeadCommitID`. Resolves#2656
I was able to reproduce this locally with _some_ pull requests, haven't
been able to get a reproducer trough integration testing.
Inputs are normally present in the taborder of a website. When they are
inside a dropdown, this means a user could theoretically also tab
through them.
With the current dropdown approach, however, this can result in the
focus being trapped, because the dropdown is closed after the focus
switches to the next element.
In this case, the focus moves to the end of the page, breaking keyword
navigation and making parts of the page inaccessible with a keyboard.
I was only able to reproduce this in Firefox.
This patch removes inputs inside dropdowns from taborder. It should be
generally safe even with potential side-effects, because *nothing*
inside dropdowns should be in the tab order.
This is a hotfix for https://codeberg.org/forgejo/forgejo/issues/2635,
but I acknowledge it is not an ideal solution.
This should be a failing test for Firefox (but working in Chrome?) for
the taborder in the explore page.
Tabbing through the page should ensure that certain elements are focused
at least once.
We need to scan `.go` files for tailwind classes. Does not seem to
affect build time much luckily.
Fixes:
https://github.com/go-gitea/gitea/pull/29678#discussion_r1518448600
Verified via `rg tw-object-contain public/assets/css/index.css`.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 1695a5ac74afc51f38fd3a1def76cff6ba8d8641)
meilisearch does not have an search option to contorl fuzzynes per query
right now:
- https://github.com/meilisearch/meilisearch/issues/1192
- https://github.com/orgs/meilisearch/discussions/377
- https://github.com/meilisearch/meilisearch/discussions/1096
so we have to create a workaround by post-filter the search result in
gitea until this is addressed.
For future works I added an option in backend only atm, to enable
fuzzynes for issue indexer too.
And also refactored the code so the fuzzy option is equal in logic to
code indexer
---
*Sponsored by Kithara Software GmbH*
Conflicts:
routers/web/repo/search.go
trivial context confict s/isMatch/isFuzzy/
Support pasting URLs over selection text in the textarea editor. Does
not work in EasyMDE and I don't intend to support it. Image paste works
as usual in both Textarea and EasyMDE.
The new `replaceTextareaSelection` function changes textarea content via
[`insertText`](https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand#using_inserttext)
command, which preserves history, e.g. `CTRL-Z` works and is also
demostrated below. We should later refactor the image paste code to use
the same function because it currently destroys history.
Overriding the formatting via `Shift` key is supported as well, e.g.
`Ctrl+Shift+V` will insert the URL as-is, like on GitHub.
(cherry picked from commit a3cfe6f39ba33cea305de592a006727857014c53)
This seeks to fix the bug reported on issue #29196.
Cause:
ID's with custom characters (- , _ , etc.), were not linking correctly
in the Markdown file when rendered in the browser because the ID in the
respective destinies would be different than the one in anchor, while
for IDs with only letters, the ID would be the same.
Fix:
It was suggested that to fix this bug, it should more or less like
GitHub does it. While in gitea the anchors would be put in HTML like
this:
```
<p dir="auto"><a href="#user-content-_toc152597800" rel="nofollow">Review</a></p>
<p dir="auto"><a href="#user-content-_toc152597802" rel="nofollow">Staging</a></p>
<p dir="auto"><a href="#user-content-_toc152597803" rel="nofollow">Development</a></p>
<p dir="auto"><a href="#user-content-_toc152597828" rel="nofollow">Testing</a></p>
<p dir="auto"><a href="#user-content-_toc152597829" rel="nofollow">Unit-tests</a></p>
```
In GitHub, the same anchor's href properties would be the same without
"user-content-" trailing behind.
So my code made sure to change those anchors, so it would not include
"user-content-" and then add respective Event Listeners so it would
scroll into the supposed places.
Fixes: #29196
---------
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit f219ea8d0e0eccd74c786202a4ddb2784a0175ad)
When logging out of Gitea, a error toast can be seen for a split second.
I don't know why or how it happens but I found it it's an `AbortError`
(related to
[AbortController#abort](https://developer.mozilla.org/en-US/docs/Web/API/AbortController/abort)),
so let's hide it.
(cherry picked from commit 886e90aa82521d2c2ae17d3e177c056ae32e4aa6)
(cherry picked from commit 25b842df261452a29570ba89ffc3a4842d73f68c)
Conflicts:
routers/web/repo/wiki.go
services/repository/branch.go
services/repository/migrate.go
services/wiki/wiki.go
also apply to Forgejo specific usage of the refactored functions
Refactor the webhook logic, to have the type-dependent processing happen
only in one place.
---
1. An event happens
2. It is pre-processed (depending on the webhook type) and its body is
added to a task queue
3. When the task is processed, some more logic (depending on the webhook
type as well) is applied to make an HTTP request
This means that webhook-type dependant logic is needed in step 2 and 3.
This is cumbersome and brittle to maintain.
Updated webhook flow with this PR:
1. An event happens
2. It is stored as-is and added to a task queue
3. When the task is processed, the event is processed (depending on the
webhook type) to make an HTTP request
So the only webhook-type dependent logic happens in one place (step 3)
which should be much more robust.
- the raw event must be stored in the hooktask (until now, the
pre-processed body was stored)
- to ensure that previous hooktasks are correctly sent, a
`payload_version` is added (version 1: the body has already been
pre-process / version 2: the body is the raw event)
So future webhook additions will only have to deal with creating an
http.Request based on the raw event (no need to adjust the code in
multiple places, like currently).
Moreover since this processing happens when fetching from the task
queue, it ensures that the queuing of new events (upon a `git push` for
instance) does not get slowed down by a slow webhook.
As a concrete example, the PR #19307 for custom webhooks, should be
substantially smaller:
- no need to change `services/webhook/deliver.go`
- minimal change in `services/webhook/webhook.go` (add the new webhook
to the map)
- no need to change all the individual webhook files (since with this
refactor the `*webhook_model.Webhook` is provided as argument)
(cherry picked from commit 26653b196bd1d15c532af41f60351596dd4330bd)
Conflicts:
services/webhook/deliver_test.go
trivial context conflict
