Add EventHandlerRegistry

Source/core/dom/Document.cpp

Index: Source/core/dom/Document.cpp
diff --git a/Source/core/dom/Document.cpp b/Source/core/dom/Document.cpp
index 2a769a7a64f5d330e24938505e1b37da109c9c15..e8717adefbe61c6e6600c13831d643f02372add5 100644
--- a/Source/core/dom/Document.cpp
+++ b/Source/core/dom/Document.cpp
@@ -71,6 +71,7 @@
 #include "core/dom/Element.h"
 #include "core/dom/ElementDataCache.h"
 #include "core/dom/ElementTraversal.h"
+#include "core/dom/EventHandlerRegistry.h"
 #include "core/dom/ExceptionCode.h"
 #include "core/dom/ExecutionContextTask.h"
 #include "core/dom/MainThreadTaskRunner.h"
@@ -2092,6 +2093,7 @@ void Document::attach(const AttachContext& context)
         textAutosizer->updatePageInfo();
 
     m_lifecycle.advanceTo(DocumentLifecycle::StyleClean);
+    lifecycleNotifier().notifyDocumentWasAttached();

[abarth-chromium, 2014/04/11 19:08:01]

What is it appropriate to do this work during Document::attach?  Generally
speaking, Document::attach is related to visual rendering of the document
whereas keeping track of these events has to do with the object model of the
document, which is independent of visual rendering.

[Sami, 2014/04/15 18:31:52]

Turns out I was a little confused about a document's relation to its window and
thought there was a way to directly move a document from one window to another.
Since this isn't the case (as far as I can tell), we can simplify this problem
down to two transitions:

1. A new document is given a window, which may have existing handlers on it =>
register those handlers.
2. Document is detached => unregister all existing window handlers and stop
tracking new ones.

The first case can we can deal with when constructing the registry and the
second case is served by ActiveDOMObject::stop().

 }
 
 void Document::detach(const AttachContext& context)