243906 2022-08-12 16:12:02 -0700 [GTK4] Guard WebKitWebExtension APIs 2022-09-07 07:15:36 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build PC Linux RESOLVED WONTFIX P2 Normal --- 210100 1 mcatanzaro webkit-unassigned alicem bugs-noreply cgarcia mcatanzaro oldest_to_newest 1891034 0 mcatanzaro 2022-08-12 16:12:02 -0700 The WebKitWebExtension APIs need to be removed before releasing GTK 4 or WPE 2 APIs. 1896128 1 mcatanzaro 2022-09-04 06:41:21 -0700 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. 1896132 2 alicem 2022-09-04 07:22:27 -0700 +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. 1896280 3 cgarcia 2022-09-05 01:17:28 -0700 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. 1896336 4 mcatanzaro 2022-09-05 06:53:19 -0700 (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? 1896447 5 cgarcia 2022-09-06 00:09:45 -0700 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. 1896487 6 mcatanzaro 2022-09-06 06:15:40 -0700 (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. 1896659 7 cgarcia 2022-09-07 01:08:50 -0700 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. 1896782 8 mcatanzaro 2022-09-07 06:26:26 -0700 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? 1896792 9 cgarcia 2022-09-07 06:51:22 -0700 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. 1896801 10 mcatanzaro 2022-09-07 07:15:36 -0700 Well... OK, let's do as you prefer.