[webkit-reviews] review granted: [Bug 17425] eliminate DeprecatedPtrList : [Attachment 26012] patch for part of this

[bugzilla-daemon at webkit.org]

Sam Weinig <sam at webkit.org> has granted Darin Adler <darin at apple.com>'s request
for review:
Bug 17425: eliminate DeprecatedPtrList
https://bugs.webkit.org/show_bug.cgi?id=17425

Attachment 26012: patch for part of this
https://bugs.webkit.org/attachment.cgi?id=26012&action=review

------- Additional Comments from Sam Weinig <sam at webkit.org>
> +++ ChangeLog (working copy)
> @@ -1,3 +1,29 @@
> +2008-12-13  Cameron Zwarich	<zwarich at apple.com>
> +
> +	   Reviewed by NOBODY (OOPS!).
> +
> +	   Bug 22562: REGRESSION (r37971): events not firing after going back
in back/forward cache
> +	   <https://bugs.webkit.org/show_bug.cgi?id=22562>
> +	   <rdar://problem/6414593>
> +
> +	   Restore the Frame's DOMWindow to its previous value when going back
in
> +	   the back/forward cache. The fact that it was not getting set before
may
> +	   have always caused some subtle bugs with the back/forward cache, but

> +	   after r37971, it causes no events to fire after restoring a page.
> +
> +	   Unfortunately, there is no way to test this with a layout test
because
> +	   it involves the back/forward cache.
> +
> +	   * history/CachedPage.cpp:
> +	   (WebCore::CachedPage::domWindow): Add.
> +	   * history/CachedPage.h:
> +	   * loader/FrameLoader.cpp:
> +	   (WebCore::FrameLoader::open): Restore the DOMWindow of the Frame to
its
> +	   saved value when navigating in the back/forward cache.
> +	   * page/Frame.cpp:
> +	   (WebCore::Frame::setDOMWindow): Add.
> +	   * page/Frame.h:

I don't think you meant to include this.


> +    // Set up a pointer to indicate whether to dispatch window events.
> +    // We don't dispatch load events to the window as a quirk, because
> +    // Mozilla used to never propagate load events to the window object.

Is this not true anymore?  Should we stop behaving this way?

r=me.