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. >>>> >>>>> Alex Christensen >>>>> _______________________________________________ >>>>> webkit-dev mailing list >>>>> webkit-dev@lists.webkit.org >>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>>> >>>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>> >>> -- >>> Carlos Garcia Campos >>> http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3 >>> >>> _______________________________________________ >>> 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 >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
