JavaScript error: RangeError: invalid value unit for option style

[veita]

Description

Visit https://gitea.example.org/admin. The following error is shown on a red bar on the webpage:

JavaScript error: RangeError: invalid value unit for option style
(https://git.nezwerg.de/assets/js/webcomponents.js?v=1.20.2 @ 1:21550).

Gitea Version

1.20.2

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

git version 2.39.2

Operating System

Debian 12 Bookworm

How are you running Gitea?

Gitea binary downloaded from https://github.com/go-gitea/gitea/releases/download/ and run as a Systemd service.

Browser: Pale Moon 32.3.1.

Database

PostgreSQL

[silverwind]

Can you show a screenshot of the surrounding JS code when you click the error line number in the browser console (F12)?

[wxiaoguang]

The exception is thrown here:

https://github.com/github/relative-time-element/blob/d0da95b8c69bd22b76781d50d6143f7427844380/src/duration-format-ponyfill.ts#L113

What's your browser name/version and what's your locale (eg: run window.document.documentElement.lang in your browser console)?

(Hmm, I see Browser: Pale Moon 32.3.1, maybe it's a browser's bug)

And, are you using some browser plugins like translators? Does the error still exist in private window?

[wxiaoguang]

PaleMoon bug (incomplete Intl.NumberFormat support).

You could test it on this page https://github.github.io/relative-time-element/examples/ and fix the bug accordingly.

[veita]

https://repo.palemoon.org/MoonchildProductions/Pale-Moon/issues/1930

[wolfbeast]

It's not necessarily a "bug", it's just "yet another spec change" and "yet another tacked on API". We did lift our Intl support to the proper level recently, however we do not yet support the so-called Unified NumberFormat API which Gitea apparently now wants to use. i.e. not a bug, just another feature we'll have to implement.

Couldn't this have been implemented a bit more browser-agnostic in Gitea? I mean, not like "relative date formats" are a new thing, at all.

[wxiaoguang]

Before 1.20: the "relative date" is rendered by backend, it doesn't support i18n well.

1.20: by using GitHub's "relative-time" element (#23988) , most date/time/duration texts are rendered by browser.

• https://github.com/github/relative-time-element
• https://github.github.io/relative-time-element/examples/

[wolfbeast]

Would you consider keeping the backend implementation as a fallback, at least? I mean, just hard throwing an error is always worse than "not supporting i18n well".

(as an aside, GitHub has indicated they want to always be on the bleeding edge of new client APIs, so using that as a reference for "what to implement" may not always be a good idea...)

[wxiaoguang]

I am neutral for it, but I am not familiar with the "relative-time" change. Maybe the original author @yardenshoham could suggest.

[wolfbeast]

For the record, GitHub's relative duration implementation does seem to render correctly in Pale Moon.

[wxiaoguang]

Maybe they use some internal packages or they use some polyfill packages.

[yardenshoham]

Perhaps we could add some sort of polyfill for the missing NumberFormat API? I see a backend implementation as a step back in terms of evolution

[wxiaoguang]

Just get an (somewhat strange) idea, would PaleMoon like to pack some polyfill packages by default? Then many browser features could be used out-of-box, instead of waiting for a C++ native implemention. 😁