DOMTimers sometimes don't get unthrottled on scrolling
https://bugs.webkit.org/show_bug.cgi?id=138838

Reviewed by Antti Koivisto.

Source/WebCore:

DOMTimers sometimes didn't get unthrottled on scrolling. This is
because we stopped listening for viewport changes every time the
timer fires, but we didn't listen for those changes again if we
decided the timer should stay throttled after the timer's action
was executed.

We should listen for viewport changes again after executing the
timer's action, if there are elements outside the viewport causing
the DOMTimer to be throttled, even if the throttleState hasn't
changed (i.e the timer stays throttled).

Test: fast/dom/timer-unthrottle-on-scroll.html

* page/DOMTimer.cpp:
(WebCore::DOMTimer::updateThrottlingStateIfNecessary):
(WebCore::DOMTimer::updateTimerIntervalIfNecessary):
(WebCore::DOMTimer::updateThrottlingStateAfterViewportChange):

LayoutTests:

Add a layout test to verify that DOMTimers get unthrottled on scroll if
the element whose style they are changing is inside the viewport after
the scroll.

* fast/dom/timer-unthrottle-on-scroll-expected.txt: Added.
* fast/dom/timer-unthrottle-on-scroll.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176282 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS] allow host application to opt-out of alternate fullscreen
https://bugs.webkit.org/show_bug.cgi?id=138787

Reviewed by Sam Weinig.
        
"allowsAlternateFullscreen" doesn't need to be in the public WKWebView header.

* UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView initWithFrame:configuration:]): allowsAlternateFullscreen -> _allowsAlternateFullscreen.

* UIProcess/API/Cocoa/WKWebViewConfiguration.h: Remove allowsAlternateFullscreen.
* UIProcess/API/Cocoa/WKWebViewConfiguration.mm:
(-[WKWebViewConfiguration _allowsAlternateFullscreen]): New.
(-[WKWebViewConfiguration _setAllowsAlternateFullscreen:]): New.

* UIProcess/API/Cocoa/WKWebViewConfigurationPrivate.h: Declare _allowsAlternateFullscreen.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176283 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Multicolumn layout with negative line spacing and orphans causes pieces of letters to be shown at the bottom of columns
https://bugs.webkit.org/show_bug.cgi?id=138204

Source/WebCore:

Reviewed by Dave Hyatt.

This code is responsible for pushing block elements to the next column if
the "orphans" CSS property is triggered. The mechanism by which this is
achieved is to push the block down such that the origin of the block is
at the origin of the next column. However, if there is negative line
spacing, the top portion of the text might actually be on top of the
origin of the block. Therefore, the block wasn't being pushed down enough
to entirely contain its text, so the top pieces were being drawn on the
previous column.

Test: fast/multicol/orphans-negative-line-spacing.html

* rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::adjustLinePositionForPagination):

LayoutTests:

Patch by Myles C. Maxfield <litherum@gmail.com> on 2014-11-18
Reviewed by Dave Hyatt.

Create a layout where the "orphans" css property causes a block element to
be pushed to the next column.

* fast/multicol/orphans-negative-line-spacing-expected.html: Added.
* fast/multicol/orphans-negative-line-spacing.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176285 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION(r152313): Inline-block element doesn't wrap properly
https://bugs.webkit.org/show_bug.cgi?id=138846 - <rdar://problem/18838703>

Reviewed by Simon Fraser.

Source/WebCore:

Added fast/inline-block/inline-block-empty-spans.html

* rendering/line/BreakingContextInlineHeaders.h:
(WebCore::BreakingContext::canBreakAtThisPosition):

LayoutTests:

* fast/inline-block/inline-block-empty-spans-expected.html: Added.
* fast/inline-block/inline-block-empty-spans.html: Added.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176287 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Avoid re-encoding action menu image data
https://bugs.webkit.org/show_bug.cgi?id=138817
<rdar://problem/18840382>

Reviewed by Anders Carlsson.

* Shared/mac/ActionMenuHitTestResult.h:
* Shared/mac/ActionMenuHitTestResult.mm:
(WebKit::ActionMenuHitTestResult::encode):
(WebKit::ActionMenuHitTestResult::decode):
Store and encode a SharedMemory with the raw encoded image data,
instead of re-painting the image into a ShareableBitmap.

* UIProcess/mac/WKActionMenuController.mm:
(-[WKActionMenuController _hitTestResultImage]):
(-[WKActionMenuController _defaultMenuItemsForImage]):
(-[WKActionMenuController _copyImage:]):
(-[WKActionMenuController _addImageToPhotos:]):
(-[WKActionMenuController _defaultMenuItems]):
(-[WKActionMenuController _canAddMediaToPhotos]): Deleted.
Build a temporary filename from a UUID and the image's desired extension.
Use the Image's encoded data instead of re-encoding it with CGImageDestination.
Build an image menu only if we have an image, URL, data, and extension.

* WebProcess/WebPage/mac/WebPageMac.mm:
(WebKit::WebPage::performActionMenuHitTestAtLocation):

* WebView/WebActionMenuController.mm:
(-[WebActionMenuController _defaultMenuItemsForImage:]):
(-[WebActionMenuController _addImageToPhotos:]):
Build a temporary filename from a UUID and the image's desired extension.
Use the Image's encoded data instead of re-encoding it with CGImageDestination.
Build an image menu only if we have an image, URL, data, and extension.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176288 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed build fix after r176283.

* UIProcess/API/Cocoa/WKWebViewConfiguration.mm:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176289 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Removed the custom allocator for ListHashSet nodes
https://bugs.webkit.org/show_bug.cgi?id=138841

Reviewed by Andreas Kling.

Source/WebCore:

Uses of ListHashSet no longer need to declare an inline capacity,
since that was only used to specify the capacity of the custom allocator.

* dom/DOMNamedFlowCollection.h:
* dom/DocumentEventQueue.h:
* dom/DocumentStyleSheetCollection.h:
* dom/NamedFlowCollection.h:
* html/FormController.h:
* rendering/FloatingObjects.h:
* rendering/RenderBlock.h:

Source/WebKit2:

Uses of ListHashSet no longer need to declare an inline capacity,
since that was only used to specify the capacity of the custom allocator.

* UIProcess/Plugins/PluginInfoStore.cpp:
(WebKit::PluginInfoStore::loadPluginsIfNecessary):

Source/WTF:

bmalloc is fast, so we don't need a custom allocator.

The MallocBench test for linked list node allocation (list_allocate) is
4.09X faster in bmalloc than TCMalloc. Also, I wrote a stress test to
add/remove link elements, which modify a ListHashSet on insertion and
removal, and it was 1% faster / in the noise with bmalloc enabled.

* wtf/ListHashSet.h:
(WTF::ListHashSetNode::ListHashSetNode):
(WTF::ListHashSetTranslator::translate):
(WTF::U>::ListHashSet):
(WTF::=):
(WTF::U>::swap):
(WTF::U>::~ListHashSet):
(WTF::U>::size):
(WTF::U>::capacity):
(WTF::U>::isEmpty):
(WTF::U>::first):
(WTF::U>::removeFirst):
(WTF::U>::takeFirst):
(WTF::U>::last):
(WTF::U>::removeLast):
(WTF::U>::takeLast):
(WTF::U>::contains):
(WTF::U>::remove):
(WTF::U>::clear):
(WTF::U>::unlink):
(WTF::U>::unlinkAndDelete):
(WTF::U>::appendNode):
(WTF::U>::prependNode):
(WTF::U>::insertNodeBefore):
(WTF::U>::deleteAllNodes):
(WTF::ListHashSetNodeAllocator::ListHashSetNodeAllocator): Deleted.
(WTF::ListHashSetNodeAllocator::allocate): Deleted.
(WTF::ListHashSetNodeAllocator::deallocate): Deleted.
(WTF::ListHashSetNodeAllocator::pool): Deleted.
(WTF::ListHashSetNodeAllocator::pastPool): Deleted.
(WTF::ListHashSetNodeAllocator::inPool): Deleted.
(WTF::ListHashSetNode::operator new): Deleted.
(WTF::ListHashSetNode::destroy): Deleted.


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