Remove RequestTracker from WebStateImpl.

Remove RequestTracker from WebStateImpl.

The RequestTracker only works with UIWebView but every code using
WebState uses WKWebView, so remove the RequestTracker from the
WebState.

The reason the RequestTracker does not work with WKWebView is that
it used to intercept the network request via NSURLProtocol (which
is not supported by WKWebView) and to put an identifier in the
User-Agent used to find the RequestTracker associated with the
request (and any sub-resources).

With WKWebView, the only events sent to the RequestTracker that was
associated with the WebState came from CRWWebController (i.e. page
load started and finished, history changed) via the WebState itself.
No request for sub-resources is ever caught (as User-Agent is not
overridden) thus they are not associated with the RequestTracker and
do not cause change to the state machine.

BUG=575800
Review-Url: https://codereview.chromium.org/2644103004
Cr-Commit-Position: refs/heads/master@{#445045}
Committed: https://chromium.googlesource.com/chromium/src/+/79fd9eab61da2ac2bb5261b460ed9f5afb6d4228

[sdefresne, 2017-01-19 18:51:08]

The CQ bit was checked by sdefresne@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-19 18:51:33]

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

[sdefresne, 2017-01-19 18:55:23]

sdefresne@chromium.org changed reviewers:
+ eugenebut@chromium.org

[sdefresne, 2017-01-19 18:55:24]

Please take a look.

I'm not so sure about this one as some callbacks may no longer invoked
(-updatedSSLStatus:forPageUrl:userInfo: called from SSLNotify). I think it was
never invoked as counts_ only ever contained one item (since there
RequestTracker is not tracking sub-requests with WKWebView) but I have not
traced all the code path exhaustively (as I'm working on my laptop today, I'll
look deeper once I have access to my beefier desktop).

[commit-bot: I haz the power, 2017-01-19 19:03:03]

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

[commit-bot: I haz the power, 2017-01-19 19:03:04]

Dry run: This issue passed the CQ dry run.

[Eugene But (OOO till 7-30), 2017-01-19 19:05:55]

Everything looks safe to me. Thank you for cleanup! lgtm

https://codereview.chromium.org/2644103004/diff/1/ios/web/web_state/ui/crw_we...
File ios/web/web_state/ui/crw_web_controller.mm (right):

https://codereview.chromium.org/2644103004/diff/1/ios/web/web_state/ui/crw_we...
ios/web/web_state/ui/crw_web_controller.mm:52: #import
"ios/web/net/request_group_util.h"
nit: Do we still need this include?

https://codereview.chromium.org/2644103004/diff/1/ios/web/web_state/web_state...
File ios/web/web_state/web_state_impl.h (right):

https://codereview.chromium.org/2644103004/diff/1/ios/web/web_state/web_state...
ios/web/web_state/web_state_impl.h:22: #import
"ios/web/net/request_tracker_impl.h"
nit: Do we still need this include?

https://codereview.chromium.org/2644103004/diff/1/ios/web/webui/crw_web_ui_ma...
File ios/web/webui/crw_web_ui_manager.mm (right):

https://codereview.chromium.org/2644103004/diff/1/ios/web/webui/crw_web_ui_ma...
ios/web/webui/crw_web_ui_manager.mm:20: #import
"ios/web/net/request_group_util.h"
nit: Do we still need this include?

[sdefresne, 2017-01-20 11:31:28]

Thank you for the review.

I double checked and counts_ of RequestTracker is only filled when
RequestTrackerImpl::StartRequest() is invoked which never happens for the
RequestTracker associated with WebStateImpl (as this method is only called from
the NSURLProtocol instance).

With counts_ always empty, the code invoked in RequestTrackerImpl from
WebStateImpl is doing nothing (no callback is invoked, in particular nothing
related to SLL is ever invoked as RequestTrackerImpl::SSLNotify early returns if
counts_ is empty).

I think it is safe to land this CL.

https://codereview.chromium.org/2644103004/diff/1/ios/web/web_state/ui/crw_we...
File ios/web/web_state/ui/crw_web_controller.mm (right):

https://codereview.chromium.org/2644103004/diff/1/ios/web/web_state/ui/crw_we...
ios/web/web_state/ui/crw_web_controller.mm:52: #import
"ios/web/net/request_group_util.h"
On 2017/01/19 19:05:54, Eugene But wrote:
> nit: Do we still need this include?

Removed.

https://codereview.chromium.org/2644103004/diff/1/ios/web/web_state/web_state...
File ios/web/web_state/web_state_impl.h (right):

https://codereview.chromium.org/2644103004/diff/1/ios/web/web_state/web_state...
ios/web/web_state/web_state_impl.h:22: #import
"ios/web/net/request_tracker_impl.h"
On 2017/01/19 19:05:55, Eugene But wrote:
> nit: Do we still need this include?

Removed.

https://codereview.chromium.org/2644103004/diff/1/ios/web/webui/crw_web_ui_ma...
File ios/web/webui/crw_web_ui_manager.mm (right):

https://codereview.chromium.org/2644103004/diff/1/ios/web/webui/crw_web_ui_ma...
ios/web/webui/crw_web_ui_manager.mm:20: #import
"ios/web/net/request_group_util.h"
On 2017/01/19 19:05:55, Eugene But wrote:
> nit: Do we still need this include?

Removed.

[sdefresne, 2017-01-20 12:05:41]

The CQ bit was checked by sdefresne@chromium.org to run a CQ dry run

[sdefresne, 2017-01-20 12:05:42]

The CQ bit was checked by sdefresne@chromium.org

[sdefresne, 2017-01-20 12:05:43]

The patchset sent to the CQ was uploaded after l-g-t-m from
eugenebut@chromium.org
Link to the patchset: https://codereview.chromium.org/2644103004/#ps20001
(title: "Remove obsolete #include add missing ones.")

[commit-bot: I haz the power, 2017-01-20 12:05:56]

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-01-20 12:07:25]

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

[commit-bot: I haz the power, 2017-01-20 12:07:26]

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

[sdefresne, 2017-01-20 12:24:24]

The CQ bit was checked by sdefresne@chromium.org

[sdefresne, 2017-01-20 12:24:24]

The patchset sent to the CQ was uploaded after l-g-t-m from
eugenebut@chromium.org
Link to the patchset: https://codereview.chromium.org/2644103004/#ps40001
(title: "Rebase.")

[commit-bot: I haz the power, 2017-01-20 12:24: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-01-20 12:37:21]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1484915064055040,
"parent_rev": "7c2c89232e5e825cf265513071566133b94bfb61", "commit_rev":
"79fd9eab61da2ac2bb5261b460ed9f5afb6d4228"}

[commit-bot: I haz the power, 2017-01-20 12:37:53]

Description was changed from

==========
Remove RequestTracker from WebStateImpl.

The RequestTracker only works with UIWebView but every code using
WebState uses WKWebView, so remove the RequestTracker from the
WebState.

The reason the RequestTracker does not work with WKWebView is that
it used to intercept the network request via NSURLProtocol (which
is not supported by WKWebView) and to put an identifier in the
User-Agent used to find the RequestTracker associated with the
request (and any sub-resources).

With WKWebView, the only events sent to the RequestTracker that was
associated with the WebState came from CRWWebController (i.e. page
load started and finished, history changed) via the WebState itself.
No request for sub-resources is ever caught (as User-Agent is not
overridden) thus they are not associated with the RequestTracker and
do not cause change to the state machine.

BUG=575800
==========

to

==========
Remove RequestTracker from WebStateImpl.

The RequestTracker only works with UIWebView but every code using
WebState uses WKWebView, so remove the RequestTracker from the
WebState.

The reason the RequestTracker does not work with WKWebView is that
it used to intercept the network request via NSURLProtocol (which
is not supported by WKWebView) and to put an identifier in the
User-Agent used to find the RequestTracker associated with the
request (and any sub-resources).

With WKWebView, the only events sent to the RequestTracker that was
associated with the WebState came from CRWWebController (i.e. page
load started and finished, history changed) via the WebState itself.
No request for sub-resources is ever caught (as User-Agent is not
overridden) thus they are not associated with the RequestTracker and
do not cause change to the state machine.

BUG=575800

Review-Url: https://codereview.chromium.org/2644103004
Cr-Commit-Position: refs/heads/master@{#445045}
Committed:
https://chromium.googlesource.com/chromium/src/+/79fd9eab61da2ac2bb5261b460ed...
==========

[commit-bot: I haz the power, 2017-01-20 12:37:56]

Committed patchset #3 (id:40001) as
https://chromium.googlesource.com/chromium/src/+/79fd9eab61da2ac2bb5261b460ed...