Simplify DOMWindowProperty and its unregistration.

Source/core/frame/LocalDOMWindow.h

 /*
  * Copyright (C) 2006, 2007, 2009, 2010 Apple Inc. All rights reserved.
  * Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies)
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
@@ skipping 94 matching lines @@
     virtual ~LocalDOMWindow();
 
     PassRefPtrWillBeRawPtr<Document> installNewDocument(const String& mimeType, const DocumentInit&, bool forceXHTML = false);
 
     virtual const AtomicString& interfaceName() const OVERRIDE;
     virtual ExecutionContext* executionContext() const OVERRIDE;
 
     virtual LocalDOMWindow* toDOMWindow() OVERRIDE;
 
     void registerProperty(DOMWindowProperty*);
-    void unregisterProperty(DOMWindowProperty*);
 
     void reset();
 
     PassRefPtrWillBeRawPtr<MediaQueryList> matchMedia(const String&);
 
     unsigned pendingUnloadEventListeners() const;
 
     static FloatRect adjustWindowRect(LocalFrame&, const FloatRect& pendingChanges);
 
     bool allowPopUp(); // Call on first window, not target window.
@@ skipping 233 matching lines @@
 
     void removeAllEventListenersInternal(BroadcastListenerRemoval);
 
     RefPtrWillBeMember<Document> m_document;
 
     bool m_shouldPrintWhenFinishedLoading;
 #if ENABLE(ASSERT)
     bool m_hasBeenReset;
 #endif
 
     WillBeHeapHashSet<RawPtrWillBeMember<DOMWindowProperty> > m_properties;

[Mads Ager (chromium), 2014/09/10 15:52:56]

What makes sure that a DOMWindowProperty cannot die before the LocalDOMWindow
and therefore the notification that the global object is being destroyed?

It makes sense for the DOMWindowProperties that are LocalDOMWindow supplements.
However, there are other DOMWIndowProperties such as BarProp that are not
LocalDOMWindow supplements and I can't convince myself that they cannot die
before the LocalDOMWindow in the non-oilpan build?

(That also reopens the question that we had on the oilpan part of this code. I
said that I would prefer a strong relationship between the DOMWindowProperty and
its LocalDOMWindow. However, if there are short lived DOMWindowProperties, we
might not want to have the LocalDOMWindow keep them alive. If that is the case
we should move to weak processing in the oilpan build to remove from this set.)

[Mads Ager (chromium), 2014/09/10 15:55:19]

Heh, ignore me. All of those properties are held alive by the list of RefPtrs
below. :-)

[sof, 2014/09/10 18:18:39]

Yes, it looks doable to elaborate m_properties to avoid having that long list of
strong references. But it makes for convenient&fast lookups as it is.

(A micro optimization with Oilpan would be not to re-trace() them.)

 
     mutable RefPtrWillBeMember<Screen> m_screen;
     mutable RefPtrWillBeMember<History> m_history;
     mutable RefPtrWillBeMember<BarProp> m_locationbar;
     mutable RefPtrWillBeMember<BarProp> m_menubar;
     mutable RefPtrWillBeMember<BarProp> m_personalbar;
     mutable RefPtrWillBeMember<BarProp> m_scrollbars;
     mutable RefPtrWillBeMember<BarProp> m_statusbar;
     mutable RefPtrWillBeMember<BarProp> m_toolbar;
     mutable RefPtrWillBeMember<Console> m_console;
@@ skipping 24 matching lines @@
 }
 
 inline String LocalDOMWindow::defaultStatus() const
 {
     return m_defaultStatus;
 }
 
 } // namespace blink
 
 #endif // LocalDOMWindow_h