Improve page transition type heuristic in WebController

Improve page transition type heuristic in WebController

When guessing the tranistion type for a URL change:
- When possible, use specific information from the last main frame load
  request.
- Fall back to guessing based on whether there has been a touch since
  the last URL change, rather than the last document change. This
  prevents changes that happen after, e.g., a replaceState from being
  assumed to be user-initiated.

BUG=548636
TEST=On an iPhone with WKWebView enabled, follow a link on
yahoo.com, then go back via the browser back button. It should return
to the main page.

Committed: https://crrev.com/b86705bd3233afdc06ed9079b6f434e7f8180376
Cr-Commit-Position: refs/heads/master@{#357157}

[stuartmorgan, 2015-10-29 21:52:23]

Description was changed from

==========
Improve page transition type heuristic in WebController

When guessing the tranistion type for a URL change:
- When possible, use specific information from the last main frame load
  request.
- Fall back to guessing based on whether there has been a touch since
  the last URL change, rather than the last document change. This
  prevents changes that happen after, e.g., a replaceState from being
  assumed to be user-initiated.

BUG=548636
==========

to

==========
Improve page transition type heuristic in WebController

When guessing the tranistion type for a URL change:
- When possible, use specific information from the last main frame load
  request.
- Fall back to guessing based on whether there has been a touch since
  the last URL change, rather than the last document change. This
  prevents changes that happen after, e.g., a replaceState from being
  assumed to be user-initiated.

BUG=548636
TEST=On an iPhone with WKWebView enabled, follow a link on
yahoo.com, then go back via the browser back button. It should return
to the main page.
==========

[stuartmorgan, 2015-10-29 21:53:39]

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

[stuartmorgan, 2015-10-29 21:53:40]

Only the second change is necessary to fix the issue, but since the transition
from WKWebView is now readily available (when it's set at all), and I was
changing the code anyway, it seemed like a good time to improve the accuracy in
general.

[Eugene But (OOO till 7-30), 2015-10-30 15:10:47]

https://codereview.chromium.org/1409033004/diff/1/ios/web/web_state/ui/crw_wk...
File ios/web/web_state/ui/crw_wk_web_view_web_controller.mm (right):

https://codereview.chromium.org/1409033004/diff/1/ios/web/web_state/ui/crw_wk...
ios/web/web_state/ui/crw_wk_web_view_web_controller.mm:1261:
_touchedSinceLastURLChange = NO;
This is not the only place where _documentURL is changed. How about adding
- (void)setDocumentURL: (const GURL&)newURL {
  if (_documentURL != newURL) {
    _documentURL = newURL;
    _touchedSinceLastURLChange = NO;
  }
}

and calling it everywhere instead of assigning value to ivar?

[stuartmorgan, 2015-10-30 16:00:01]

https://codereview.chromium.org/1409033004/diff/1/ios/web/web_state/ui/crw_wk...
File ios/web/web_state/ui/crw_wk_web_view_web_controller.mm (right):

https://codereview.chromium.org/1409033004/diff/1/ios/web/web_state/ui/crw_wk...
ios/web/web_state/ui/crw_wk_web_view_web_controller.mm:1261:
_touchedSinceLastURLChange = NO;
On 2015/10/30 15:10:47, eugenebut wrote:
> This is not the only place where _documentURL is changed. How about adding
> - (void)setDocumentURL: (const GURL&)newURL {
>   if (_documentURL != newURL) {
>     _documentURL = newURL;
>     _touchedSinceLastURLChange = NO;
>   }
> }
> 
> and calling it everywhere instead of assigning value to ivar?

Originally I didn't do that because of the async code in URL change detection
below, but on further consideration keeping the relative ordering makes sense,
and this is a less fragile approach. Done.

[Eugene But (OOO till 7-30), 2015-10-30 16:04:01]

lgtm!

[stuartmorgan, 2015-10-30 16:52:25]

The CQ bit was checked by stuartmorgan@chromium.org

[commit-bot: I haz the power, 2015-10-30 16:53:10]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1409033004/10001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1409033004/10001

[commit-bot: I haz the power, 2015-10-30 16:54:44]

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

[commit-bot: I haz the power, 2015-10-30 16:54:45]

Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[stuartmorgan, 2015-10-30 16:59:42]

The CQ bit was checked by stuartmorgan@chromium.org

[stuartmorgan, 2015-10-30 16:59: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/1409033004/#ps30001
(title: "Rebase")

[commit-bot: I haz the power, 2015-10-30 17:00:58]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1409033004/30001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1409033004/30001

[commit-bot: I haz the power, 2015-10-30 18:49:10]

Committed patchset #3 (id:30001)

[commit-bot: I haz the power, 2015-10-30 18:50:11]

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