[webkit-dev] InjectedBundle deprecation

Tue Aug 16 18:46:24 PDT 2022

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 at 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 at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>> 
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org <mailto:webkit-dev at 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 at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20220816/acd89562/attachment.htm>