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
