Introduce a lifecycle model to WindowProxy

Introduce a lifecycle model to WindowProxy

This CL intorduces the following lifecycle model to WindowProxy:

  ContextUninitialized => ContextInitialized => ContextDetached

This clarifies the lifecycle and enables us to insert dchecks to detect
invalid lifecycle transitions.

BUG=677253
Review-Url: https://codereview.chromium.org/2615213002
Cr-Commit-Position: refs/heads/master@{#442519}
Committed: https://chromium.googlesource.com/chromium/src/+/381723f8f6664f04b9524e6212e218e1b1ec7510

[haraken, 2017-01-06 10:53:18]

haraken@chromium.org changed reviewers:
+ dcheng@chromium.org, yukishiino@chromium.org

[haraken, 2017-01-06 10:53:19]

Now I'm ready to make this change. PTAL.

This CL replaces existing isContextInitialized() checks with the new lifecycle
model without changing any condition.

However, as commented below, I don't think the current condition is correct. Let
me dig into the details in a follow-up.

https://codereview.chromium.org/2615213002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/core/v8/V8BindingForTesting.cpp (left):

https://codereview.chromium.org/2615213002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/V8BindingForTesting.cpp:84:
getScriptState()->disposePerContextData();

disposePerContextData() is called in WindowProxy::disposeContext(), so no
needed. Calling it here confuses the relationship between the state of
WindowProxy::m_scriptState and WindowProxy::m_lifecycle.

https://codereview.chromium.org/2615213002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp (right):

https://codereview.chromium.org/2615213002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:222: // proxy. This
must be 'if(m_lifecycle == Lifecycle::ContextUninitialized)'.

If I change the condition to 'if(m_lifecycle ==
Lifecycle::ContextUninitialized)', a couple of webkit_unit_tests start failing.
This is clearly a bug. I'll investigate the bug after landing this CL.

Note that this CL does not change any existing behavior. This CL preserves the
existing wrong behavior.

https://codereview.chromium.org/2615213002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:330: //
DCHECK(m_lifecycle == Lifecycle::ContextUninitialized);

Ditto.

[haraken, 2017-01-06 10:53:25]

The CQ bit was checked by haraken@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-06 10:53:38]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Yuki, 2017-01-06 11:49:37]

Re-initialization of the context / global object is strange and should be
impossible, however, re-attachment of the browsing context is possible.  You can
insert an iframe, remove it, and then insert it again.

So, the spec allows uninitialized => initialized(attached) => detached =>
re-attached.  Blink doesn't support the re-attachement, though.

Navigation (updating the document) is disallowed while detached, but you can
re-attach and navigate the context.

https://codereview.chromium.org/2615213002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp (right):

https://codereview.chromium.org/2615213002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:331: m_lifecycle =
Lifecycle::ContextInitialized;
I'm not sure where we should set m_lifecycle to ContextInitialized.

The end of WindowProxy::initialize() may be an option.  In the initialize()
function, just afer the call to setupWindowPrototypeChain() may be another
option.

I understand that you put this here because we had CHECK(isContextInitialized())
just after createContext(), but the initialization has not yet been fully
completed.  Internal fields, m_globalProxy, etc. are not yet set at this point.

Personally I prefer the end of initialize() given that there is no use of
m_lifecycle during initialize().

https://codereview.chromium.org/2615213002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:485: // requires a
not-yet-detached context to instantiate a document wrapper.
There must be no way to update the document if the browsing context is detached.
 If there is, it must be a bug.

[haraken, 2017-01-06 12:54:15]

> Re-initialization of the context / global object is strange and should be
> impossible, however, re-attachment of the browsing context is possible. You
can
> insert an iframe, remove it, and then insert it again.

Yeah, I'll investigate after landing this CL. The good news is that we can repro
the case in webkit_unit_tests.

In this CL I want to add TODOs and keep existing behavior.

https://codereview.chromium.org/2615213002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp (right):

https://codereview.chromium.org/2615213002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:331: m_lifecycle =
Lifecycle::ContextInitialized;
On 2017/01/06 11:49:37, Yuki wrote:
> I'm not sure where we should set m_lifecycle to ContextInitialized.
> 
> The end of WindowProxy::initialize() may be an option.  In the initialize()
> function, just afer the call to setupWindowPrototypeChain() may be another
> option.
> 
> I understand that you put this here because we had
CHECK(isContextInitialized())
> just after createContext(), but the initialization has not yet been fully
> completed.  Internal fields, m_globalProxy, etc. are not yet set at this
point.
> 
> Personally I prefer the end of initialize() given that there is no use of
> m_lifecycle during initialize().

Done.

https://codereview.chromium.org/2615213002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:485: // requires a
not-yet-detached context to instantiate a document wrapper.
On 2017/01/06 11:49:37, Yuki wrote:
> There must be no way to update the document if the browsing context is
detached.
>  If there is, it must be a bug.

Yeah, but actually updateDocument is called after the context is detached (in
some tests in webkit_unit_tests)...

[haraken, 2017-01-06 12:54:24]

The CQ bit was checked by haraken@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-06 12:54:30]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Yuki, 2017-01-06 12:56:56]

LGTM.

https://codereview.chromium.org/2615213002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/WindowProxy.h (right):

https://codereview.chromium.org/2615213002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/WindowProxy.h:57: enum class
Lifecycle {
nit: We can move this into private: section?

[haraken, 2017-01-06 13:03:04]

>
https://codereview.chromium.org/2615213002/diff/100001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/bindings/core/v8/WindowProxy.h (right):
> 
>
https://codereview.chromium.org/2615213002/diff/100001/third_party/WebKit/Sou...
> third_party/WebKit/Source/bindings/core/v8/WindowProxy.h:57: enum class
> Lifecycle {
> nit: We can move this into private: section?

Done.

[haraken, 2017-01-06 13:03:15]

The CQ bit was checked by haraken@chromium.org

[haraken, 2017-01-06 13:03:15]

The patchset sent to the CQ was uploaded after l-g-t-m from
yukishiino@chromium.org
Link to the patchset: https://codereview.chromium.org/2615213002/#ps120001
(title: "temp")

[commit-bot: I haz the power, 2017-01-06 13:03:21]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-06 13:48:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-06 13:48:20]

Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[dcheng, 2017-01-06 18:44:39]

On 2017/01/06 13:48:20, commit-bot: I haz the power wrote:
> Try jobs failed on following builders:
>   linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
> (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

This is a blocking patch for me, so I'm going to look at the trybot failures and
try to address them.

[dcheng, 2017-01-09 00:26:39]

On 2017/01/06 18:44:39, dcheng wrote:
> On 2017/01/06 13:48:20, commit-bot: I haz the power wrote:
> > Try jobs failed on following builders:
> >   linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
> > (JOB_FAILED,
> >
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
> 
> This is a blocking patch for me, so I'm going to look at the trybot failures
and
> try to address them.

As an update, I haven't tracked down what's breaking completely yet. However, I
finally managed to get the 'jss' helper in v8/tools/gdbinit working. It turns
out that in debug builds, v8 is still built with optimizations. So if you set:

v8_optimized_debug = false

in GN, then 'jss' will work.

The stack where v8 crashes is:
#1  0x00007fffde1e1baf in V8_Fatal (file=0x7fffeb7231aa
"../../v8/src/lookup.cc", line=874, format=0x7fffeb6a493a "Check failed: %s.")  
    
    at ../../v8/src/base/logging.cc:66                                          
                                                            
#2  0x00007fffeb06d874 in v8::internal::LookupIterator::LookupCachedProperty
(this=0x7fffffff45c0) at ../../v8/src/lookup.cc:874             
#3  0x00007fffeb06d694 in v8::internal::LookupIterator::TryLookupCachedProperty
(this=0x7fffffff45c0) at ../../v8/src/lookup.cc:858
#4  0x00007fffeb09d0cc in v8::internal::Object::GetPropertyWithAccessor
(it=0x7fffffff45c0) at ../../v8/src/objects.cc:1428                  
#5  0x00007fffeb09bc59 in v8::internal::Object::GetProperty (it=0x7fffffff45c0)
at ../../v8/src/objects.cc:1060                              
#6  0x00007fffeafad885 in v8::internal::LoadIC::Load (this=0x7fffffff4840,
object=..., name=...) at ../../v8/src/ic/ic.cc:695
#7  0x00007fffeafaeaa3 in v8::internal::LoadGlobalIC::Load (this=0x7fffffff4840,
name=...) at ../../v8/src/ic/ic.cc:737                      
#8  0x00007fffeafbb480 in v8::internal::__RT_impl_Runtime_LoadGlobalIC_Miss
(args=..., isolate=0x2a273ebcc020) at ../../v8/src/ic/ic.cc:2597 
#9  0x00007fffeafbb120 in v8::internal::Runtime_LoadGlobalIC_Miss
(args_length=3, args_object=0x7fffffff49f8, isolate=0x2a273ebcc020)   
    at ../../v8/src/ic/ic.cc:2582   

and this script is invoked from:

#0  0x00007fffeae75cde in v8::internal::(anonymous namespace)::Invoke
(isolate=0x2b4b4f2e2020, is_construct=false, target=...,
    receiver=..., argc=0, args=0x0, new_target=...) at
../../v8/src/execution.cc:139
#1  0x00007fffeae756f8 in v8::internal::Execution::Call (isolate=0x2b4b4f2e2020,
callable=..., receiver=..., argc=0, argv=0x0)
    at ../../v8/src/execution.cc:176
#2  0x00007fffea76c1a3 in v8::Script::Run (this=0x2b4b4f627880, context=...) at
../../v8/src/api.cc:2018
#3  0x00007fffe6f44692 in blink::V8ScriptRunner::runCompiledScript
(isolate=0x2b4b4f2e2020, script=..., context=0xa78b2722988)
    at ../../third_party/WebKit/Source/bindings/core/v8/V8ScriptRunner.cpp:524
#4  0x00007fffe6e9d695 in blink::ScriptController::executeScriptAndReturnValue
(this=0x1ecdf7801830, context=..., source=...,
    accessControlStatus=blink::NotSharableCrossOrigin) at
../../third_party/WebKit/Source/bindings/core/v8/ScriptController.cpp:151
#5  0x00007fffe6e9f475 in blink::ScriptController::evaluateScriptInMainWorld
(this=0x1ecdf7801830, sourceCode=...,
    accessControlStatus=blink::NotSharableCrossOrigin,
policy=blink::ScriptController::DoNotExecuteScriptWhenScriptsDisabled)
    at ../../third_party/WebKit/Source/bindings/core/v8/ScriptController.cpp:426
#6  0x00007fffe6e9f6b7 in
blink::ScriptController::executeScriptInMainWorldAndReturnValue
(this=0x1ecdf7801830, sourceCode=...,
    policy=blink::ScriptController::DoNotExecuteScriptWhenScriptsDisabled)
    at ../../third_party/WebKit/Source/bindings/core/v8/ScriptController.cpp:406
#7  0x00007fffe9e59c45 in blink::WebLocalFrameImpl::executeScriptAndReturnValue
(this=0x3c406f4e1ee0, source=...)
    at ../../third_party/WebKit/Source/web/WebLocalFrameImpl.cpp:745
#8  0x00007fffe9e59cdc in non-virtual thunk to
blink::WebLocalFrameImpl::executeScriptAndReturnValue(blink::WebScriptSource
const&) ()
    at ../../third_party/WebKit/Source/wtf/Vector.h:873
#9  0x00007ffff2ba6c23 in
content::RenderFrameImpl::OnJavaScriptExecuteRequestForTests
(this=0x2b4b4f279020,
   
jscript="w\000i\000n\000d\000o\000w\000.\000d\000o\000m\000A\000u\000t\000o\000m\000a\000t\000i\000o\000n\000C\000o\000n\000t\000r\000o\000l\000l\000e\000r\000.\000s\000e\000t\000A\000u\000t\000o\000m\000a\000t\000i\000o\000n\000I\000d\000(\000\060\000)\000;\000w\000i\000n\000d\000o\000w\000.\000d\000o\000m\000A\000u\000t\000o\000m\000a\000t\000i\000o\000n\000C\000o\000n\000t\000r\000o\000l\000l\000e\000r\000.\000s\000e\000n\000d\000(\000c\000l\000i\000c\000k\000S\000a\000m\000e\000S\000i\000t\000e\000N\000"...,
id=0, notify_result=false,
    has_user_gesture=true) at ../../content/renderer/render_frame_impl.cc:1971

My guess is perhaps the v8 context is not getting reinitialized, but I need to
debug more.

[dcheng, 2017-01-09 22:01:31]

On 2017/01/09 00:26:39, dcheng wrote:
> On 2017/01/06 18:44:39, dcheng wrote:
> > On 2017/01/06 13:48:20, commit-bot: I haz the power wrote:
> > > Try jobs failed on following builders:
> > >   linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
> > > (JOB_FAILED,
> > >
> >
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
> > 
> > This is a blocking patch for me, so I'm going to look at the trybot failures
> and
> > try to address them.
> 
> As an update, I haven't tracked down what's breaking completely yet. However,
I
> finally managed to get the 'jss' helper in v8/tools/gdbinit working. It turns
> out that in debug builds, v8 is still built with optimizations. So if you set:
> 
> v8_optimized_debug = false
> 
> in GN, then 'jss' will work.
> 
> The stack where v8 crashes is:
> #1  0x00007fffde1e1baf in V8_Fatal (file=0x7fffeb7231aa
> "../../v8/src/lookup.cc", line=874, format=0x7fffeb6a493a "Check failed: %s.")
 
>     
>     at ../../v8/src/base/logging.cc:66                                        
 
>                                                             
> #2  0x00007fffeb06d874 in v8::internal::LookupIterator::LookupCachedProperty
> (this=0x7fffffff45c0) at ../../v8/src/lookup.cc:874             
> #3  0x00007fffeb06d694 in
v8::internal::LookupIterator::TryLookupCachedProperty
> (this=0x7fffffff45c0) at ../../v8/src/lookup.cc:858
> #4  0x00007fffeb09d0cc in v8::internal::Object::GetPropertyWithAccessor
> (it=0x7fffffff45c0) at ../../v8/src/objects.cc:1428                  
> #5  0x00007fffeb09bc59 in v8::internal::Object::GetProperty
(it=0x7fffffff45c0)
> at ../../v8/src/objects.cc:1060                              
> #6  0x00007fffeafad885 in v8::internal::LoadIC::Load (this=0x7fffffff4840,
> object=..., name=...) at ../../v8/src/ic/ic.cc:695
> #7  0x00007fffeafaeaa3 in v8::internal::LoadGlobalIC::Load
(this=0x7fffffff4840,
> name=...) at ../../v8/src/ic/ic.cc:737                      
> #8  0x00007fffeafbb480 in v8::internal::__RT_impl_Runtime_LoadGlobalIC_Miss
> (args=..., isolate=0x2a273ebcc020) at ../../v8/src/ic/ic.cc:2597 
> #9  0x00007fffeafbb120 in v8::internal::Runtime_LoadGlobalIC_Miss
> (args_length=3, args_object=0x7fffffff49f8, isolate=0x2a273ebcc020)   
>     at ../../v8/src/ic/ic.cc:2582   
> 
> and this script is invoked from:
> 
> #0  0x00007fffeae75cde in v8::internal::(anonymous namespace)::Invoke
> (isolate=0x2b4b4f2e2020, is_construct=false, target=...,
>     receiver=..., argc=0, args=0x0, new_target=...) at
> ../../v8/src/execution.cc:139
> #1  0x00007fffeae756f8 in v8::internal::Execution::Call
(isolate=0x2b4b4f2e2020,
> callable=..., receiver=..., argc=0, argv=0x0)
>     at ../../v8/src/execution.cc:176
> #2  0x00007fffea76c1a3 in v8::Script::Run (this=0x2b4b4f627880, context=...)
at
> ../../v8/src/api.cc:2018
> #3  0x00007fffe6f44692 in blink::V8ScriptRunner::runCompiledScript
> (isolate=0x2b4b4f2e2020, script=..., context=0xa78b2722988)
>     at ../../third_party/WebKit/Source/bindings/core/v8/V8ScriptRunner.cpp:524
> #4  0x00007fffe6e9d695 in blink::ScriptController::executeScriptAndReturnValue
> (this=0x1ecdf7801830, context=..., source=...,
>     accessControlStatus=blink::NotSharableCrossOrigin) at
> ../../third_party/WebKit/Source/bindings/core/v8/ScriptController.cpp:151
> #5  0x00007fffe6e9f475 in blink::ScriptController::evaluateScriptInMainWorld
> (this=0x1ecdf7801830, sourceCode=...,
>     accessControlStatus=blink::NotSharableCrossOrigin,
> policy=blink::ScriptController::DoNotExecuteScriptWhenScriptsDisabled)
>     at
../../third_party/WebKit/Source/bindings/core/v8/ScriptController.cpp:426
> #6  0x00007fffe6e9f6b7 in
> blink::ScriptController::executeScriptInMainWorldAndReturnValue
> (this=0x1ecdf7801830, sourceCode=...,
>     policy=blink::ScriptController::DoNotExecuteScriptWhenScriptsDisabled)
>     at
../../third_party/WebKit/Source/bindings/core/v8/ScriptController.cpp:406
> #7  0x00007fffe9e59c45 in
blink::WebLocalFrameImpl::executeScriptAndReturnValue
> (this=0x3c406f4e1ee0, source=...)
>     at ../../third_party/WebKit/Source/web/WebLocalFrameImpl.cpp:745
> #8  0x00007fffe9e59cdc in non-virtual thunk to
> blink::WebLocalFrameImpl::executeScriptAndReturnValue(blink::WebScriptSource
> const&) ()
>     at ../../third_party/WebKit/Source/wtf/Vector.h:873
> #9  0x00007ffff2ba6c23 in
> content::RenderFrameImpl::OnJavaScriptExecuteRequestForTests
> (this=0x2b4b4f279020,
>    
>
jscript="w\000i\000n\000d\000o\000w\000.\000d\000o\000m\000A\000u\000t\000o\000m\000a\000t\000i\000o\000n\000C\000o\000n\000t\000r\000o\000l\000l\000e\000r\000.\000s\000e\000t\000A\000u\000t\000o\000m\000a\000t\000i\000o\000n\000I\000d\000(\000\060\000)\000;\000w\000i\000n\000d\000o\000w\000.\000d\000o\000m\000A\000u\000t\000o\000m\000a\000t\000i\000o\000n\000C\000o\000n\000t\000r\000o\000l\000l\000e\000r\000.\000s\000e\000n\000d\000(\000c\000l\000i\000c\000k\000S\000a\000m\000e\000S\000i\000t\000e\000N\000"...,
> id=0, notify_result=false,
>     has_user_gesture=true) at ../../content/renderer/render_frame_impl.cc:1971
> 
> My guess is perhaps the v8 context is not getting reinitialized, but I need to
> debug more.

Also, for completeness, the v8 assert is:
#                                                                               
                   
# Fatal error in ../../v8/src/lookup.cc, line 874                               
                   
# Check failed: state() == LookupIterator::DATA (4 vs. 6).                      
                   
#      

And this is happening when something is trying to touch the document property it
seems: in LoadIC::Load(), job *(void**) name prints out '#document'. 4 is
LookupIterator::NOT_FOUND.

[dcheng, 2017-01-09 22:10:58]

https://codereview.chromium.org/2615213002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp (right):

https://codereview.chromium.org/2615213002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:286: m_lifecycle =
Lifecycle::ContextInitialized;
I understand the trybot failures now. It is problematic to set Initialized
here--things like updateDocument() and setSecurityOrigin() are no-ops if
lifecycle != Lifecycle::ContextInitialized. So this causes all the work to be
skipped.

So even though it looks weird, I guess we should just set it at the beginning of
initialize() -- there are no longer any early returns, so there are no
initialization paths that can fail. But it would be nice to able to assert this
somehow...

[haraken, 2017-01-10 03:48:34]

The CQ bit was checked by haraken@chromium.org

[haraken, 2017-01-10 03:48:34]

The patchset sent to the CQ was uploaded after l-g-t-m from
yukishiino@chromium.org
Link to the patchset: https://codereview.chromium.org/2615213002/#ps140001
(title: "temp")

[haraken, 2017-01-10 03:48:58]

On 2017/01/09 22:10:58, dcheng wrote:
>
https://codereview.chromium.org/2615213002/diff/120001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp (right):
> 
>
https://codereview.chromium.org/2615213002/diff/120001/third_party/WebKit/Sou...
> third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:286: m_lifecycle =
> Lifecycle::ContextInitialized;
> I understand the trybot failures now. It is problematic to set Initialized
> here--things like updateDocument() and setSecurityOrigin() are no-ops if
> lifecycle != Lifecycle::ContextInitialized. So this causes all the work to be
> skipped.
> 
> So even though it looks weird, I guess we should just set it at the beginning
of
> initialize() -- there are no longer any early returns, so there are no
> initialization paths that can fail. But it would be nice to able to assert
this
> somehow...

Thanks for the digging! I moved the place to set Lifecycle::ContextInitialized
to the end of createContext().

[commit-bot: I haz the power, 2017-01-10 03:49:25]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-10 06:21:47]

CQ is committing da patch.

Bot data: {"patchset_id": 140001, "attempt_start_ts": 1484020114609180,
"parent_rev": "968d2048faa36195bf79684cb104aec2399d10ee", "commit_rev":
"381723f8f6664f04b9524e6212e218e1b1ec7510"}

[commit-bot: I haz the power, 2017-01-10 06:22:23]

Description was changed from

==========
Introduce a lifecycle model to WindowProxy

This CL intorduces the following lifecycle model to WindowProxy:

  ContextUninitialized => ContextInitialized => ContextDetached

This clarifies the lifecycle and enables us to insert dchecks to detect
invalid lifecycle transitions.

BUG=677253
==========

to

==========
Introduce a lifecycle model to WindowProxy

This CL intorduces the following lifecycle model to WindowProxy:

  ContextUninitialized => ContextInitialized => ContextDetached

This clarifies the lifecycle and enables us to insert dchecks to detect
invalid lifecycle transitions.

BUG=677253

Review-Url: https://codereview.chromium.org/2615213002
Cr-Commit-Position: refs/heads/master@{#442519}
Committed:
https://chromium.googlesource.com/chromium/src/+/381723f8f6664f04b9524e6212e2...
==========

[commit-bot: I haz the power, 2017-01-10 06:22:24]

Committed patchset #8 (id:140001) as
https://chromium.googlesource.com/chromium/src/+/381723f8f6664f04b9524e6212e2...