Enabling Dev Channel APIs On Stable

[PhistucK]

I would like to use the chrome.processes API on the stable channel in order to try to workaround a nasty bug where Chrome creates zombie processes whenever I read a message in GMail and makes my machine very slow due to high memory consumption (if you are curious, crbug.com/707509).

I enabled the experimental extension APIs flag, but chrome.processes is undefined.

After much searching, I found the way (on Windows, at least), using some registry fiddling (set the "ap" entry to "x64-dev").

Why does the experimental extension APIs flag not let you use all of the experimental extension APIs? Why do you limit some APIs to certain channels without a command line flag to enable them elsewhere?

:(

☆PhistucK

[Ricardo Feliciano]

I think you're missing the whole point of Chrome's release channels. Channels other than "stable" are there to test features. Maybe they're not ready, maybe Google isn't sure people want them, maybe they're unstable, etc. As the API stabilizes and proves useful, it'll make it to the stable channel. Then you can utilize it.

Trying to force an unstable API onto someone's "stable" install of Google Chrome is unfair to the user. Chrome shouldn't allow you to do that.

[PhistucK]

That specific API exists for more than five years, if I remember correctly.

The experimental APIs (with a command line flag, banned from the store) were introduced for experimentation purposes at some point and at a later point, the channel came to be used instead (but the flag still exists).

I do not see the point of having multiple ways to experiment with APIs and I do not see the point of not letting the stable channel use an experimental API, gated by a command line flag (that already exists).

Why must I sacrifice the general stability (and maybe even security) of the browser (unrelated to the aforementioned API) for experimenting with an API? I do not think the two should necessarily be connected so tightly. Especially if it is a defense mechanism (hardly, as it can be easily broken down by changing a registry value. Malicious software can change registry values as well and open a can of worms).

It does not make sense to have really dangerous, sandbox-disabling and web-security-disabling flags available to the stable channel and not experimental extension APIs.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Chromium-Extensions-Announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.
To post to this group, send email to chromium-extensions@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/8b0ce5cb-6b91-4bbf-8964-ffa236ca2899%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Devlin Cronin]

Hey PhistucK!  I agree with you that the experimental extension APIs flag should probably also enable APIs that are restricted to other channels; that sounds totally reasonable.  Can you file a new bug at crbug.com/new and cc me on it?  We'll run it by some other folks, but I think we should be able to make this happen.

(Separately, we are still thinking about the processes API, but there are a few things that need to happen before we can launch it, and no one with the bandwidth to tackle them.  But it's not entirely forgotten!)

Cheers,

- Devlin

[PhistucK]

Done with some code hints. ;)

crbug.com/763960

☆PhistucK

On Mon, Sep 11, 2017 at 6:11 PM, Devlin Cronin <rdevlin...@chromium.org> wrote:

Hey PhistucK!  I agree with you that the experimental extension APIs flag should probably also enable APIs that are restricted to other channels; that sounds totally reasonable.  Can you file a new bug at crbug.com/new and cc me on it?  We'll run it by some other folks, but I think we should be able to make this happen.

(Separately, we are still thinking about the processes API, but there are a few things that need to happen before we can launch it, and no one with the bandwidth to tackle them.  But it's not entirely forgotten!)

Cheers,

- Devlin

On Saturday, September 9, 2017 at 10:11:04 AM UTC-7, PhistucK wrote:

That specific API exists for more than five years, if I remember correctly.

The experimental APIs (with a command line flag, banned from the store) were introduced for experimentation purposes at some point and at a later point, the channel came to be used instead (but the flag still exists).

I do not see the point of having multiple ways to experiment with APIs and I do not see the point of not letting the stable channel use an experimental API, gated by a command line flag (that already exists).

Why must I sacrifice the general stability (and maybe even security) of the browser (unrelated to the aforementioned API) for experimenting with an API? I do not think the two should necessarily be connected so tightly. Especially if it is a defense mechanism (hardly, as it can be easily broken down by changing a registry value. Malicious software can change registry values as well and open a can of worms).

It does not make sense to have really dangerous, sandbox-disabling and web-security-disabling flags available to the stable channel and not experimental extension APIs.

☆PhistucK

On Sat, Sep 9, 2017 at 7:46 PM, Ricardo Feliciano <felici...@gmail.com> wrote:

I think you're missing the whole point of Chrome's release channels. Channels other than "stable" are there to test features. Maybe they're not ready, maybe Google isn't sure people want them, maybe they're unstable, etc. As the API stabilizes and proves useful, it'll make it to the stable channel. Then you can utilize it.

Trying to force an unstable API onto someone's "stable" install of Google Chrome is unfair to the user. Chrome shouldn't allow you to do that.

On Saturday, September 9, 2017 at 6:19:48 AM UTC-4, PhistucK wrote:

I would like to use the chrome.processes API on the stable channel in order to try to workaround a nasty bug where Chrome creates zombie processes whenever I read a message in GMail and makes my machine very slow due to high memory consumption (if you are curious, crbug.com/707509).

I enabled the experimental extension APIs flag, but chrome.processes is undefined.

After much searching, I found the way (on Windows, at least), using some registry fiddling (set the "ap" entry to "x64-dev").

Why does the experimental extension APIs flag not let you use all of the experimental extension APIs? Why do you limit some APIs to certain channels without a command line flag to enable them elsewhere?

:(

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Chromium-Extensions-Announce" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsubscribe...@chromium.org.

To post to this group, send email to chromium-extensions@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/8b0ce5cb-6b91-4bbf-8964-ffa236ca2899%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

--
You received this message because you are subscribed to the Google Groups "Chromium-Extensions-Announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.
To post to this group, send email to chromium-extensions@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/8c8289a2-4c6f-4f23-a484-56ac5fa7d60f%40chromium.org.