We are talking about time scales longer than LTS support. This email thread is already 3 years old, and most LTS distros seem to support around 5 years. We can probably support current APIs another 5 years, but hopefully not longer. We’ve already done a major breaking transition with the change from single process WebKit to multi-process WebKit. That was painful but necessary.
> On Jul 30, 2025, at 2:26 PM, Demi Marie Obenour via webkit-dev > <webkit-dev@lists.webkit.org> wrote: > > On 7/29/25 20:32, Alex Christensen via webkit-dev wrote: >> Picking up this thread only 3 years later, we’ve made a lot of progress in >> this regard, and we would like to coordinate with the maintainers of the >> Linux APIs a little more. Here are the main categories we’ve made progress >> on: >> >>>>> JavaScript extensions >> We have since released public API WKWebExtension and migrated a large amount >> of code to WebKit to support it. Would a similarly shaped API meet your >> needs for JavaScript extensions? >> >>>>> Context Menu >> Similar to what you suggested, we have added enough data to >> WebHitTestResultData that there is no longer a need to use injected bundle >> callbacks for context menus. Is there information that you would need for >> your context menus that is not in WebHitTestResultData? >> >>>>> Form autofilling >> We’re prototyping some solutions using >> _WKContentWorldConfiguration.allowAutofill and .allowElementUserInfo. Are >> those solutions generic enough that they could be used for your autofill >> implementations as well? >> >>>>> Page snapshot >> WKWebView.takeSnapshotWithConfiguration is the way we’ve done this for a >> while. Do you still have a need for something like >> WKBundlePageCreateSnapshotInViewCoordinates that can’t be met by something >> like WKWebView.takeSnapshotWithConfiguration? >> >>> On Aug 16, 2022, at 7:11 PM, Alex Christensen <achristen...@apple.com> >>> wrote: >>> >>> By the way, we have many of the same hurdles that you do and we don’t have >>> good solutions to all the problems yet. >>> >>>> On Aug 16, 2022, at 6:46 PM, Alex Christensen via webkit-dev >>>> <webkit-dev@lists.webkit.org> wrote: >>>> >>>> Thanks for the analysis, Carlos! We are only at the beginning of this >>>> journey, but I’m glad we’ve begun it together. There will be many bumps >>>> along the way, but I’m confident it’ll be worth it. >>>> >>>>> On Aug 16, 2022, at 6:35 AM, Carlos Garcia Campos via webkit-dev >>>>> <webkit-dev@lists.webkit.org> wrote: >>>>> >>>>> Here is the list of features in GTK and WPE ports exposed using >>>>> injected bundle. >>>>> >>>>> JavaScript extensions >>>>> --------------------- >>>>> >>>>> Used by apps to expose current JavaScript APIs using the JSC API. This >>>>> includes: >>>>> >>>>> - WebKitScriptWorld: The window-object-cleared signal is the initial >>>>> point for injecting JavaScript. It allows allows to create isolated >>>>> worlds. >>>>> - WebKitFrame: To get the JS context. It also allows to get the JS >>>>> value for a node handle. >>>>> - WebKitDOMNode: To associate a DOM node to its JSCValue. >>>>> >>>>> We still need a way to run code in the JavaScript process. >>>>> >>>>> >>>>> Requests handling >>>>> ----------------- >>>>> >>>>> This is send-request signal to expose willSendRequest. It allows to >>>>> modify every request before it's sent or even cancel it. This was used >>>>> by epiphany to implement the adblocker before the content filter api >>>>> existed. Other apps still use it to modify the uri of requests before >>>>> being sent. >>>>> >>>>> This is not easy to migrate because going to the UI process for every >>>>> load would be too much. >>>>> >>>>> >>>>> Context Menu >>>>> ------------ >>>>> >>>>> This is the same API we have in the UI process to provide more >>>>> information and be able to build the menu based on the DOM node. For >>>>> example epiphany uses it to determine if the context menu was opened >>>>> over a node that is editable or a password input field. It's also used >>>>> to get the currently selected text. All that info is set as user data >>>>> that is passed to the context menu signal in the UI process. >>>>> >>>>> I think nowadays most of this information is already in >>>>> WebHitTestResultData and we can add whatever is missing, so this should >>>>> be easy to migrate. >>>>> >>>>> >>>>> Form autofilling >>>>> ---------------- >>>>> >>>>> We expose a signal to notify when form controls are associated to a >>>>> frame. This is used by epiphany to auto fill password fields. >>>>> >>>>> This could probably be moved to the UI process or implemented entirely >>>>> using JavaScript. >>>>> >>>>> >>>>> Password manager >>>>> ---------------- >>>>> >>>>> Related with previous one we have a signal to notify when a form is >>>>> going to be submitted. Used by epiphany to remember the passwords. >>>>> >>>>> This could probably be moved to the UI process or implemented entirely >>>>> using JavaScript. >>>>> >>>>> >>>>> Console messages >>>>> ---------------- >>>>> >>>>> API to notify the user when a console message is sent. >>>>> >>>>> This could be easily moved to the UI process, but I think nobody is >>>>> currently using this API so it can be just removed instead. >>>>> >>>>> >>>>> Editor >>>>> ------ >>>>> >>>>> Expose the selection changed signal. >>>>> >>>>> This could be implemented with JavaScript. I'm not sure this is >>>>> currently used by any application. >>>>> >>>>> >>>>> Resources load >>>>> -------------- >>>>> >>>>> This is internal implementation used to implement the UI process API >>>>> for resources. >>>>> >>>>> There's APIResourceLoadClient now, so we could probably switch to use >>>>> that or add whatever is missing. >>>>> >>>>> >>>>> Page snapshot >>>>> ------------- >>>>> >>>>> This is also internal implementation for the UI process API for page >>>>> snapshots. >>>>> >>>>> We could expose this without using injected bundle at all. >>>>> >>>>> >>>>> User messages >>>>> ------------- >>>>> >>>>> API to send custom messages between UI and web process. >>>>> >>>>> We might need this depending on how we migrate other features. >>>>> >>>>> >>>>> >>>>> >>>>> El dom, 14-08-2022 a las 09:25 +0200, Carlos Garcia Campos via webkit- >>>>> dev escribió: >>>>>> El vie, 12-08-2022 a las 13:40 -0700, Alex Christensen via webkit-dev >>>>>> escribió: >>>>>>> Hello WebKit developers! We are ramping up to do some serious work >>>>>>> on >>>>>>> Site Isolation which includes putting cross-origin iframes in a >>>>>>> different process than the parent frame. Similar efforts have been >>>>>>> done in other browser engines and some related work has already >>>>>>> been >>>>>>> done in WebKit, but not enough. >>>>>>> >>>>>>> This will do strange things to the InjectedBundle APIs, which have >>>>>>> fundamental assumptions that the whole DOM is in one process and >>>>>>> that >>>>>>> communication only happens with one process at a time. We have >>>>>>> never >>>>>>> exposed InjectedBundle APIs as public API, but some other >>>>>>> distributors of WebKit have. As we make progress on this project, >>>>>>> we >>>>>>> anticipate that anything in >>>>>>> Source/WebKit/WebProcess/InjectedBundle/API is subject to >>>>>>> deprecation >>>>>>> and removal. This will also allow us to tighten the sandbox on the >>>>>>> web process, resolve security and performance issues, and have >>>>>>> cleaner code. >>>>>>> >>>>>>> Would the maintainers of the GTK and WPE APIs be willing to assist >>>>>>> in >>>>>>> migrating from those APIs and designing replacements in the UI >>>>>>> process? >>>>>>> >>>>>> >>>>>> Sure. I think the most important feature we expose from injected >>>>>> bundle >>>>>> is JavaScript extensibility using the JSC API. >>>>>> >>>>>> Next week I can write a summary of the features we currently expose >>>>>> from injected bundle and possible alternatives. > > Personally, I think breaking changes to embedded browser APIs need > to be avoided if at all possible. The reason is that stable and > LTS distros need to be confident that they can ship WebKitGTK+ > updates without breaking applications. Otherwise, distros are in > the bad position of being forced to break API (and possibly ABI) > within a release in order to ship security patches. WebKitGTK+ > is security supported in Debian and I believe this is only possible > because its API and ABI are stable. > > Would it be possible to provide a degraded version of the API > instead? For instance, creating a cross-origin iframe might fail > if InjectedBundle is used. > -- > Sincerely, > Demi Marie Obenour > (she/her/hers)<OpenPGP_0xB288B55FFF9C22C1.asc>_______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
