When running relative-time tests on my local system, the tests fail.
I've verified this failure does occur when the local system time is configured to use these timezones:
- America/Edmonton
- America/Boise
- America/Goose Bay
But the tests pass if the local system time is in these timezones:
- America/Phoenix (has no DST)
- Europe/Berlin (different DST rules)
"7 months ago" (the existing test case output) is accurate considering the offsets used in the test, but internally dayjs calculates it to be 7.99 months when the system TZ is in the "success" TZs, and 8.0001 months in the "failure" TZs.
I believe the source of the difference is that...
- dayjs takes timestamps with offsets, applies the offset, and then treats them as local times...
- Summer Time ended on Oct 27 (the "now" date under test) in Europe, but did not end until November 3rd in the US/Canada...
- In Europe there would have been one hour less between those local timestamps than there would be in US/Canada.
My proposed fix is to perform the diff calculations after converting the timestamps to UTC values. This provides consistent successful output regardless of the local system TZ.
As the tests are sensitive to system timezone, I've modified the CI build to run the frontend tests twice with two different TZ environment variables. This is a pretty coarse way to exercise the problem and I'm open to improvements.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8858
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
After seeing #8111 use a webcomponent, I think that they are a neat usecase for Forgejo where most of the frontend is backend-generated, with some "island of enhancements".
I am considering using a webcomponent for the CITATION management (last occurrence of [`Blob.GetBlobContent`](https://codeberg.org/forgejo/forgejo/issues/8222)), however I noticed that the developer experience wasn't ideal.
With this PR it would be very easy to declare a webcomponent, which will be loaded only if needed (I converted `model-viewer` and `pdf-object` to this technique).
Some cleanup in the neighbor webcomponents.
## Testing
1) Create a new repository or use an existing one.
2) Upload a `.pdf` or `.glb` file (such as https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/testdata/data/viewer/Unicode%E2%9D%A4%E2%99%BBTest.glb)
3) Open the Network inspector and view the file in the repository.
- After a short loading spinner, the PDF or 3D model should be rendered in a viewer
- the related JS should have been loaded (e.g. http://localhost:3000/assets/js/model-viewer.494bf0cd.js)
- visiting another page and check that this JS file isn't loaded
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8510
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: oliverpool <git@olivier.pfad.fr>
Co-committed-by: oliverpool <git@olivier.pfad.fr>
Fixes#8124
Replaces #8130
Use a custom element for relative-time. Thanks to @Beowulf for suggesting this approach.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8134
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Benedikt Straub <benedikt-straub@web.de>
Co-committed-by: Benedikt Straub <benedikt-straub@web.de>
This is my take to fix#6078
Should also resolve#6111
As far as I can tell, Forgejo uses only a subset of the relative-time functionality, and as far as I can see, this subset can be implemented using browser built-in date conversion and arithmetic. So I wrote a JavaScript to format the relative-time element accordingly, and a Go binding to generate the translated elements.
This is my first time writing Go code, and my first time coding for a large-scale server application, so please tell me if I'm doing something wrong, or if the whole approach is not acceptable.
---
Screenshot: Localized times in Low German
Screenshot: The same with Forgejo in English
---
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org).
### Tests
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I added test coverage for JavaScript changes...
- [x] in `web_src/js/*.test.js` if it can be unit tested.
- [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)).
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [x] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [x] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/6154
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Benedikt Straub <benedikt-straub@web.de>
Co-committed-by: Benedikt Straub <benedikt-straub@web.de>
