Re: [webkit-dev] InjectedBundle deprecation
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 > 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 >> 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
Re: [webkit-dev] InjectedBundle deprecation
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 > 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
Re: [webkit-dev] InjectedBundle deprecation
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 > https://lists.webkit.org/mailman/listinfo/webkit-dev -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=
Re: [webkit-dev] InjectedBundle deprecation
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 > -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3 signature.asc Description: This is a digitally signed message part ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] InjectedBundle deprecation
That sounds like the ideal way to handle this. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] InjectedBundle deprecation
I agree that this will be quite disruptive. I think it would be advantageous to deprecate the InjectedBundle APIs asap. At least for the next year (and likely a little longer) we will need to keep a working configuration without site isolation. In the very long term we probably don’t want to keep them working, but I’m not sure exactly what that time frame looks like right now. I’m not saying it’ll be a sudden change, but it is going to be a big change with big consequences that we need to start preparing for now. > On Aug 12, 2022, at 2:29 PM, Michael Catanzaro wrote: > > On Fri, Aug 12 2022 at 01:40:02 PM -0700, Alex Christensen via webkit-dev > wrote: >> 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? > > Sigh... we'll need to discuss what to do. Unfortunately, these are public > APIs and this will be extremely disruptive. If it's needed for site > isolation, I don't see that we have much choice. But if we remove these APIs, > Linux distros will get stranded on the last version of WebKit that still > supports them and will be unable to take our further updates. > > Deprecation is a lot easier than removal. If we can keep deprecated APIs > working and just disable site isolation when they're used, that would be much > less disruptive. > > Michael > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] InjectedBundle deprecation
On Fri, Aug 12 2022 at 01:40:02 PM -0700, Alex Christensen via webkit-dev wrote: 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? Sigh... we'll need to discuss what to do. Unfortunately, these are public APIs and this will be extremely disruptive. If it's needed for site isolation, I don't see that we have much choice. But if we remove these APIs, Linux distros will get stranded on the last version of WebKit that still supports them and will be unable to take our further updates. Deprecation is a lot easier than removal. If we can keep deprecated APIs working and just disable site isolation when they're used, that would be much less disruptive. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] InjectedBundle deprecation
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? Alex Christensen ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
