Move empty loading to DocumentLoader, simplify FrameLoader::init()
https://bugs.webkit.org/show_bug.cgi?id=101512

Reviewed by Adam Barth.

Source/WebCore:

No new tests, though several outputs changed because we no longer send resource
    load callbacks for empty loads.

* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::startLoadingMainResource): Handle empty main resource
    loads directly here.
* loader/DocumentLoader.h:
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::FrameLoader): Initialize some variables whose values
    were previously being reset in init(). Given that the FrameLoader is in
    an inconsistent state before init() is called anyway, there doesn't seem
    to be a disadvantage to just initializing them to their post-init() values.
(WebCore::FrameLoader::init): Just call startLoadingMainResource(), instead of
    doing a bunch of direct calls to functions FrameLoader shouldn't know about.
* loader/FrameLoaderStateMachine.cpp:
* loader/FrameLoaderStateMachine.h:
* loader/MainResourceLoader.cpp: Throughout, remove the concept of an empty load.
(WebCore::MainResourceLoader::loadNow): This only returned true when an empty
    load got deferred, which won't happen now. Return void and always treat
    as returning false.
* loader/MainResourceLoader.h:

Tools:

Chromium DRT has some code that doesn't play nicely with empty urls and incorrectly
interprets them as a non-empty load. This ensures
http/tests/navigation/new-window-redirect-history.html continues to pass
in chromium.

* DumpRenderTree/chromium/WebViewHost.cpp:
(WebViewHost::updateForCommittedLoad):

LayoutTests:

Don't expect resource load callbacks for empty loads.

* http/tests/inspector/network/network-iframe-load-and-delete.html:
* http/tests/loading/redirect-methods-expected.txt:
* http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-expected.txt:
* http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-in-body-expected.txt:
* http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-parent-same-origin-deny-expected.txt:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@134649 268f45cc-cd09-0410-ab3c-d52691b4dbfc
PDFPlugin should make use of PDFKit's fluid zooming
https://bugs.webkit.org/show_bug.cgi?id=101962
<rdar://problem/12555229>

Reviewed by Anders Carlsson.

Expose the notion of a frame that handles page scale gestures via WebFrame and to the bundle via WKBundleFrame.
The only frames that will purport to handle page scale gestures are those which contain PluginDocuments
backed by PDFPlugin, for now. Also, allow PDFKit to do its own fluid zooming animation.

* WebProcess/InjectedBundle/API/c/WKBundleFrame.cpp:
(WKBundleFrameHandlesPageScaleGesture): Provide WKBundleFrameHandlesPageScaleGesture to
inform the injected bundle whether or not the frame handles scaling itself.
* WebProcess/InjectedBundle/API/c/WKBundleFramePrivate.h: Add WKBundleFrameHandlesPageScaleGesture.
* WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::geometryDidChange): Allow PDFKit to use its fluid zooming instead of changing
the scale factor immediately.
* WebProcess/WebPage/WebFrame.cpp:
(WebKit::WebFrame::handlesPageScaleGesture): For now, the only frames that handle page scale
gestures themselves are plugins that purport to handle page scale changes themselves (i.e. only PDFPlugin).
* WebProcess/WebPage/WebFrame.h:
(WebFrame):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@134650 268f45cc-cd09-0410-ab3c-d52691b4dbfc