Enable ThreadRestrictionVerifier for StringImpl

third_party/WebKit/Source/core/dom/Node.cpp

Index: third_party/WebKit/Source/core/dom/Node.cpp
diff --git a/third_party/WebKit/Source/core/dom/Node.cpp b/third_party/WebKit/Source/core/dom/Node.cpp
index caf5618827c3424f3f6e8939958d3761287ee1f4..4652e51fb7e32e6d4dc2438d7e8d80b9adc4afc9 100644
--- a/third_party/WebKit/Source/core/dom/Node.cpp
+++ b/third_party/WebKit/Source/core/dom/Node.cpp
@@ -1493,7 +1493,17 @@ String Node::debugName() const {
     const Element& thisElement = toElement(*this);
     if (thisElement.hasID()) {
       name.append(" id=\'");
-      name.append(thisElement.getIdAttribute());
+      // Unsafe hack to avoid triggering the ThreadRestrictionVerifier on
+      // StringImpl. crbug.com/545926 should be fixed completely, and we should
+      // always avoid accessing these strings from the impl thread. Currently
+      // code that calls into this method from the impl thread tries to make
+      // sure that the main thread is not running at this time.
+      StringImpl* impl = thisElement.getIdAttribute().impl();
+      if (impl) {
+        name.append(impl->is8Bit()
+                        ? StringView(impl->characters8(), impl->length())
+                        : StringView(impl->characters16(), impl->length()));

[esprehn, 2017/01/11 22:34:02]

Why do we need this but not below where we use AtomicString?

[Charlie Harrison, 2017/01/12 16:42:30]

I think we probably do and we're just not hitting that code path in tests.

+      }
       name.append('\'');
     }