[iOS WK1] Single touch div scrolling doesn't work in framesets (breaks Word previews)
https://bugs.webkit.org/show_bug.cgi?id=135103
<rdar://problem/11830219>

Reviewed by Darin Adler.

After r166117 all layer flushing starts on the root frame; we no longer flush layers
for each frame during painting. However, flushing GraphicsLayers can set some state
on a subframe RenderLayerCompositor that is now never processed, which breaks scroll
layer registration.

Fix by doing a walk of the Frame tree, and calling didFlushLayers() on subframe RenderLayerCompositors
before calling didFlushLayers() on self.

* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::flushPendingLayerChanges):
(WebCore::RenderLayerCompositor::didFlushLayers):
(WebCore::RenderLayerCompositor::notifySubframesAfterLayerFlush):
(WebCore::RenderLayerCompositor::enclosingCompositorFlushingLayers): Drive-by nullptr.
* rendering/RenderLayerCompositor.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171306 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add helper functions to dump the scrolling state tree from the debugger
https://bugs.webkit.org/show_bug.cgi?id=135101

Reviewed by Darin Adler.

Add debug-only showScrollingStateTree() functions that take a ScrollingStateTree* and ScrollingStateNode*
for use while debugging.

* page/scrolling/ScrollingStateTree.cpp:
(showScrollingStateTree):
* page/scrolling/ScrollingStateTree.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171307 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Put position:fixed elements into layers when a WK1 view is layer-backed
https://bugs.webkit.org/show_bug.cgi?id=135075

Reviewed by Darin Adler.


Source/WebCore: 
This patch adds a new ChromeClient function called 
requiresAcceleratedCompositingForViewportConstrainedPosition(). Since a view can 
go in and out of layer backing, we need a ChromeClient method that can be 
dynamically re-evaluated rather than using the existing settings for enabling 
accelerated fixed and fixed that creates a stacking context.

Ensure that fixed elements create a stacking context when 
requiresAcceleratedCompositingForViewportConstrainedPosition is true.
* css/StyleResolver.cpp:
(WebCore::StyleResolver::adjustRenderStyle):

New ChromeClient function.
* page/ChromeClient.h:

Source/WebKit/mac: 
Returns true when the WebHTMLView has a layer.

* WebCoreSupport/WebChromeClient.h:
* WebCoreSupport/WebChromeClient.mm:
(WebChromeClient::requiresAcceleratedCompositingForViewportConstrainedPosition):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171308 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed hidpi test gardening.

Use Ahem font to ensure font size predictability.

* fast/forms/hidpi-fieldset-on-subpixel-position-when-legend-is-present-expected.html:
* fast/forms/hidpi-fieldset-on-subpixel-position-when-legend-is-present.html:

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

* WebCoreSupport/WebChromeClient.mm:
(WebChromeClient::requiresAcceleratedCompositingForViewportConstrainedPosition):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171310 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Case sensitive file system build fix.

* page/scrolling/ScrollingStateTree.cpp:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171311 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Back/Forward arrows (modern) are too large.
https://bugs.webkit.org/show_bug.cgi?id=135073

Reviewed by Joseph Pecoraro.

Changes to adjust new forward and back arrow sizes to be more consistent with the
universal design language. Moved WebInspector.Platform definition to its own file.
Refactored handling of image versions inside ImageUtilities.js.

* UserInterface/Base/ImageUtilities.js:
(.restoreImage):
(.generateImage):
(generateColoredImagesForCSS):
Make the default image versioning smarter.

* UserInterface/Base/Main.js:
(WebInspector.contentLoaded):
(WebInspector.contentLoaded.WebInspector.Platform.version.toString): Deleted.
(WebInspector.contentLoaded.WebInspector.Platform.toString): Deleted.
* UserInterface/Base/Platform.js: Added.
Move platform information definition into Platform.js.

* UserInterface/Main.html: Include Platform.js.

* UserInterface/Views/ContentBrowser.js:
(WebInspector.ContentBrowser):
* UserInterface/Views/FindBanner.css:
(.find-banner > button > .glyph):
(body.mac-platform.legacy .find-banner > button > .glyph):
(.find-banner > button.segmented.left > .glyph):
(body.mac-platform.legacy .find-banner > button.segmented.left > .glyph):
(.find-banner > button.segmented.right > .glyph):
(body.mac-platform.legacy .find-banner > button.segmented.right > .glyph):
(.find-banner > button.segmented):
(body.mac-platform.legacy .find-banner > button.segmented):
* UserInterface/Views/FindBanner.js:
(WebInspector.FindBanner.prototype._generateButtonsGlyphsIfNeeded):
Size of forward and back arrows adjusted.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171312 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fast/canvas/canvas-putImageData-zero-alpha.html is flaky
https://bugs.webkit.org/show_bug.cgi?id=131787

* platform/mac/TestExpectations: Mark it as such.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171313 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS] Handle QuickLook ResourceLoaders in the web process
https://bugs.webkit.org/show_bug.cgi?id=135113

Reviewed by David Kilzer.

Source/WebCore:
No new tests. QuickLook is not testable from WebKit.

* WebCore.exp.in:
* loader/ResourceLoadScheduler.cpp:
(WebCore::ResourceLoadScheduler::maybeLoadQuickLookResource): Start loading the ResourceLoader if it is for a QuickLook resource.
* loader/ResourceLoadScheduler.h:

Source/WebKit2:
The QuickLook framework registers a NSURLProtocol to handle loading subresources of the HTML documents it
generates. In order for these loads to succeed, we need to start them in the same process in which QuickLook
generated the main resource.

* WebProcess/Network/WebResourceLoadScheduler.cpp:
(WebKit::WebResourceLoadScheduler::scheduleLoad):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171314 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Allow MiniBrowser WK1 to do element fullscreen
https://bugs.webkit.org/show_bug.cgi?id=135125

Reviewed by Simon Fraser.

Allow WK1 windows to go fullscreen using the DOM API.

* MiniBrowser/mac/WK1BrowserWindowController.m:
(-[WK1BrowserWindowController awakeFromNib]): Enable the preference for
fullscreen.


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