WeakRef usage (not always supported and not recommended)

[wolfbeast]

Description

JavaScript promise rejection: WeakRef is not defined. Open browser console to see more details.

I noticed Gitea's web interface started using WeakRef (noticed when posting a reply to a PR review conversation).
Please note that UXP doesn't implement WeakRef and its usage is not recommended unless you explicitly want to give hints to the JS GC for the release of (overly large) memory. Even so there is no guarantee that a JS engine will honour those hints, as they have often very complex internal machinery to deal with garbage collection. Letting content interfere with this process is not desirable; UXP doesn't intend to implement this as a result (potential can of worms also for security considerations as it might open UAFs and the like).

Please consider removing WeakRef usage from Gitea's web interface. There should not be a reason for using it to begin with. Let the engine do its own housekeeping. There is currently the risk of JS scripting breaking if it runs into WeakRef being undefined errors.

Screenshots

I didn't think of capturing the error box

Gitea Version

1.23.1

Can you reproduce the bug on the Gitea demo site?

Yes

Operating System

Windows 10 22H2

Browser Version

Pale Moon 33.5.1

[wxiaoguang]

grep -r WeakRef web_src shows that there is no WeakRef in Gitea's codebase.

Could you elaborate where it is used?

[wxiaoguang]

After searching the built assets, I found this, it is from github's text-expander https://github.com/github/text-expander-element, it uses https://github.com/iansan5653/dom-input-range/blob/main/src/input-style-clone-element.ts#L72

The related change is github/text-expander-element@180d221 (8 months ago), then text-expander started using input-style-clone which uses WeakRef.

---

I think it's impossible to remove text-expander, it is heavily used to show markdown suggestions. Do you think it's possible to polyfill the WeakRef?

[wolfbeast]

That use of WeakRef on an input doesn't even make much sense.
I'm not too familiar with writing polyfills so I don't know how easy or difficult it would be. It attaches a .deref() to the object passed into the constructor but doesn't interfere with it otherwise AFAIK.
You can polyfill this by simply using dummy functions for the API if you're married to that github module and can't make changes to it. As explained the spec is only providing hints for the garbage collector.

[wxiaoguang]

That use of WeakRef on an input doesn't even make much sense.

Yep, but that's from a dependency's dependency.

You can polyfill this by simply using dummy functions for the API if you're married to that github module and can't make changes to it. As explained the spec is only providing hints for the garbage collector.

I think you can add some polyfills to Pale Moon's engine, then all websites use WeakRef could benefit. For example:

• https://github.com/jaenster/weakref-pollyfill
• https://github.com/ungap/weakrefs

[wolfbeast]

I absolutely understand there's a broader solution possible, but you can't plug a web-based polyfill into an application's javascript engine like that. (if only! that would simplify a lot of things with all these convenience/sugar functions that get added to ES)
I have an open issue for implementing a stub into the engine but it's not straightforward.

[wolfbeast]

What would be the best way to report this to your dependency's dependency? because it really should not be used this way. Even the W3C TAG Design Principles group cautions strongly against them even existing and they should at most be used for extremely specific targeted situations and never make their way into generic dependencies or broadly-used libraries...
(see also https://repo.palemoon.org/MoonchildProductions/UXP/issues/1740 where this was analyzed when the question for implementation came up)

[TheFox0x7]

Probably raise an issue/PR there: https://github.com/iansan5653/dom-input-range

[wolfbeast]

Will do. Thanks