Main frame's unique name can always be null.

content/browser/frame_host/frame_tree_node.cc

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/browser/frame_host/frame_tree_node.h"
 
 #include <queue>
 #include <utility>
 
 #include "base/macros.h"
@@ skipping 214 matching lines @@
       is_potentially_trustworthy_unique_origin;
 }
 
 void FrameTreeNode::SetFrameName(const std::string& name,
                                  const std::string& unique_name) {
   if (name == replication_state_.name) {
     // |unique_name| shouldn't change unless |name| changes.
     DCHECK_EQ(unique_name, replication_state_.unique_name);
     return;
   }
+
+  if (parent()) {
+    // Non-main frames should have a non-empty unique name.
+    DCHECK(!unique_name.empty());
+  } else {
+    // Unique name of main frames should always stay empty.
+    DCHECK(unique_name.empty());

[Charlie Reis, 2016/09/15 20:04:12]

This is in response to an IPC, right?  Should we enforce this in any way for
release builds, like clearing the unique_name if it isn't empty for a main
frame?

[Łukasz Anforowicz, 2016/09/15 20:55:13]

Usually yes, but not necessarily.  For example - a non-IPC call can be made from
the place I had to fix-up in WebContentsImpl::Init.
I am not sure.  I think doing this for emptiness of main frame is not needed:

1. Browser should not look at the unique name of the main frame.

2. Old code worked fine when unique name might have been non-empty.

3. The DCHECKs I've added are mainly to help me^H^H^H future maintainers avoid
the mistake I've made in patchset #1 (where I've modified the unique name format
in Blink, but forgot about this one place in browser-side).


I guess some browser-side validation might still be desirable - most importantly
to make sure the unique names are truly unique (AFAIR we had a security bug
where duplicate unique names where one part of a bigger repro/puzzle).  Still -
even non-malicious renderers can hit a race and generate a non-unique name, so I
don't see how to do the enforcement here (we can't kill a renderer, but there is
no clear fallback).

+  }
+
   RecordUniqueNameLength(unique_name.size());
   render_manager_.OnDidUpdateName(name, unique_name);
   replication_state_.name = name;
   replication_state_.unique_name = unique_name;
 }
 
 void FrameTreeNode::AddContentSecurityPolicy(
     const ContentSecurityPolicyHeader& header) {
   replication_state_.accumulated_csp_headers.push_back(header);
   render_manager_.OnDidAddContentSecurityPolicy(header);
@@ skipping 249 matching lines @@
       }
       return parent_->child_at(i + relative_offset);
     }
   }
 
   NOTREACHED() << "FrameTreeNode not found in its parent's children.";
   return nullptr;
 }
 
 }  // namespace content