[webkit-changes] [WebKit/WebKit] 96e0c1: Lazily loaded frames should still get a contentWin...

[Chris Dumez]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 96e0c1e9f533ea9b3e084baee49342c95b6f68b8
      https://github.com/WebKit/WebKit/commit/96e0c1e9f533ea9b3e084baee49342c95b6f68b8
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-02-22 (Wed, 22 Feb 2023)

  Changed paths:
    A LayoutTests/http/tests/lazyload/synchronous-frame-creation-expected.txt
    A LayoutTests/http/tests/lazyload/synchronous-frame-creation.html
    M Source/WebCore/html/HTMLFrameElementBase.cpp
    M Source/WebCore/loader/SubframeLoader.cpp
    M Source/WebCore/loader/SubframeLoader.h

  Log Message:
  -----------
  Lazily loaded frames should still get a contentWindow/contentDocument as soon as they get inserted into the document
https://bugs.webkit.org/show_bug.cgi?id=252754

Reviewed by Rob Buis.

Lazily loaded frames should still get a contentWindow/contentDocument as soon
as they get inserted into the document. Currently, we return null for these
until the iframe moves to the viewport and gets loaded. This behavior is
inconsistent with Chrome and recently caused breakage on
https://www.kongregate.com (Bug 252636).

* LayoutTests/http/tests/lazyload/synchronous-frame-creation-expected.txt: Added.
* LayoutTests/http/tests/lazyload/synchronous-frame-creation.html: Added.
* Source/WebCore/html/HTMLFrameElementBase.cpp:
(WebCore::HTMLFrameElementBase::openURL):
* Source/WebCore/loader/SubframeLoader.cpp:
(WebCore::FrameLoader::SubframeLoader::createFrameIfNecessary):
* Source/WebCore/loader/SubframeLoader.h:

Canonical link: https://commits.webkit.org/260713@main