Re: Unsafe CPOWs are about to be outlawed in browser code
The spaghetti was put in the machine last night - this work has now landed on mozilla-central. If you start seeing "unsafe CPOW usage forbidden" in the Browser Console for various things, please mark them blocking bug 1233497. Thanks all, -Mike On 20/01/2016 3:54 PM, Mike Conley wrote: > (cross-posted to both dev-platform and firefox-dev) > * > * > TL;DR: Shortly, I’ll be flipping a pref to outlaw unsafe CPOWs in almost > all browser code. Unsafe CPOWs inside add-on scopes should continue to > work properly. If you start seeing "unsafe CPOW usage forbidden” errors > being throw for a feature you’re working on in the Browser Console, it’s > because unsafe CPOWs have been outlawed and you should stop using them. > Talk to me if you run into problems. > > Details: > > “unsafe” CPOWs[1][2] are CPOWs that are accessed when the other process > is not currently blocked waiting for information from you. For example, > if you access gBrowser.selectedBrowser.contentDocumentAsCPOW.body when > the content process is garbage collecting, the parent will be blocked > until the child decides that it has a moment to service the synchronous > message and return the information that the parent needs. Unsafe CPOWS > are generally pretty horrible for performance, especially because we > cannot know what state the other process is in. > > “safe” CPOWs are when the other process is in a known blocked state - > for example, the content process sends a synchronous message to the > parent asking for some information, and is blocked waiting for a > response. The parent then accesses CPOWs in the content process safely, > because the content process is in a known state. The only overhead here > is the IPC traffic. > > “unsafe” CPOWs are often used by add-ons to synchronously manipulate > content. A year or so back, a bunch of browser code also used unsafe > CPOWs in this way, but we’ve been slowly but surely weeding them out. > We’re at the state now where we believe we’ve eliminated most of the > in-browser unsafe CPOW uses[3]. > > Within the next day or so, I’m going to be landing bug 1233497[4] which > will cause unsafe CPOW usage in non-addon browser code to throw. In the > event that this breaks things horribly, there is a pref[5] that we can > flip to turn unsafe CPOWs back on while we fix things. > > Again, this work is occurring in bug 1233497[4]. If there are any major > concerns, please bring them up here before I throw the spaghetti into > the machine. > > For more details on unsafe CPOWs, please read [1] and/or [2]. > > [1]: > https://mikeconley.ca/blog/2015/02/17/on-unsafe-cpow-usage-in-firefox-desktop-and-why-is-my-nightly-so-sluggish-with-e10s-enabled/ > > [2]: http://blog.lassey.us/2015/01/10/unsafe-cpow-usage/ > [3]: Outside of tests, and a few other little things that there are > follow-ups for. > [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1233497 > [5]: dom.ipc.cpows.forbid-unsafe-from-browser > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unsafe CPOWs are about to be outlawed in browser code
Do we have any agenda for extensions? I'm using FireGestures and it's broken since this has landed, just shouting out a lot of "unsafe CPOW usage" (missing the "forbidden" tho). Is the action here limited to just file a bug on the add-on side to fix this or can we do anything on our side? (I presume and also support that add-ons should be fixed here.) Thanks. -hb- On 1/27/2016 17:42, Mike Conley wrote: The spaghetti was put in the machine last night - this work has now landed on mozilla-central. If you start seeing "unsafe CPOW usage forbidden" in the Browser Console for various things, please mark them blocking bug 1233497. Thanks all, -Mike On 20/01/2016 3:54 PM, Mike Conley wrote: (cross-posted to both dev-platform and firefox-dev) * * TL;DR: Shortly, I’ll be flipping a pref to outlaw unsafe CPOWs in almost all browser code. Unsafe CPOWs inside add-on scopes should continue to work properly. If you start seeing "unsafe CPOW usage forbidden” errors being throw for a feature you’re working on in the Browser Console, it’s because unsafe CPOWs have been outlawed and you should stop using them. Talk to me if you run into problems. Details: “unsafe” CPOWs[1][2] are CPOWs that are accessed when the other process is not currently blocked waiting for information from you. For example, if you access gBrowser.selectedBrowser.contentDocumentAsCPOW.body when the content process is garbage collecting, the parent will be blocked until the child decides that it has a moment to service the synchronous message and return the information that the parent needs. Unsafe CPOWS are generally pretty horrible for performance, especially because we cannot know what state the other process is in. “safe” CPOWs are when the other process is in a known blocked state - for example, the content process sends a synchronous message to the parent asking for some information, and is blocked waiting for a response. The parent then accesses CPOWs in the content process safely, because the content process is in a known state. The only overhead here is the IPC traffic. “unsafe” CPOWs are often used by add-ons to synchronously manipulate content. A year or so back, a bunch of browser code also used unsafe CPOWs in this way, but we’ve been slowly but surely weeding them out. We’re at the state now where we believe we’ve eliminated most of the in-browser unsafe CPOW uses[3]. Within the next day or so, I’m going to be landing bug 1233497[4] which will cause unsafe CPOW usage in non-addon browser code to throw. In the event that this breaks things horribly, there is a pref[5] that we can flip to turn unsafe CPOWs back on while we fix things. Again, this work is occurring in bug 1233497[4]. If there are any major concerns, please bring them up here before I throw the spaghetti into the machine. For more details on unsafe CPOWs, please read [1] and/or [2]. [1]: https://mikeconley.ca/blog/2015/02/17/on-unsafe-cpow-usage-in-firefox-desktop-and-why-is-my-nightly-so-sluggish-with-e10s-enabled/ [2]: http://blog.lassey.us/2015/01/10/unsafe-cpow-usage/ [3]: Outside of tests, and a few other little things that there are follow-ups for. [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1233497 [5]: dom.ipc.cpows.forbid-unsafe-from-browser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unsafe CPOWs are about to be outlawed in browser code
I don't think that this is meant to impact add-on code at all, unless it is calling browser code and making it do something unsafe, in which case it would be up to the add-on developer to fix that. It's probably worth filing a bug to track what is going on there though. On Thu, Jan 28, 2016 at 6:36 AM, Honza Bambas wrote: > Do we have any agenda for extensions? I'm using FireGestures and it's broken > since this has landed, just shouting out a lot of "unsafe CPOW usage" > (missing the "forbidden" tho). > > Is the action here limited to just file a bug on the add-on side to fix this > or can we do anything on our side? (I presume and also support that add-ons > should be fixed here.) > > Thanks. > > -hb- > > > On 1/27/2016 17:42, Mike Conley wrote: >> >> The spaghetti was put in the machine last night - this work has now >> landed on mozilla-central. >> >> If you start seeing "unsafe CPOW usage forbidden" in the Browser Console >> for various things, please mark them blocking bug 1233497. >> >> Thanks all, >> >> -Mike >> >> On 20/01/2016 3:54 PM, Mike Conley wrote: >>> >>> (cross-posted to both dev-platform and firefox-dev) >>> * >>> * >>> TL;DR: Shortly, I’ll be flipping a pref to outlaw unsafe CPOWs in almost >>> all browser code. Unsafe CPOWs inside add-on scopes should continue to >>> work properly. If you start seeing "unsafe CPOW usage forbidden” errors >>> being throw for a feature you’re working on in the Browser Console, it’s >>> because unsafe CPOWs have been outlawed and you should stop using them. >>> Talk to me if you run into problems. >>> >>> Details: >>> >>> “unsafe” CPOWs[1][2] are CPOWs that are accessed when the other process >>> is not currently blocked waiting for information from you. For example, >>> if you access gBrowser.selectedBrowser.contentDocumentAsCPOW.body when >>> the content process is garbage collecting, the parent will be blocked >>> until the child decides that it has a moment to service the synchronous >>> message and return the information that the parent needs. Unsafe CPOWS >>> are generally pretty horrible for performance, especially because we >>> cannot know what state the other process is in. >>> >>> “safe” CPOWs are when the other process is in a known blocked state - >>> for example, the content process sends a synchronous message to the >>> parent asking for some information, and is blocked waiting for a >>> response. The parent then accesses CPOWs in the content process safely, >>> because the content process is in a known state. The only overhead here >>> is the IPC traffic. >>> >>> “unsafe” CPOWs are often used by add-ons to synchronously manipulate >>> content. A year or so back, a bunch of browser code also used unsafe >>> CPOWs in this way, but we’ve been slowly but surely weeding them out. >>> We’re at the state now where we believe we’ve eliminated most of the >>> in-browser unsafe CPOW uses[3]. >>> >>> Within the next day or so, I’m going to be landing bug 1233497[4] which >>> will cause unsafe CPOW usage in non-addon browser code to throw. In the >>> event that this breaks things horribly, there is a pref[5] that we can >>> flip to turn unsafe CPOWs back on while we fix things. >>> >>> Again, this work is occurring in bug 1233497[4]. If there are any major >>> concerns, please bring them up here before I throw the spaghetti into >>> the machine. >>> >>> For more details on unsafe CPOWs, please read [1] and/or [2]. >>> >>> [1]: >>> https://mikeconley.ca/blog/2015/02/17/on-unsafe-cpow-usage-in-firefox-desktop-and-why-is-my-nightly-so-sluggish-with-e10s-enabled/ >>> >>> [2]: http://blog.lassey.us/2015/01/10/unsafe-cpow-usage/ >>> [3]: Outside of tests, and a few other little things that there are >>> follow-ups for. >>> [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1233497 >>> [5]: dom.ipc.cpows.forbid-unsafe-from-browser >>> >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform > > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unsafe CPOWs are about to be outlawed in browser code
Add-ons that are not yet marked multi-process compatible will use our shimming layer, which allows usage of unsafe CPOWs within add-on code / compartments. At least part of the problem here appears to be that FireGestures has "multiprocessCompatible" set to true in its install.rdf: https://github.com/gomita/firegestures/blob/7bd7db329c985dece9717105b07ede6303827a3d/install.rdf#L317 This will cause it to bypass our shim layer, which means it doesn't get a free pass on using CPOWs anymore. I'll see if I can make some recommendations to that add-on author in the associated GitHub issue: https://github.com/gomita/firegestures/issues/116 On 28 January 2016 at 11:57, Dave Townsend wrote: > I don't think that this is meant to impact add-on code at all, unless > it is calling browser code and making it do something unsafe, in which > case it would be up to the add-on developer to fix that. It's probably > worth filing a bug to track what is going on there though. > > On Thu, Jan 28, 2016 at 6:36 AM, Honza Bambas wrote: > > Do we have any agenda for extensions? I'm using FireGestures and it's > broken > > since this has landed, just shouting out a lot of "unsafe CPOW usage" > > (missing the "forbidden" tho). > > > > Is the action here limited to just file a bug on the add-on side to fix > this > > or can we do anything on our side? (I presume and also support that > add-ons > > should be fixed here.) > > > > Thanks. > > > > -hb- > > > > > > On 1/27/2016 17:42, Mike Conley wrote: > >> > >> The spaghetti was put in the machine last night - this work has now > >> landed on mozilla-central. > >> > >> If you start seeing "unsafe CPOW usage forbidden" in the Browser Console > >> for various things, please mark them blocking bug 1233497. > >> > >> Thanks all, > >> > >> -Mike > >> > >> On 20/01/2016 3:54 PM, Mike Conley wrote: > >>> > >>> (cross-posted to both dev-platform and firefox-dev) > >>> * > >>> * > >>> TL;DR: Shortly, I’ll be flipping a pref to outlaw unsafe CPOWs in > almost > >>> all browser code. Unsafe CPOWs inside add-on scopes should continue to > >>> work properly. If you start seeing "unsafe CPOW usage forbidden” errors > >>> being throw for a feature you’re working on in the Browser Console, > it’s > >>> because unsafe CPOWs have been outlawed and you should stop using them. > >>> Talk to me if you run into problems. > >>> > >>> Details: > >>> > >>> “unsafe” CPOWs[1][2] are CPOWs that are accessed when the other process > >>> is not currently blocked waiting for information from you. For example, > >>> if you access gBrowser.selectedBrowser.contentDocumentAsCPOW.body when > >>> the content process is garbage collecting, the parent will be blocked > >>> until the child decides that it has a moment to service the synchronous > >>> message and return the information that the parent needs. Unsafe CPOWS > >>> are generally pretty horrible for performance, especially because we > >>> cannot know what state the other process is in. > >>> > >>> “safe” CPOWs are when the other process is in a known blocked state - > >>> for example, the content process sends a synchronous message to the > >>> parent asking for some information, and is blocked waiting for a > >>> response. The parent then accesses CPOWs in the content process safely, > >>> because the content process is in a known state. The only overhead here > >>> is the IPC traffic. > >>> > >>> “unsafe” CPOWs are often used by add-ons to synchronously manipulate > >>> content. A year or so back, a bunch of browser code also used unsafe > >>> CPOWs in this way, but we’ve been slowly but surely weeding them out. > >>> We’re at the state now where we believe we’ve eliminated most of the > >>> in-browser unsafe CPOW uses[3]. > >>> > >>> Within the next day or so, I’m going to be landing bug 1233497[4] which > >>> will cause unsafe CPOW usage in non-addon browser code to throw. In the > >>> event that this breaks things horribly, there is a pref[5] that we can > >>> flip to turn unsafe CPOWs back on while we fix things. > >>> > >>> Again, this work is occurring in bug 1233497[4]. If there are any major > >>> concerns, please bring them up here before I throw the spaghetti into > >>> the machine. > >>> > >>> For more details on unsafe CPOWs, please read [1] and/or [2]. > >>> > >>> [1]: > >>> > https://mikeconley.ca/blog/2015/02/17/on-unsafe-cpow-usage-in-firefox-desktop-and-why-is-my-nightly-so-sluggish-with-e10s-enabled/ > >>> > >>> [2]: http://blog.lassey.us/2015/01/10/unsafe-cpow-usage/ > >>> [3]: Outside of tests, and a few other little things that there are > >>> follow-ups for. > >>> [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1233497 > >>> [5]: dom.ipc.cpows.forbid-unsafe-from-browser > >>> > >> ___ > >> dev-platform mailing list > >> dev-platform@lists.mozilla.org > >> https://lists.mozilla.org/listinfo/dev-platform > > > > > > > > ___ > > dev-platform mailin
Re: Unsafe CPOWs are about to be outlawed in browser code
On Thu, Jan 28, 2016 at 10:16 AM, Mike Conley wrote: > Add-ons that are not yet marked multi-process compatible will use our > shimming layer, which allows usage of unsafe CPOWs within add-on code / > compartments. > > At least part of the problem here appears to be that FireGestures has > "multiprocessCompatible" set to true in its install.rdf: > > > https://github.com/gomita/firegestures/blob/7bd7db329c985dece9717105b07ede6303827a3d/install.rdf#L317 > > This will cause it to bypass our shim layer, which means it doesn't get a > free pass on using CPOWs anymore. > I'm not sure this is the problem. The patch in bug 1233497 just looks at whether an add-on is making the CPOW request. It doesn't know anything about shims or multiprocessCompatible. > > I'll see if I can make some recommendations to that add-on author in the > associated GitHub issue: https://github.com/gomita/firegestures/issues/116 > > On 28 January 2016 at 11:57, Dave Townsend wrote: > > > I don't think that this is meant to impact add-on code at all, unless > > it is calling browser code and making it do something unsafe, in which > > case it would be up to the add-on developer to fix that. It's probably > > worth filing a bug to track what is going on there though. > > > > On Thu, Jan 28, 2016 at 6:36 AM, Honza Bambas > wrote: > > > Do we have any agenda for extensions? I'm using FireGestures and it's > > broken > > > since this has landed, just shouting out a lot of "unsafe CPOW usage" > > > (missing the "forbidden" tho). > > > > > > Is the action here limited to just file a bug on the add-on side to fix > > this > > > or can we do anything on our side? (I presume and also support that > > add-ons > > > should be fixed here.) > > > > > > Thanks. > > > > > > -hb- > > > > > > > > > On 1/27/2016 17:42, Mike Conley wrote: > > >> > > >> The spaghetti was put in the machine last night - this work has now > > >> landed on mozilla-central. > > >> > > >> If you start seeing "unsafe CPOW usage forbidden" in the Browser > Console > > >> for various things, please mark them blocking bug 1233497. > > >> > > >> Thanks all, > > >> > > >> -Mike > > >> > > >> On 20/01/2016 3:54 PM, Mike Conley wrote: > > >>> > > >>> (cross-posted to both dev-platform and firefox-dev) > > >>> * > > >>> * > > >>> TL;DR: Shortly, I’ll be flipping a pref to outlaw unsafe CPOWs in > > almost > > >>> all browser code. Unsafe CPOWs inside add-on scopes should continue > to > > >>> work properly. If you start seeing "unsafe CPOW usage forbidden” > errors > > >>> being throw for a feature you’re working on in the Browser Console, > > it’s > > >>> because unsafe CPOWs have been outlawed and you should stop using > them. > > >>> Talk to me if you run into problems. > > >>> > > >>> Details: > > >>> > > >>> “unsafe” CPOWs[1][2] are CPOWs that are accessed when the other > process > > >>> is not currently blocked waiting for information from you. For > example, > > >>> if you access gBrowser.selectedBrowser.contentDocumentAsCPOW.body > when > > >>> the content process is garbage collecting, the parent will be blocked > > >>> until the child decides that it has a moment to service the > synchronous > > >>> message and return the information that the parent needs. Unsafe > CPOWS > > >>> are generally pretty horrible for performance, especially because we > > >>> cannot know what state the other process is in. > > >>> > > >>> “safe” CPOWs are when the other process is in a known blocked state - > > >>> for example, the content process sends a synchronous message to the > > >>> parent asking for some information, and is blocked waiting for a > > >>> response. The parent then accesses CPOWs in the content process > safely, > > >>> because the content process is in a known state. The only overhead > here > > >>> is the IPC traffic. > > >>> > > >>> “unsafe” CPOWs are often used by add-ons to synchronously manipulate > > >>> content. A year or so back, a bunch of browser code also used unsafe > > >>> CPOWs in this way, but we’ve been slowly but surely weeding them out. > > >>> We’re at the state now where we believe we’ve eliminated most of the > > >>> in-browser unsafe CPOW uses[3]. > > >>> > > >>> Within the next day or so, I’m going to be landing bug 1233497[4] > which > > >>> will cause unsafe CPOW usage in non-addon browser code to throw. In > the > > >>> event that this breaks things horribly, there is a pref[5] that we > can > > >>> flip to turn unsafe CPOWs back on while we fix things. > > >>> > > >>> Again, this work is occurring in bug 1233497[4]. If there are any > major > > >>> concerns, please bring them up here before I throw the spaghetti into > > >>> the machine. > > >>> > > >>> For more details on unsafe CPOWs, please read [1] and/or [2]. > > >>> > > >>> [1]: > > >>> > > > https://mikeconley.ca/blog/2015/02/17/on-unsafe-cpow-usage-in-firefox-desktop-and-why-is-my-nightly-so-sluggish-with-e10s-enabled/ > > >>> > > >>> [2]: http://blog.lassey.us/2015/01/10/unsafe-cpow-us
Re: Unsafe CPOWs are about to be outlawed in browser code
четверг, 28 января 2016 г., 19:57:59 UTC+3 пользователь Dave Townsend написал: > I don't think that this is meant to impact add-on code at all, unless > it is calling browser code and making it do something unsafe, in which > case it would be up to the add-on developer to fix that. It's probably > worth filing a bug to track what is going on there though. Hi! My addon is reportedly broken in the Nightly: https://github.com/dgutov/bmreplace/issues/32#issuecomment-176126946 It imports PlacesUIUtils.jsm and calls three functions from it, most notably PlacesUIUtils.getDescriptionFromDocument. How do I "fix" that in the addon, aside for doing the big transition to an E10s-friendly architecture? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unsafe CPOWs are about to be outlawed in browser code
On Thu, Jan 28, 2016 at 06:30:03PM -0800, raa...@gmail.com wrote: Hi! My addon is reportedly broken in the Nightly: https://github.com/dgutov/bmreplace/issues/32#issuecomment-176126946 It imports PlacesUIUtils.jsm and calls three functions from it, most notably PlacesUIUtils.getDescriptionFromDocument. How do I "fix" that in the addon, aside for doing the big transition to an E10s-friendly architecture? That falls into the category of "unless it is calling browser code and making it do something unsafe". If you need to use that function from the main process, you can only do so from the message listener for a synchronous message from the content process (or a few other similar situations). While you're at it, though, it would be a good idea to make that function asynchronous, so that you can check the description from the content process, and look up whether the URL is bookmarked, without blocking the browser process. -- Kris Maglione Firefox Add-ons Engineer Mozilla Corporation It is well to know something of the manners of various peoples, in order more sanely to judge our own, and that we do not think that everything against our modes is ridiculous, and against reason, as those who have seen nothing are accustomed to think. --Rene Descartes ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unsafe CPOWs are about to be outlawed in browser code
On Tue, Feb 02, 2016 at 01:39:00AM +0300, Dmitry Gutov wrote: On 02/02/2016 12:29 AM, Kris Maglione wrote: That falls into the category of "unless it is calling browser code and making it do something unsafe". That's too bad. I'm just reusing a querying function from there, and a pretty small one. It's not as small as you might think. In the best case, that function makes two CPOW calls, one for getElementsByTagName, and one to check its length. If any tags are returned, it makes as many as 5 calls for each one, and a sixth for the first one that matches. In the cases where the content process isn't blocked on sync message, any or all of those requests might go out while the content process is in the middle of executing a slow script. The contents of those elements could change between each call. The browser could navigate to a different page. Yes, that will add some complexity. It seems I can just copy getDescriptionFromDocument's definition until I get around to supporting E10s properly. You could, but it would really be better not to. Unsafe CPOW usage is called unsafe for a reason. Should be a plus, but the user's just waiting for the action to complete at this point, so it's not like there are many other things for the browser process to do. You might be surprised. In your case, the difference between making simultaneous asynchronous requests to look up existing bookmarks and to get the description, and making blocking, synchronous calls for both, could easily be the difference between the action appearing to complete immediately, and it taking, at the very least, a noticeable amount of time. In the mean time, since you're blocking the event loop on the requests, it means that the UI is essentially frozen. Animations and roll-over effects are stopped. If the content process is in the middle of a slow script, and the hard drive is busy, the UI could easily be completely unresponsive for seconds at a time. There are definitely worse times to do synchronous bookmark queries and unsafe CPOW requests than in response to a user clicking a button, but that doesn't mean they don't cause problems. -- Kris Maglione Firefox Add-ons Engineer Mozilla Corporation If C gives you enough rope to hang yourself, C++ gives you enough rope to bind and gag your neighbourhood, rig the sails in a small ship and still have enough rope left to hang yourself from the yardarm. --Anonymous ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unsafe CPOWs are about to be outlawed in browser code
On 02/02/2016 12:29 AM, Kris Maglione wrote: That falls into the category of "unless it is calling browser code and making it do something unsafe". That's too bad. I'm just reusing a querying function from there, and a pretty small one. If you need to use that function from the main process, you can only do so from the message listener for a synchronous message from the content process (or a few other similar situations). Yes, that will add some complexity. It seems I can just copy getDescriptionFromDocument's definition until I get around to supporting E10s properly. While you're at it, though, it would be a good idea to make that function asynchronous, so that you can check the description from the content process, and look up whether the URL is bookmarked, without blocking the browser process. Should be a plus, but the user's just waiting for the action to complete at this point, so it's not like there are many other things for the browser process to do. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform