- Prefer
[window.location.assign](https://developer.mozilla.org/en-US/docs/Web/API/Location/assign)
over assigning to
[window.location](https://developer.mozilla.org/en-US/docs/Web/API/Window/location)
which typescript does not like. This works in all browsers including
PaleMoon.
- Fix all typescript issues in `web_src/js/webcomponents`, no behaviour
changes.
- ~~Workaround bug in `@typescript-eslint/no-unnecessary-type-assertion`
rule.~~
- Omit vendored file from type checks.
- `tsc` error count is reduce by 53 with these changes.
---
Conflict resolution: Choose our version.
Done differently: Everything related to typescript types isn't ported.
Use `window.location.href` instead of `String(window.location)`, thanks
@viceice!
(cherry picked from commit 810782302652d73c4f7249c4c3df8a7e85bae5f0)
This will move the settings button back to the right, like known from
older versions.
For this, the overflow-menu was changed when a setting button is
available. If no settings button is available, the behavior will not
change.
Fixes#3301
There is a small layout shift in when active tab changes. Notice how the
actions SVG is unstable:
This is because the active item with bold text is wider then the
inactive one. I have applied [this
trick](https://stackoverflow.com/a/32570813/808699) to prevent this
layout shift. It's only active inside `<overflow-menu>` because I wanted
to avoid changing HTML and doing it in regular JS would cause a flicker.
I don't expect us to introduce other similar menus without
`<overflow-menu>`, so that place is likely fine.
I also changed the weight from 500 to 600, slightly reduced horizontal
padding, merged some tab-bar related CSS rules and a added a small
margin below repo-header so it does not look so crammed against the
buttons on top.
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
---
Conflict resolution: Moved an `:focus` selector to the new CSS rule.
Ref: https://codeberg.org/forgejo/forgejo/issues/2776
(cherry picked from commit 99d7ef50917e8d61798715e1b0b3dc1a99709f27)
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'
Ported the function as-is and added comments so we don't forget about
this in the future.
Fixes: https://github.com/go-gitea/gitea/issues/29462
(cherry picked from commit 82405f808d7b50c3580f26e5ca645e2ed6d284ab)
When setting `url.host` on a URL object with no port specified (like is
the case of default port), the resulting URL's port will not change.
Workaround this quirk in the URL standard by explicitely setting port
for the http and https protocols.
Extracted the logic to a function for the purpose of testing. Initially
I wanted to have the function in utils.js, but it turns out esbuild can
not treeshake the unused functions which would result in the
webcomponents chunk having all 2kB utils.js inlined, so it seemed not
worth.
Fixes: https://github.com/go-gitea/gitea/issues/29084
(cherry picked from commit b6bf8041d8e8ee845728687b1f358f1d482afff2)
Related: #23590
Reference:
https://github.com/webcomponents/polyfills/tree/master/packages/webcomponentsjs
It seems that there are some users using old browsers, so the
`window.customElements` need polyfill.
The Custom Elements would help a lot for Gitea's UI problems, including:
* `<span class="js-pretty-number">`
* `<time data-format>`
So it's worth get polyfill.
---------
Co-authored-by: delvh <dev.lh@web.de>
This PR follows:
* #21986
* #22831
This PR also introduce customized HTML elements, which would also help
problems like:
* #17760
* #21429
* #21440
With customized HTML elements, there won't be any load-search-replace
operations, and it can avoid page flicking (which @silverwind cares a
lot).
Browser support:
https://developer.mozilla.org/en-US/docs/Web/API/Window/customElements
# FAQ
## Why the component has the prefix?
As usual, I would strongly suggest to add prefixes for our own/private
names. The dedicated prefix will avoid conflicts in the future, and it
makes it easier to introduce various 3rd components, like GitHub's
`relative-time` component. If there is no prefix, it's impossible to
introduce another public component with the same name in the future.
## Why the `custcomp.js` is loaded before HTML body? The `index.js` is
after HTML body.
Customized components must be registered before the content loading.
Otherwise there would be still some flicking.
`custcomp.js` should have its own dependencies and should be very light,
so it won't affect the page loading time too much.
## Why use `data-url` attribute but not use the `textContent`?
According to the standard, the `connectedCallback` occurs on the
tag-opening moment. The element's children are not ready yet.
## Why not use `{{.GuessCurrentOrigin $.ctx ...}}` to let backend decide
the absolute URL?
It's difficult for backend to guess the correct protocol(scheme)
correctly with zero configuration. Generating the absolute URL from
frontend can guarantee that the URL is 100% correct -- since the user is
visiting it.
# Screenshot
<details>
</details>
Gusted
