Ensure that FrameLoadTypeBackForward only occurs once per navigation.

Ensure that FrameLoadTypeBackForward only occurs once per navigation.

With this change, TypeBackForward will only occur once at the top level navigation, and sub-frames that are created along the way will get TypeInitialInChildFrame.

BUG=416184
TEST=as in bug

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=183556

[Avi (use Gerrit), 2014-10-08 15:54:53]

avi@chromium.org changed reviewers:
+ creis@chromium.org, japhet@chromium.org

[Avi (use Gerrit), 2014-10-08 15:54:54]

Charlie: FYI

Nate: This is how I was thinking of trying out your idea. Do you have a testcase
for that horrible scenario you were talking about where sibling iframes both
navigate simultaneously on a history nav?

[Nate Chapin, 2014-10-08 17:01:39]

On 2014/10/08 15:54:54, Avi wrote:
> Charlie: FYI
> 
> Nate: This is how I was thinking of trying out your idea. Do you have a
testcase
> for that horrible scenario you were talking about where sibling iframes both
> navigate simultaneously on a history nav?

If you want to test in blink rather than in chromium, you can only test the
FrameLoadType artifact, not the mangling of the history state. I think that may
be the better option in general, as getting the right ordering to tickle this
case is fairly difficult to de-flake.

The sequence for such a WebFrameTest would be:
* Load a dummy document, give it a WebFrameClient that overrides
createChildFrame().
* Manufacture a WebHistoryItem and call WebFrame::loadHistoryItem() for the main
frame, which loads a page with an iframe.
* When the child frame is created, the overridden createChildFrame() will be
called. This should provide the new child frame with a WebFrameClient that
overrides didCommitProvisionalLoad() and verifies the WebHistoryCommitType.

See TestCachePolicyWebFrameClient and WebFrameTest.ReloadIframe for an example
of instrument a child frame like this.

[Avi (use Gerrit), 2014-10-08 17:43:18]

On 2014/10/08 17:01:39, Nate Chapin wrote:
> On 2014/10/08 15:54:54, Avi wrote:
> > Charlie: FYI
> > 
> > Nate: This is how I was thinking of trying out your idea. Do you have a
> testcase
> > for that horrible scenario you were talking about where sibling iframes both
> > navigate simultaneously on a history nav?
> 
> If you want to test in blink rather than in chromium, you can only test the
> FrameLoadType artifact, not the mangling of the history state. I think that
may
> be the better option in general, as getting the right ordering to tickle this
> case is fairly difficult to de-flake.
> 
> The sequence for such a WebFrameTest would be:
> * Load a dummy document, give it a WebFrameClient that overrides
> createChildFrame().
> * Manufacture a WebHistoryItem and call WebFrame::loadHistoryItem() for the
main
> frame, which loads a page with an iframe.
> * When the child frame is created, the overridden createChildFrame() will be
> called. This should provide the new child frame with a WebFrameClient that
> overrides didCommitProvisionalLoad() and verifies the WebHistoryCommitType.
> 
> See TestCachePolicyWebFrameClient and WebFrameTest.ReloadIframe for an example
> of instrument a child frame like this.

I was looking more towards something I could load, just so that I could see how
it behaved. Already this is killing tests, so I need to see what's up there.

[Avi (use Gerrit), 2014-10-10 18:35:58]

Nate, this version seems to work.

[Nate Chapin, 2014-10-10 18:38:49]

LGTM

Thanks for sticking with this!

[Avi (use Gerrit), 2014-10-10 18:40:41]

The CQ bit was checked by avi@chromium.org

[commit-bot: I haz the power, 2014-10-10 18:41:32]

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

[commit-bot: I haz the power, 2014-10-10 21:44:36]

Committed patchset #4 (id:160001) as 183556