Replicating WebFrame::uniqueName across renderers.

content/common/frame_replication_state.h

Index: content/common/frame_replication_state.h
diff --git a/content/common/frame_replication_state.h b/content/common/frame_replication_state.h
index 414bc3c130412e48dab34aeee29025e85600f9ef..ec56a76ca5aab3bac35b3cbcdf4547f3ca237723 100644
--- a/content/common/frame_replication_state.h
+++ b/content/common/frame_replication_state.h
@@ -21,6 +21,7 @@ struct CONTENT_EXPORT FrameReplicationState {
   FrameReplicationState();
   FrameReplicationState(blink::WebTreeScopeType scope,
                         const std::string& name,
+                        const std::string& unique_name,
                         blink::WebSandboxFlags sandbox_flags,
                         bool should_enforce_strict_mixed_content_checking);
   ~FrameReplicationState();
@@ -51,8 +52,7 @@ struct CONTENT_EXPORT FrameReplicationState {
   // frame.
   blink::WebSandboxFlags sandbox_flags;
 
-  // The assigned name of the frame. This name can be empty, unlike the unique

[Charlie Reis, 2016/01/27 23:48:49]

Why isn't this true anymore?

[Łukasz Anforowicz, 2016/01/28 01:21:19]

AFAICT it was never true.  If you look at FrameTree::setName, you see that for
main frame we simply assign |m_uniqueName = name|.  And the main frame initially
uses nullAtom as its name (i.e. see WebViewImpl::setMainFrame method).

[Charlie Reis, 2016/02/11 22:02:14]

Acknowledged.

-  // name generated internally in the DOM tree.
+  // The assigned name of the frame.
   //
   // |name| is set when a new child frame is created using the value of the
   // <iframe> element's "name" attribute (see
@@ -64,6 +64,10 @@ struct CONTENT_EXPORT FrameReplicationState {
   // frame using its updated name (e.g., using window.open(url, frame_name)).
   std::string name;
 
+  // Unique name of the frame.
+  // https://crbug.com/576969: This isn't really "unique" today.

[Charlie Reis, 2016/01/27 23:48:49]

I don't think it makes sense to document this here.  It'll likely just become a
stale comment once the bug is fixed.

[Łukasz Anforowicz, 2016/01/28 01:21:19]

Done.
Hmmm... should there be a tool that complains when there are crbug comments in
Chromium's source code that refer to bugs that have been marked as fixed?

[alexmos, 2016/02/10 00:46:45]

I don't think that's always undesirable.  For example, when I'm writing a test,
I often mention which bug it's for, and I think it's fine to refer to a fixed
bug in that case.

[Łukasz Anforowicz, 2016/02/10 22:10:50]

Acknowledged.  Maybe just pay attention to bugs on TODO lines?  I get 1081 bugs
with the cmdline below and some of them are stale (i.e. issue 8123):

$ git grep 'TODO.*crbug.com/[0-9]' | \
    sed -e 's:^.*crbug.com/\([0-9]\+\).*$:\1:g' | \
    sort | uniq

[Charlie Reis, 2016/02/11 22:02:14]

Yeah, I've wondered this myself sometimes.  Finding TODOs with closed bug
numbers could be useful.  What would you do with that data?  It seems more like
something to process in the background and email the author of the TODO (and/or
the person who closed the bug).

[Łukasz Anforowicz, 2016/02/11 23:23:55]

I thought that the bug could be marked with a label like "StaleTodo" and
commented with the location of the TODO.  The label should help avoid commenting
on the same bug twice.

This also sounds like something where a quick ad-hoc script would do a job more
or less fine, but where potentially a lot of effort is needed to do things the
right way (host the script somewhere, run it automatically, maintain
write-permissions for the script, make sure that this is actually useful and
that somebody follows-up on the marked bugs).  Maybe I should try to pitch the
idea on chromium-dev.

+  std::string unique_name;
+
   // Whether the frame is in a document tree or a shadow tree, per the Shadow
   // DOM spec: https://w3c.github.io/webcomponents/spec/shadow/
   // Note: This should really be const, as it can never change once a frame is