Merge CWVWebsiteDataStore into CWVWebViewConfiguration.

Merge CWVWebsiteDataStore into CWVWebViewConfiguration.

BUG=700791
Review-Url: https://codereview.chromium.org/2747683002
Cr-Commit-Position: refs/heads/master@{#457388}
Committed: https://chromium.googlesource.com/chromium/src/+/7abaa4aa3e33391a1cf81ace5dc94bbb42ae507d

[Hiroshi Ichikawa, 2017-03-13 07:07:50]

ichikawa@chromium.org changed reviewers:
+ eugenebut@chromium.org, michaeldo@chromium.org

[michaeldo, 2017-03-13 14:54:02]

lgtm

Thanks!

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/internal/cwv_w...
File ios/web_view/internal/cwv_web_view_configuration.mm (right):

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/internal/cwv_w...
ios/web_view/internal/cwv_web_view_configuration.mm:32: configuration = [[self
alloc] initWithBrowserState:client->browser_state()];
Please use explicit class name here:

[CWVWebViewConfiguration alloc]

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/internal/cwv_w...
ios/web_view/internal/cwv_web_view_configuration.mm:43: configuration = [[self
alloc]
Please use explicit class name here:

[CWVWebViewConfiguration alloc]

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/public/cwv_web...
File ios/web_view/public/cwv_web_view_configuration.h (right):

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/public/cwv_web...
ios/web_view/public/cwv_web_view_configuration.h:15: // Configuration with
persistent data store which stores
Please re-wrap comments for these two static methods.

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/public/cwv_web...
ios/web_view/public/cwv_web_view_configuration.h:25: @property(readonly,
getter=isPersistent) BOOL persistent;
Please add comment.

[Eugene But (OOO till 7-30), 2017-03-13 21:17:02]

lgtm

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/internal/cwv_w...
File ios/web_view/internal/cwv_web_view_configuration.mm (right):

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/internal/cwv_w...
ios/web_view/internal/cwv_web_view_configuration.mm:27: static dispatch_once_t
once;
In WKWebView these these methods return new object every time they are called.
Is there a reason why you want them to be singletons? The downside of a
singleton is that you can't have 2 incognito web view. Upside is that cookies
will always be shared for all non-incognito web view. Also from the current
interface comments I would not expect to have singletons.

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/internal/cwv_w...
ios/web_view/internal/cwv_web_view_configuration.mm:32: configuration = [[self
alloc] initWithBrowserState:client->browser_state()];
On 2017/03/13 14:54:02, michaeldo wrote:
> Please use explicit class name here:
> 
> [CWVWebViewConfiguration alloc]
Why? self is better because it respects subclassing. Using
|CWVWebViewConfiguration| would totally defeat the purpose of }instancetype|
return type.

[michaeldo, 2017-03-13 21:27:58]

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/internal/cwv_w...
File ios/web_view/internal/cwv_web_view_configuration.mm (right):

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/internal/cwv_w...
ios/web_view/internal/cwv_web_view_configuration.mm:32: configuration = [[self
alloc] initWithBrowserState:client->browser_state()];
On 2017/03/13 21:17:01, Eugene But wrote:
> On 2017/03/13 14:54:02, michaeldo wrote:
> > Please use explicit class name here:
> > 
> > [CWVWebViewConfiguration alloc]
> Why? self is better because it respects subclassing. Using
> |CWVWebViewConfiguration| would totally defeat the purpose of }instancetype|
> return type.

That's true, |[self alloc]| is preferable. (I missed this example in the style
guide when I first looked.)

Please ignore my original request.

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/internal/cwv_w...
ios/web_view/internal/cwv_web_view_configuration.mm:43: configuration = [[self
alloc]
On 2017/03/13 14:54:02, michaeldo wrote:
> Please use explicit class name here:
> 
> [CWVWebViewConfiguration alloc]

Please ignore, correct as-is.

[Hiroshi Ichikawa, 2017-03-16 05:38:57]

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/internal/cwv_w...
File ios/web_view/internal/cwv_web_view_configuration.mm (right):

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/internal/cwv_w...
ios/web_view/internal/cwv_web_view_configuration.mm:27: static dispatch_once_t
once;
On 2017/03/13 21:17:01, Eugene But wrote:
> In WKWebView these these methods return new object every time they are called.
> Is there a reason why you want them to be singletons? The downside of a
> singleton is that you can't have 2 incognito web view. Upside is that cookies
> will always be shared for all non-incognito web view. Also from the current
> interface comments I would not expect to have singletons.

With the current implementation where WebViewMainParts owns BrowserState
instances, don't they share the cookies/storage/etc. even if this method returns
a new object? Are you suggesting to create a new BrowserState here (after we
resolve crbug.com/690182)?

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/public/cwv_web...
File ios/web_view/public/cwv_web_view_configuration.h (right):

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/public/cwv_web...
ios/web_view/public/cwv_web_view_configuration.h:15: // Configuration with
persistent data store which stores
On 2017/03/13 14:54:02, michaeldo wrote:
> Please re-wrap comments for these two static methods.

Done.

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/public/cwv_web...
ios/web_view/public/cwv_web_view_configuration.h:25: @property(readonly,
getter=isPersistent) BOOL persistent;
On 2017/03/13 14:54:02, michaeldo wrote:
> Please add comment.

Done.

[Hiroshi Ichikawa, 2017-03-16 05:39:32]

The CQ bit was checked by ichikawa@chromium.org

[commit-bot: I haz the power, 2017-03-16 05:39:49]

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, 2017-03-16 05:45:45]

The CQ bit was unchecked by commit-bot@chromium.org

[Hiroshi Ichikawa, 2017-03-16 05:45:45]

The CQ bit was unchecked by ichikawa@chromium.org

[commit-bot: I haz the power, 2017-03-16 05:45:46]

Try jobs failed on following builders:
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)

[Hiroshi Ichikawa, 2017-03-16 05:57:22]

The CQ bit was checked by ichikawa@chromium.org

[Hiroshi Ichikawa, 2017-03-16 05:57:23]

The patchset sent to the CQ was uploaded after l-g-t-m from
michaeldo@chromium.org, eugenebut@chromium.org
Link to the patchset: https://codereview.chromium.org/2747683002/#ps20001
(title: "Apply review comments, rebase and merge.")

[commit-bot: I haz the power, 2017-03-16 05:57:30]

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, 2017-03-16 06:29:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-16 06:29:38]

Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[Hiroshi Ichikawa, 2017-03-16 06:43:27]

The CQ bit was checked by ichikawa@chromium.org

[commit-bot: I haz the power, 2017-03-16 06:43:37]

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, 2017-03-16 07:19:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-16 07:19:18]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Hiroshi Ichikawa, 2017-03-16 07:35:31]

The CQ bit was checked by ichikawa@chromium.org

[commit-bot: I haz the power, 2017-03-16 07:35:45]

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, 2017-03-16 08:58:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-16 08:58:54]

Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Hiroshi Ichikawa, 2017-03-16 09:08:06]

The CQ bit was checked by ichikawa@chromium.org

[commit-bot: I haz the power, 2017-03-16 09:08:24]

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, 2017-03-16 10:03:24]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1489655286411030,
"parent_rev": "5b5c309859412def817a518a7dddbf413cd892e9", "commit_rev":
"7abaa4aa3e33391a1cf81ace5dc94bbb42ae507d"}

[commit-bot: I haz the power, 2017-03-16 10:04:07]

Description was changed from

==========
Merge CWVWebsiteDataStore into CWVWebViewConfiguration.

BUG=
==========

to

==========
Merge CWVWebsiteDataStore into CWVWebViewConfiguration.

BUG=

Review-Url: https://codereview.chromium.org/2747683002
Cr-Commit-Position: refs/heads/master@{#457388}
Committed:
https://chromium.googlesource.com/chromium/src/+/7abaa4aa3e33391a1cf81ace5dc9...
==========

[commit-bot: I haz the power, 2017-03-16 10:04:09]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/7abaa4aa3e33391a1cf81ace5dc9...

[Eugene But (OOO till 7-30), 2017-03-16 16:45:25]

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/internal/cwv_w...
File ios/web_view/internal/cwv_web_view_configuration.mm (right):

https://codereview.chromium.org/2747683002/diff/1/ios/web_view/internal/cwv_w...
ios/web_view/internal/cwv_web_view_configuration.mm:27: static dispatch_once_t
once;
On 2017/03/16 05:38:57, Hiroshi Ichikawa wrote:
> On 2017/03/13 21:17:01, Eugene But wrote:
> > In WKWebView these these methods return new object every time they are
called.
> > Is there a reason why you want them to be singletons? The downside of a
> > singleton is that you can't have 2 incognito web view. Upside is that
cookies
> > will always be shared for all non-incognito web view. Also from the current
> > interface comments I would not expect to have singletons.
> 
> With the current implementation where WebViewMainParts owns BrowserState
> instances, don't they share the cookies/storage/etc. even if this method
returns
> a new object? Are you suggesting to create a new BrowserState here (after we
> resolve crbug.com/690182)?
Yes, the suggestion is to create a new BrowserState for each
WebViewConfiguration. If you want to have these API return singletons, then
could you please update the comments to explicitly state that the result is a
singleton. Otherwise could you please add a TODO to return a new object every
time this method is called.

[Hiroshi Ichikawa, 2017-03-17 04:37:11]

On 2017/03/16 16:45:25, Eugene But wrote:
>
https://codereview.chromium.org/2747683002/diff/1/ios/web_view/internal/cwv_w...
> File ios/web_view/internal/cwv_web_view_configuration.mm (right):
> 
>
https://codereview.chromium.org/2747683002/diff/1/ios/web_view/internal/cwv_w...
> ios/web_view/internal/cwv_web_view_configuration.mm:27: static dispatch_once_t
> once;
> On 2017/03/16 05:38:57, Hiroshi Ichikawa wrote:
> > On 2017/03/13 21:17:01, Eugene But wrote:
> > > In WKWebView these these methods return new object every time they are
> called.
> > > Is there a reason why you want them to be singletons? The downside of a
> > > singleton is that you can't have 2 incognito web view. Upside is that
> cookies
> > > will always be shared for all non-incognito web view. Also from the
current
> > > interface comments I would not expect to have singletons.
> > 
> > With the current implementation where WebViewMainParts owns BrowserState
> > instances, don't they share the cookies/storage/etc. even if this method
> returns
> > a new object? Are you suggesting to create a new BrowserState here (after we
> > resolve crbug.com/690182)?
> Yes, the suggestion is to create a new BrowserState for each
> WebViewConfiguration. If you want to have these API return singletons, then
> could you please update the comments to explicitly state that the result is a
> singleton. Otherwise could you please add a TODO to return a new object every
> time this method is called.

I see, makes sense. Will create an issue for it since this CL has already been
submitted.

[Hiroshi Ichikawa, 2017-03-22 08:13:45]

Description was changed from

==========
Merge CWVWebsiteDataStore into CWVWebViewConfiguration.

BUG=

Review-Url: https://codereview.chromium.org/2747683002
Cr-Commit-Position: refs/heads/master@{#457388}
Committed:
https://chromium.googlesource.com/chromium/src/+/7abaa4aa3e33391a1cf81ace5dc9...
==========

to

==========
Merge CWVWebsiteDataStore into CWVWebViewConfiguration.

BUG=700791

Review-Url: https://codereview.chromium.org/2747683002
Cr-Commit-Position: refs/heads/master@{#457388}
Committed:
https://chromium.googlesource.com/chromium/src/+/7abaa4aa3e33391a1cf81ace5dc9...
==========