When call getAttribute, HTMLIFrame.sandbox has a bug which don't return changed value.

Source/core/html/HTMLIFrameElement.cpp

 /*
  * Copyright (C) 1999 Lars Knoll (knoll@kde.org)
  *           (C) 1999 Antti Koivisto (koivisto@kde.org)
  *           (C) 2000 Simon Hausmann (hausmann@kde.org)
  *           (C) 2001 Dirk Mueller (mueller@kde.org)
  * Copyright (C) 2004, 2006, 2008, 2009 Apple Inc. All rights reserved.
  * Copyright (C) 2009 Ericsson AB. All rights reserved.
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Library General Public
@@ skipping 145 matching lines @@
     HTMLFrameElementBase::removedFrom(insertionPoint);
     if (insertionPoint->inDocument() && document().isHTMLDocument() && !insertionPoint->isInShadowTree())
         toHTMLDocument(document()).removeExtraNamedItem(m_name);
 }
 
 bool HTMLIFrameElement::isInteractiveContent() const
 {
     return true;
 }
 
-void HTMLIFrameElement::valueChanged()
+void HTMLIFrameElement::valueChanged(DOMSettableTokenList* tokenList)
 {
-    String invalidTokens;
-    setSandboxFlags(m_sandbox->value().isNull() ? SandboxNone : parseSandboxPolicy(m_sandbox->tokens(), invalidTokens));
-    if (!invalidTokens.isNull())
-        document().addConsoleMessage(ConsoleMessage::create(OtherMessageSource, ErrorMessageLevel, "Error while parsing the 'sandbox' attribute: " + invalidTokens));
+    if (tokenList == m_sandbox) {

[Mike West, 2015/03/30 05:01:57]

When wouldn't this be true? Can you either `ASSERT_EQ(tokenList, m_sandbox)`, or
just drop the parameter entirely?

[hyunjunekim2, 2015/03/30 07:02:51]

If HTMLIFrameElement has two DOMSettableTokenList, we should distinguish whether
is sandbox or others about DOMSettableTokenList.

[Mike West, 2015/03/30 09:01:33]

But HTMLIFrameElement doesn't have two DOMSettableTokenLists, does it? If we
need this complexity in the future, we can add it. For now, it just makes this
code more complicated without adding any functionality or value.

For the moment, I'd prefer that you just make the one-line change you need in
order to fix the bug you've identified.

(And, speaking of which, please file a bug at `https://crbug.com/new`, and add
it to the CL description (`BUG=...`).)

[hyunjunekim2, 2015/03/30 09:16:22]

Ok, I'm wrong, It's also my mistake. After file a bug, I will request review.

+        String invalidTokens;
+        setSandboxFlags(m_sandbox->value().isNull() ? SandboxNone : parseSandboxPolicy(m_sandbox->tokens(), invalidTokens));
+        if (!invalidTokens.isNull())
+            document().addConsoleMessage(ConsoleMessage::create(OtherMessageSource, ErrorMessageLevel, "Error while parsing the 'sandbox' attribute: " + invalidTokens));
+        setSynchronizedLazyAttribute(sandboxAttr, m_sandbox->value());

[Mike West, 2015/03/30 05:01:57]

This line is the only actual change in the patch, right? The rest seems
irrelevant. Why add the complexity?

[hyunjunekim2, 2015/03/30 07:02:51]

I have a reason adding this one. Because it add this line to fix a bug.
<iframe id="if17" sandbox ="hi"/>
<script>
  if17.sandbox = "allow-script";
  if17.getAttribute("sandbox");
</script>
If you run this script, can't return "allow-script", maybe you should see "hi".
So, I think that the blink need this
line(setSynchronizedLazyAttribute(sandboxAttr, m_sandbox->value());) to update
element's attribute value.

+    }
 }
 
 }