Bug 243906 – [GTK4] Guard WebKitWebExtension APIs

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKitGTK

[Michael Catanzaro]

The WebKitWebExtension APIs need to be removed before releasing GTK 4 or WPE 2 APIs.

[Michael Catanzaro]

To avoid completely derailing Epiphany's port to GTK 4, instead of removing them, we should guard them behind an I_KNOW_THE_WEBKIT_WEB_PROCESS_EXTENSION_API_WILL_PROBABLY_GO_AWAY_SOON flag.

[Alice Mikhaylenko]

+1, this way we can do a proper transition like Apple ports once the replacements are in place, rather than basically preventing most apps from porting at all for months if not years.

[Carlos Garcia Campos]

I'm not sure about this, I suspect we will have to bump the api version once the new solution for JavaScript injection is added.

[Michael Catanzaro]

(In reply to Carlos Garcia Campos from comment #3)
> I'm not sure about this, I suspect we will have to bump the api version once
> the new solution for JavaScript injection is added.

You mean you think it will be possible to not completely remove the WebKitWebExtension API, and to merely bump its API version?

Or you expect we would need to bump the UI process API version?

[Carlos Garcia Campos]

It's difficult to know because we don't know how we are going to replace all the functionality exposed from injected bundle, but it's possible that the changes in the design require a new api version bump. And in any case that's not going to happen soon, so we can simply do the version bump if needed eventually.

[Michael Catanzaro]

(In reply to Carlos Garcia Campos from comment #5)
> It's difficult to know because we don't know how we are going to replace all
> the functionality exposed from injected bundle, but it's possible that the
> changes in the design require a new api version bump.

Do you expect we will need a UI process API version bump, or a web process API version bump? I was expecting that the entire injected bundle and all web process APIs would completely go away.

Of course we want a stable GTK 4 API as soon as possible, and to avoid a UI process version bump after that at all costs. I'm going to propose we remove the webkit_web_view_send_message_to_page() or webkit_web_context_send_message_to_all_extensions() UI process APIs now to avoid needing to remove them later.

[Carlos Garcia Campos]

We will need a way to inject js in any case, so whatever it's called, we will probably have to load a .so from the frame process. The point of the deprecation is to isolate iframes into their own process and current injected bundle api is page oriented, so we will need a new api for sure, based on frames. In any case, I understand we don't want to release a new api version to break it soon, but it's very difficult to make a decision now based on something that we don't know when and how it will be. So, I would focus on making easy to port apps to new api and we have to bump the version again in two years, let's just do it.

[Michael Catanzaro]

It sounds like you probably agree with the plan to keep the WebKitWebExtension APIs but guard them behind the I_KNOW_THE_WEBKIT_WEB_PROCESS_EXTENSION_API_WILL_PROBABLY_GO_AWAY_SOON flag?

[Carlos Garcia Campos]

No, I would just pretend we don't know anything about injected bundle deprecation, and just do whatever is best for the project right now. Because as I said, it's very difficult to make the right decision with the very little information we have now.

[Michael Catanzaro]

Well... OK, let's do as you prefer.