Revert of Fix webview preloading in zygote.

Revert of Fix webview preloading in zygote. (patchset #1 id:1 of https://codereview.chromium.org/2583913002/ )

Reason for revert:
Realised after the fact that we can't set the process type because the zygote may spawn renderers for Chrome.

Original issue's description:
> Fix webview preloading in zygote.
>
> We weren't setting the process type, which is fetched via JNI during
> JNI_OnLoad. Set it by constructing the LibraryLoader singleton, but
> don't actually call any methods of LibraryLoader, which need to be on
> the right thread, have a Context, have a CommandLine initialised, and
> other setup we can't (or at least, don't currently) do in the zygote.
>
> BUG=
>
> Committed: https://crrev.com/db6be0f685e774c56eef7d03a8ab19736023d8bb
> Cr-Commit-Position: refs/heads/master@{#439213}

TBR=rsesek@chromium.org,sgurun@chromium.org,torne@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=

Committed: https://crrev.com/8c4ee96c29f43c4169d3427961e6755fa945d97b
Cr-Commit-Position: refs/heads/master@{#439446}

[Tobias Sargeant, 2016-12-19 09:40:45]

The CQ bit was checked by tobiasjs@chromium.org

[Tobias Sargeant, 2016-12-19 09:40:45]

Created Revert of Fix webview preloading in zygote.

[commit-bot: I haz the power, 2016-12-19 09:41:01]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-19 10:13:07]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1482140445240010, "parent_rev":
"f73d31431a7e1fd7067c0eed3f50bc0d3aedc854", "commit_rev":
"ce58c21da670fdcd06a2c4b00dbd52e40efae36f"}

[commit-bot: I haz the power, 2016-12-19 10:13:32]

Description was changed from

==========
Revert of Fix webview preloading in zygote. (patchset #1 id:1 of
https://codereview.chromium.org/2583913002/ )

Reason for revert:
Realised after the fact that we can't set the process type because the zygote
may spawn renderers for Chrome.

Original issue's description:
> Fix webview preloading in zygote.
> 
> We weren't setting the process type, which is fetched via JNI during
> JNI_OnLoad. Set it by constructing the LibraryLoader singleton, but
> don't actually call any methods of LibraryLoader, which need to be on
> the right thread, have a Context, have a CommandLine initialised, and
> other setup we can't (or at least, don't currently) do in the zygote.
> 
> BUG=
> 
> Committed: https://crrev.com/db6be0f685e774c56eef7d03a8ab19736023d8bb
> Cr-Commit-Position: refs/heads/master@{#439213}

TBR=rsesek@chromium.org,sgurun@chromium.org,torne@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=
==========

to

==========
Revert of Fix webview preloading in zygote. (patchset #1 id:1 of
https://codereview.chromium.org/2583913002/ )

Reason for revert:
Realised after the fact that we can't set the process type because the zygote
may spawn renderers for Chrome.

Original issue's description:
> Fix webview preloading in zygote.
> 
> We weren't setting the process type, which is fetched via JNI during
> JNI_OnLoad. Set it by constructing the LibraryLoader singleton, but
> don't actually call any methods of LibraryLoader, which need to be on
> the right thread, have a Context, have a CommandLine initialised, and
> other setup we can't (or at least, don't currently) do in the zygote.
> 
> BUG=
> 
> Committed: https://crrev.com/db6be0f685e774c56eef7d03a8ab19736023d8bb
> Cr-Commit-Position: refs/heads/master@{#439213}

TBR=rsesek@chromium.org,sgurun@chromium.org,torne@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=

Review-Url: https://codereview.chromium.org/2586193002
==========

[commit-bot: I haz the power, 2016-12-19 10:13:33]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-12-19 10:15:45]

Description was changed from

==========
Revert of Fix webview preloading in zygote. (patchset #1 id:1 of
https://codereview.chromium.org/2583913002/ )

Reason for revert:
Realised after the fact that we can't set the process type because the zygote
may spawn renderers for Chrome.

Original issue's description:
> Fix webview preloading in zygote.
> 
> We weren't setting the process type, which is fetched via JNI during
> JNI_OnLoad. Set it by constructing the LibraryLoader singleton, but
> don't actually call any methods of LibraryLoader, which need to be on
> the right thread, have a Context, have a CommandLine initialised, and
> other setup we can't (or at least, don't currently) do in the zygote.
> 
> BUG=
> 
> Committed: https://crrev.com/db6be0f685e774c56eef7d03a8ab19736023d8bb
> Cr-Commit-Position: refs/heads/master@{#439213}

TBR=rsesek@chromium.org,sgurun@chromium.org,torne@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=

Review-Url: https://codereview.chromium.org/2586193002
==========

to

==========
Revert of Fix webview preloading in zygote. (patchset #1 id:1 of
https://codereview.chromium.org/2583913002/ )

Reason for revert:
Realised after the fact that we can't set the process type because the zygote
may spawn renderers for Chrome.

Original issue's description:
> Fix webview preloading in zygote.
>
> We weren't setting the process type, which is fetched via JNI during
> JNI_OnLoad. Set it by constructing the LibraryLoader singleton, but
> don't actually call any methods of LibraryLoader, which need to be on
> the right thread, have a Context, have a CommandLine initialised, and
> other setup we can't (or at least, don't currently) do in the zygote.
>
> BUG=
>
> Committed: https://crrev.com/db6be0f685e774c56eef7d03a8ab19736023d8bb
> Cr-Commit-Position: refs/heads/master@{#439213}

TBR=rsesek@chromium.org,sgurun@chromium.org,torne@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=

Committed: https://crrev.com/8c4ee96c29f43c4169d3427961e6755fa945d97b
Cr-Commit-Position: refs/heads/master@{#439446}
==========

[commit-bot: I haz the power, 2016-12-19 10:15:46]

Patchset 1 (id:??) landed as
https://crrev.com/8c4ee96c29f43c4169d3427961e6755fa945d97b
Cr-Commit-Position: refs/heads/master@{#439446}

[Robert Sesek, 2016-12-19 15:56:08]

What are the implications of having a WebView renderer preloaded as a Chrome
one, and vice versa? The zygote could end up forking either type, depending on
what the current WebView provider is.

[Tobias Sargeant, 2016-12-19 18:41:19]

On 2016/12/19 15:56:08, Robert Sesek wrote:
> What are the implications of having a WebView renderer preloaded as a Chrome
> one, and vice versa? The zygote could end up forking either type, depending on
> what the current WebView provider is.

At the end of OnJNIOnLoadInit we call content::SetContentMainDelegate with an
appropriate object. So for Monochrome we need to choose correctly what
MainDelegate to instantiate and set based upon who the caller is. Currently it's
based on what that LibraryProcesType is. Torne's CL probably broke starting
chrome from monochrome. Is there any way to know whether we're going to need a
chrome or a webview renderer?

Could we rely on the calling package being the same as the package the zygote
has loaded to determine this? And is it possible to get that information?

[Robert Sesek, 2016-12-19 21:22:22]

On 2016/12/19 18:41:19, Tobias Sargeant wrote:
> On 2016/12/19 15:56:08, Robert Sesek wrote:
> > What are the implications of having a WebView renderer preloaded as a Chrome
> > one, and vice versa? The zygote could end up forking either type, depending
on
> > what the current WebView provider is.
> 
> At the end of OnJNIOnLoadInit we call content::SetContentMainDelegate with an
> appropriate object. So for Monochrome we need to choose correctly what
> MainDelegate to instantiate and set based upon who the caller is. Currently
it's
> based on what that LibraryProcesType is. Torne's CL probably broke starting
> chrome from monochrome. Is there any way to know whether we're going to need a
> chrome or a webview renderer?
> 
> Could we rely on the calling package being the same as the package the zygote
> has loaded to determine this? And is it possible to get that information?

This is called in the zygote to preload the .so for all child processes. That
means it could end up forking WebView children or, if Monochrome is the current
provider, Chrome children.