Add a lifecycle state machine for Document

Add a lifecycle state machine for Document

This CL adds a linear state machine to the Document to ensure that it follows
an orderly progression through its state machine. The plan is to use this state
machine in https://codereview.chromium.org/24976002/ rather than asking the
render tree whether the document is active.

R=eseidel
BUG=299011
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=158503

[eseidel, 2013-09-27 20:33:54]

lgtm

[commit-bot: I haz the power, 2013-09-27 20:34:16]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/abarth@chromium.org/25036004/1

[Peter Beverloo, 2013-09-27 20:38:57]

Will DocumentLifecycle eventually own the DocumentLifecycleNotifier and inform
the observers based on calls to advanceTo()?

The name DocumentLifecycle would indicate to me that it has more
responsibilities than just be the state, also since we already have various
other DocumentLifecycle* classes.  If it'll just do the state, maybe
DocumentLifecycleState would be a better name?

[abarth-chromium, 2013-09-27 20:48:31]

On 2013/09/27 20:38:57, Peter Beverloo wrote:
> Will DocumentLifecycle eventually own the DocumentLifecycleNotifier and inform
> the observers based on calls to advanceTo()?

They're definitely related.  I'm not sure which should own which.  I also want
to align the names so that the relationship between the observations and the
transitions are clear.

> The name DocumentLifecycle would indicate to me that it has more
> responsibilities than just be the state, also since we already have various
> other DocumentLifecycle* classes.  If it'll just do the state, maybe
> DocumentLifecycleState would be a better name?

DocumentLifecycleState::State would have a bit of a stutter...

[Peter Beverloo, 2013-09-27 21:26:30]

On 2013/09/27 20:48:31, abarth wrote:
> On 2013/09/27 20:38:57, Peter Beverloo wrote:
> > Will DocumentLifecycle eventually own the DocumentLifecycleNotifier and
inform
> > the observers based on calls to advanceTo()?
> 
> They're definitely related.  I'm not sure which should own which.  I also want
> to align the names so that the relationship between the observations and the
> transitions are clear.

Ok. The differences in naming of events while DocumentLifecycle and
DocumentLifecycleNotifier are very related was a concern.  I guess
DocumentLifecycle could take on that responsibility since it already receives
the notifications in the first place, and "m_lifeCycle.addObserver()" reads
well.  Anyhow, that can be orthogonal to this change :-).  Thanks for the
clarification!

> > The name DocumentLifecycle would indicate to me that it has more
> > responsibilities than just be the state, also since we already have various
> > other DocumentLifecycle* classes.  If it'll just do the state, maybe
> > DocumentLifecycleState would be a better name?
> 
> DocumentLifecycleState::State would have a bit of a stutter...

Agreed.

[commit-bot: I haz the power, 2013-09-28 00:20:30]

Retried try job too often on win_blink_rel for step(s) webkit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_blink_...

[commit-bot: I haz the power, 2013-09-28 00:22:54]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/abarth@chromium.org/25036004/1

[commit-bot: I haz the power, 2013-09-28 04:29:26]

Failed to apply patch for Source/core/dom/Document.h:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file Source/core/dom/Document.h
  Hunk #1 FAILED at 32.
  Hunk #2 succeeded at 42 (offset -1 lines).
  Hunk #3 succeeded at 1058 (offset -3 lines).
  Hunk #4 succeeded at 1153 (offset -1 lines).
  1 out of 4 hunks FAILED -- saving rejects to file
Source/core/dom/Document.h.rej

Patch:       Source/core/dom/Document.h
Index: Source/core/dom/Document.h
diff --git a/Source/core/dom/Document.h b/Source/core/dom/Document.h
index
37cfc0e9ad8ddc4f6e8f2b4d587e94351a166a9a..23214f8ab6ddbc331f58bb7f690ef6bcc8c562a7
100644
--- a/Source/core/dom/Document.h
+++ b/Source/core/dom/Document.h
@@ -32,8 +32,8 @@
 #include "core/dom/ContainerNode.h"
 #include "core/dom/CustomElement.h"
 #include "core/dom/DOMTimeStamp.h"
-#include "core/events/DocumentEventQueue.h"
 #include "core/dom/DocumentInit.h"
+#include "core/dom/DocumentLifecycle.h"
 #include "core/dom/DocumentTiming.h"
 #include "core/dom/IconURL.h"
 #include "core/dom/MutationObserver.h"
@@ -43,12 +43,13 @@
 #include "core/dom/TreeScope.h"
 #include "core/dom/UserActionElementSet.h"
 #include "core/dom/ViewportArguments.h"
+#include "core/events/DocumentEventQueue.h"
 #include "core/html/CollectionType.h"
 #include "core/page/FocusDirection.h"
 #include "core/page/PageVisibilityState.h"
-#include "weborigin/ReferrerPolicy.h"
 #include "core/platform/Timer.h"
 #include "core/rendering/HitTestRequest.h"
+#include "weborigin/ReferrerPolicy.h"
 #include "wtf/HashSet.h"
 #include "wtf/OwnPtr.h"
 #include "wtf/PassOwnPtr.h"
@@ -1060,6 +1061,7 @@ public:
 
     PassRefPtr<FontFaceSet> fonts();
     DocumentLifecycleNotifier* lifecycleNotifier();
+    bool isActive() const { return m_lifecyle.state() ==
DocumentLifecycle::Active; }
 
     enum HttpRefreshType {
         HttpRefreshFromHeader,
@@ -1152,6 +1154,8 @@ private:
     void processHttpEquivXFrameOptions(const String& content);
     void processHttpEquivContentSecurityPolicy(const String& equiv, const
String& content);
 
+    DocumentLifecycle m_lifecyle;
+
     // FIXME: This should probably be handled inside the style resolver itself.
     Timer<Document> m_styleResolverThrowawayTimer;
     unsigned m_styleResolverAccessCount;

[commit-bot: I haz the power, 2013-09-29 20:32:04]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/abarth@chromium.org/25036004/21001

[commit-bot: I haz the power, 2013-09-29 23:27:09]

Change committed as 158503