Upstream most of the iOS WebUI support in ios/web/

Upstream most of the iOS WebUI support in ios/web/

This upstreams the bulk of the code necessary to support WebUI in the
iOS web layer. Much of this is forked off of the content/ versions,
which can't be used on iOS.

BUG=464810
Committed: https://crrev.com/f0e19f918f0d1e183d2ee35fdaca3b191e36c19b
Cr-Commit-Position: refs/heads/master@{#327441}

[stuartmorgan, 2015-04-28 18:44:15]

stuartmorgan@chromium.org changed reviewers:
+ eugenebut@chromium.org, thakis@chromium.org

[stuartmorgan, 2015-04-28 18:44:15]

eugenebut for the main review
thakis for the ui_base.gyp change
jyquinn FYI

[Nico, 2015-04-28 18:45:51]

ui_base.gyp lgtm (I guess you don't care about .gn files yet)

Someone from content/OWNERS should probably look too if you're copying a bunch
from there more or less.

[stuartmorgan, 2015-04-28 20:06:20]

stuartmorgan@chromium.org changed reviewers:
+ jam@chromium.org

[stuartmorgan, 2015-04-28 20:06:21]

+jam, per Nico's comment.

I think blundell may have discussed this with you at the time; to remove our
dependency on the content/ WebUI infrastructure, we cloned portions of it.
Nothing was particularly complex, so it seemed reasonable.

Let me know if you have any concerns.

[Eugene But (OOO till 7-30), 2015-04-28 20:23:01]

lgtm

https://codereview.chromium.org/1110213002/diff/1/ios/public/provider/web/web...
File ios/public/provider/web/web_ui_ios.h (right):

https://codereview.chromium.org/1110213002/diff/1/ios/public/provider/web/web...
ios/public/provider/web/web_ui_ios.h:38: 
NIT: Do you need comments for these?

https://codereview.chromium.org/1110213002/diff/1/ios/web/public/web_ui_ios_d...
File ios/web/public/web_ui_ios_data_source.h (right):

https://codereview.chromium.org/1110213002/diff/1/ios/web/public/web_ui_ios_d...
ios/web/public/web_ui_ios_data_source.h:25: 
ditto

https://codereview.chromium.org/1110213002/diff/1/ios/web/webui/url_data_mana...
File ios/web/webui/url_data_manager_ios_backend.cc (right):

https://codereview.chromium.org/1110213002/diff/1/ios/web/webui/url_data_mana...
ios/web/webui/url_data_manager_ios_backend.cc:70: // Parse |url| to get the path
which will be used to resolve the request. The
NIT: s/Parse/Parses

https://codereview.chromium.org/1110213002/diff/1/ios/web/webui/url_data_sour...
File ios/web/webui/url_data_source_ios.cc (right):

https://codereview.chromium.org/1110213002/diff/1/ios/web/webui/url_data_sour...
ios/web/webui/url_data_source_ios.cc:36: if
(GetWebClient()->IsAppSpecificURL(request->url()))
NIT:

return GetWebClient()->IsAppSpecificURL(request->url());

https://codereview.chromium.org/1110213002/diff/1/ios/web/webui/web_ui_ios_co...
File ios/web/webui/web_ui_ios_controller_factory_registry.cc (right):

https://codereview.chromium.org/1110213002/diff/1/ios/web/webui/web_ui_ios_co...
ios/web/webui/web_ui_ios_controller_factory_registry.cc:13:
base::LazyInstance<std::vector<WebUIIOSControllerFactory*> > g_factories =
NIT: no need for space between '>'

[jam, 2015-04-29 00:42:14]

On 2015/04/28 20:06:21, stuartmorgan wrote:
> +jam, per Nico's comment.
> 
> I think blundell may have discussed this with you at the time; to remove our
> dependency on the content/ WebUI infrastructure, we cloned portions of it.
> Nothing was particularly complex, so it seemed reasonable.
> 
> Let me know if you have any concerns.

ok for now.

 do you expect to have webui implementations in src/chrome that are used on both
ios and non-ios? i.e. will we need to make those be layered components? if so, i
wonder if it'd be easier to make this webui code be a component, since per the
cr-dev thread content can now depend on components.

[stuartmorgan, 2015-04-29 01:57:28]

On 2015/04/29 00:42:14, jam wrote:
>  do you expect to have webui implementations in src/chrome that are used on
both
> ios and non-ios? i.e. will we need to make those be layered components? if so,
i
> wonder if it'd be easier to make this webui code be a component, since per the
> cr-dev thread content can now depend on components.

Pretty much all of the iOS WebUI is shared (since anything iOS-only is much
easier to write natively, due to the limitations in the webview); things like
the sync internals page are examples. I think they will often be parts of things
we are componentizing anyway, but it's possible we'll want to extract specific
components for some WebUI bits.

I was thinking about the longer-term possibility of a component for this code
today as well (obviously the creation of this predates that, even though the
upstreaming is happening now). My understanding is that right now the change in
policy is specific to things shared with html_viewer, but if that works out well
in practice maybe we can revisit some areas of content/web overlap and see if we
want to extend the policy to allow sharing for that purpose as well.

The good news is that by getting this upstreamed, when we come back to that
question it'll be much easier for everyone involved to see the specifics of what
can be shared than it has been in the past :)

[stuartmorgan, 2015-04-29 01:57:50]

The CQ bit was checked by stuartmorgan@chromium.org

[commit-bot: I haz the power, 2015-04-29 01:58:57]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1110213002/1

[jam, 2015-04-29 04:04:07]

On 2015/04/29 01:57:28, stuartmorgan wrote:
> On 2015/04/29 00:42:14, jam wrote:
> >  do you expect to have webui implementations in src/chrome that are used on
> both
> > ios and non-ios? i.e. will we need to make those be layered components? if
so,
> i
> > wonder if it'd be easier to make this webui code be a component, since per
the
> > cr-dev thread content can now depend on components.
> 
> Pretty much all of the iOS WebUI is shared (since anything iOS-only is much
> easier to write natively, due to the limitations in the webview); things like
> the sync internals page are examples. I think they will often be parts of
things
> we are componentizing anyway, but it's possible we'll want to extract specific
> components for some WebUI bits.
> 
> I was thinking about the longer-term possibility of a component for this code
> today as well (obviously the creation of this predates that, even though the
> upstreaming is happening now). My understanding is that right now the change
in
> policy is specific to things shared with html_viewer, but if that works out
well
> in practice maybe we can revisit some areas of content/web overlap and see if
we
> want to extend the policy to allow sharing for that purpose as well.

Yep agreed; now that we're sharing code with content/html_viewer, I think it
makes sense to do so for webui (and maybe other things with ios too, we'll need
to examine each piece one-by-one).

> 
> The good news is that by getting this upstreamed, when we come back to that
> question it'll be much easier for everyone involved to see the specifics of
what
> can be shared than it has been in the past :)

sgtm

[commit-bot: I haz the power, 2015-04-29 06:01:28]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-04-29 06:03:04]

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