[BlackBerry] Set spellchecking calculations on a timer to free up the WebKit thread
https://bugs.webkit.org/show_bug.cgi?id=107284

Reviewed by Rob Buis.

PR282351
Firing off spellcheck requests is tieing up the WebKit thread for an
extended period of time. In testing with large blocks of text, this
can be in the matter of 5-10 seconds. Though we are using asynchronous
spellchecking, the process in which we break down blocks of text based
on input_service limitations is the issue.
Using a timer here which fires with an arbitrary timeout to allow for
focus and interaction to maintain at a reasonable level.
Further, pulling this code out of InputHandler and into its own class.

Internally reviewed by Mike Fenton and Gen Mak.

* WebKitSupport/InputHandler.cpp:
(BlackBerry::WebKit::InputHandler::InputHandler):
(BlackBerry::WebKit::InputHandler::~InputHandler):
(BlackBerry::WebKit::InputHandler::callRequestCheckingFor):
(WebKit):
(BlackBerry::WebKit::InputHandler::requestCheckingOfString):
(BlackBerry::WebKit::InputHandler::spellCheckingRequestProcessed):
(BlackBerry::WebKit::InputHandler::shouldRequestSpellCheckingOptionsForPoint):
(BlackBerry::WebKit::InputHandler::setElementUnfocused):
(BlackBerry::WebKit::InputHandler::setElementFocused):
* WebKitSupport/InputHandler.h:
(WebCore):
(WebKit):
(InputHandler):
* WebKitSupport/SpellingHandler.cpp: Added.
(WebKit):
(BlackBerry::WebKit::SpellingHandler::SpellingHandler):
(BlackBerry::WebKit::SpellingHandler::~SpellingHandler):
(BlackBerry::WebKit::SpellingHandler::spellCheckTextBlock):
(BlackBerry::WebKit::SpellingHandler::createSpellCheckRequest):
(BlackBerry::WebKit::SpellingHandler::parseBlockForSpellChecking):
(BlackBerry::WebKit::SpellingHandler::getRangeForSpellCheckWithFineGranularity):
* WebKitSupport/SpellingHandler.h: Added.
(WebCore):
(WebKit):
(SpellingHandler):
(BlackBerry::WebKit::SpellingHandler::isSpellCheckActive):
(BlackBerry::WebKit::SpellingHandler::setSpellCheckActive):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@140170 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Incorrect scrollable height during simplified layout
https://bugs.webkit.org/show_bug.cgi?id=107193

Reviewed by Ojan Vafai.

Source/WebCore:

Test: fast/overflow/height-during-simplified-layout.html

When computing overflow, we use the height of the block before it was clamped
(i.e., before updateLogicalHeight() has been called).

During simplfied layout, we use the previous sizes rather than doing a full
layout. We still compute overflow, but we were using the clamped height rather
than the full height.

This caused us to incorrectly compute the overflow by the vertical padding.
Since we were passing in the already clamped clientHeight to RenderBlock::computeOverflow,
we would only include the overflow from our children sizes and not include the overflow
from ourselves caused by padding + content.

* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::simplifiedLayout): Use the scrollable height rather than the
already clamped height.

LayoutTests:

* fast/overflow/height-during-simplified-layout-expected.txt: Added.
* fast/overflow/height-during-simplified-layout.html: Added.


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