Use the single argument overload of WebFrame::create().

Use the single argument overload of WebFrame::create().

As of r252664, we no longer depend on storing the frame ID in Blink,
so we can simply use the one-argument version of WebFrame::create()
and delete the two argument overload once this lands.

BUG=314791
R=creis@chromium.org
TBR=bauerb@chromium.org, boliu@chromium.org, vitalybuka@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=252831

[Charlie Reis, 2014-02-21 23:47:25]

Hmm, it seems risky to me to change back to that signature before changing the
code in Blink.  I think I removed all the external callers of
WebFrame::identifier(), but you said the ID can leak through in places like
history items.  If we set that value using generateEmbedderIdentifier() rather
than the routing ID, I'm concerned it will lead to bugs.

Wouldn't it be safer to change Blink to remove the internal uses of the frame ID
first (and make the two create signatures do the same thing), then land this?

[Charlie Reis, 2014-02-22 00:26:10]

Ok, we discussed this in person.

I was concerned that as soon as Blink's internal frame ID and RenderFrame's
routing ID started to diverge, we might see bugs.  I was thinking that we were
going to remove Blink's internal frame ID entirely, at which point this change
would be a no-op.

That assumption wasn't correct.  Your Blink CL is going to keep the internal
frame ID and have it diverge from routing IDs anyway, so starting to do that in
this CL won't matter.  We think that is likely to be safe for the reasons below.

The internal frame ID is only used in HistoryItem, and while that does get
exposed to content/ via WebHistoryItem, it's only used for serialization and
deserialization.  It looks like no one else is touching it and comparing it to
routing IDs.  Thus, we have good reason to think this should be safe.

(Side note: I would love to eliminate HistoryItem's targetFrameID when we move
it to the browser process, replacing it with a FrameTreeNode ID if necessary. 
We shouldn't make any assumptions about it continuing to be unique across
browser sessions.)

So, given all that, this CL LGTM.

[dcheng, 2014-02-23 00:22:54]

I figured out how to prevent these inconsistency issues. I modified the
Blink-side patch to simply ignore the sequence number that's passed in, so it
consistently uses its own sequence numbers inside WebCore. Now, since there's no
chance of a collision between how WebCore and content choose to assign frame
IDs, we can safely land this change. I'll TBR the remaining reviewers since this
is a trivial change to move away from a deprecated blink API.

[dcheng, 2014-02-23 00:22:54]

I figured out how to prevent these inconsistency issues. I modified the
Blink-side patch to simply ignore the sequence number that's passed in, so it
consistently uses its own sequence numbers inside WebCore. Now, since there's no
chance of a collision between how WebCore and content choose to assign frame
IDs, we can safely land this change. I'll TBR the remaining reviewers since this
is a trivial change to move away from a deprecated blink API.

[dcheng, 2014-02-23 00:23:55]

Committed patchset #1 manually as r252831 (presubmit successful).