[webkit-dev] JavaScript evaluation result abstraction

Michael Catanzaro mcatanza at redhat.com
Fri Jul 18 08:13:14 PDT 2025


On Thu, Jul 10 2025 at 03:18:51 PM -07:00:00, Alex Christensen via 
webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 1. How long are we planning to keep ENABLE(2022_GLIB_API) in our repo?
> 

I asked about this recently. I think the answer is "indefinitely (but 
not forever)." Removing it would cut off a large number of GTK 3 
applications.

We could force an API break and create a new GTK 3 API version if we 
*really* need to, and I expect that might eventually be necessitated by 
your plans for removing InjectedBundle anyway. But API breaks are very 
high cost, so let's not do so casually.

> 2. What types of JavaScript value return types do we want to continue 
> to support?  Is the existing number/array/dictionary/string/date/null 
> abstraction enough, or is there a specific need to support more types?

Looks like you also support boolean and object types, yes?

The JSCValue API additionally supports function and promise types. But 
I'm not sure we expect those types to work via the UI process API 
(webkit_web_view_evaluate_javascript() and friends), so maybe it's OK 
to not support them? I don't see clear documentation regarding what is 
expected to work, but I imagine trying to return a function or promise 
across process boundary probably won't work? Carlos Garcia would know.

It's also possible to say: well, maybe it theoretically worked in the 
past, but if no applications actually use it, then it's OK to break.

Michael




More information about the webkit-dev mailing list