The WebKitWebExtension APIs need to be removed before releasing GTK 4 or WPE 2 APIs.
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.
+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.
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.
(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?
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.
(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.
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.
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?
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.
Well... OK, let's do as you prefer.