DragController should ascertain dragClient to be non-null
https://bugs.webkit.org/show_bug.cgi?id=92474

Patch by Vivek Galatage <vivekgalatage@gmail.com> on 2012-07-27
Reviewed by Tony Chang.

The DragController must always ensure a valid dragClient object. Hence
adding the ASSERT to assure that.

No new tests. Added assertion for PageClient.dragClient.

* page/DragController.cpp:
(WebCore::DragController::DragController):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123927 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Build warning in CSSPrimitiveValueMappings.h when CSS_STICKY_POSITION is disabled
https://bugs.webkit.org/show_bug.cgi?id=92523

Patch by Christophe Dumez <christophe.dumez@intel.com> on 2012-07-27
Reviewed by Simon Fraser.

Move #ifdef in CSSPrimitiveValueMappings.h to silent compilation warning
when CSS_STICKY_POSITION is disabled.

No new tests, no behavior change.

* css/CSSPrimitiveValueMappings.h:
(WebCore::CSSPrimitiveValue::CSSPrimitiveValue):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123928 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WINCE] Use macros from ICU instead of defining the same functionality again
https://bugs.webkit.org/show_bug.cgi?id=92530

Patch by Patrick Gansterer <paroga@webkit.org> on 2012-07-27
Reviewed by Ryosuke Niwa.

Replace isHighSurrogate() with U16_IS_LEAD(), isLowSurrogate() with
U16_IS_TRAIL() and surrogateToUcs4() with U16_GET_SUPPLEMENTARY().

Source/WebCore:

* html/FTPDirectoryDocument.cpp:
(WebCore::processFileDateString):
* loader/archive/mhtml/MHTMLArchive.cpp:
(WebCore::MHTMLArchive::generateMHTMLData):
* platform/graphics/wince/FontWinCE.cpp:
(WebCore::generateComponents):

Source/WTF:

* wtf/unicode/wince/UnicodeWinCE.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123929 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add diagnostic logging for plugins-per-page.
https://bugs.webkit.org/show_bug.cgi?id=92538

Reviewed by Anders Carlsson.

Add some diagnostic logging for whether a page has seen a plugin, and
whether a page has seen a plugin of a specific type.

Move the diagnostic logging out of the elemements themselves:
* html/HTMLEmbedElement.cpp:
(WebCore::HTMLEmbedElement::updateWidget):
* html/HTMLObjectElement.cpp:
(WebCore::HTMLObjectElement::updateWidget):

Instead, log when the plugin is requested, thereby catching plugins which are
rejected because, e.g., Java is disabled or not installed:
* loader/SubframeLoader.cpp:
(WebCore::logPluginRequest):
(WebCore::SubframeLoader::requestObject):
(WebCore::SubframeLoader::createJavaAppletWidget):

Add new diagnostic key values:
* page/DiagnosticLoggingKeys.cpp:
(WebCore::DiagnosticLoggingKeys::pageContainsPluginKey):
(WebCore::DiagnosticLoggingKeys::pageContainsAtLeastOnePluginKey):
* page/DiagnosticLoggingKeys.h:

Add a map of plugin types seen per-page for diagnostic purposes:
* page/Page.cpp:
(WebCore::Page::hasSeenAnyPlugin):
(WebCore::Page::hasSeenPlugin):
(WebCore::Page::sawPlugin):
* page/Page.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123930 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Split functionality of MarkedAllocator::m_currentBlock
https://bugs.webkit.org/show_bug.cgi?id=92550

Reviewed by Filip Pizlo.

MarkedAllocator::m_currentBlock serves two purposes right now; it indicates the block that is currently 
being used for allocation and the beginning of the list of blocks that need to be swept. We should split 
these two functionalities into two separate fields.

* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::tryAllocateHelper): Use m_blocksToSweep instead of m_currentBlock as the 
initializer/reference of the loop. Only change m_currentBlock when we know what the result will be.
(JSC::MarkedAllocator::addBlock): When we add a new block we know that both m_blocksToSweep and 
m_currentBlock are null. In order to preserve the invariant that m_currentBlock <= m_blocksToSweep, 
we assign both of them to point to the new block.
(JSC::MarkedAllocator::removeBlock): We need a separate check to see if the block we're removing is 
m_blocksToSweep and if so, advance it to the next block in the list.
* heap/MarkedAllocator.h:
(MarkedAllocator): Initialize m_blocksToSweep.
(JSC::MarkedAllocator::MarkedAllocator):
(JSC::MarkedAllocator::reset): We set m_blocksToSweep to be the head of our list. This function is called
at the end of a collection, so all of the blocks in our allocator need to be swept. We need to sweep a 
block before we can start allocating, so m_currentBlock is set to null. We also set the freeList to 
the empty FreeList to emphasize the fact that we can't start allocating until we do some sweeping.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123931 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Fix color matrix filter computation so that filters that don't need clamping are correctly detected as such
https://bugs.webkit.org/show_bug.cgi?id=92452

Patch by Antoine Labour <piman@chromium.org> on 2012-07-27
Reviewed by Stephen White.

Because of precision issues, some filters were returning true to
matrixNeedsClamping when they can return false. This fixes it.

No new tests in this CL, a follow-up change refactors the code to add
several tests.

* platform/graphics/chromium/cc/CCRenderSurfaceFilters.cpp:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123932 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL][WK2] Assertion hit in ewk_cookie_manager.cpp
https://bugs.webkit.org/show_bug.cgi?id=92544

Patch by Christophe Dumez <christophe.dumez@intel.com> on 2012-07-27
Reviewed by Kenneth Rohde Christiansen.

Removed wrong assertion in ewk_cookie_manager.cpp
and replace it by an if check. The assertion was
sometimes hit by our unit tests.

* UIProcess/API/efl/ewk_cookie_manager.cpp:
(cookiesDidChange):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123933 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Adapt to change in the FontInfo platform API.
https://bugs.webkit.org/show_bug.cgi?id=92547

Patch by Eli Fidler <efidler@rim.com> on 2012-07-27
Reviewed by Yong Li

RIM PR 161263

Source/WebCore:

* page/blackberry/SettingsBlackBerry.cpp:
(WebCore::Settings::initializeDefaultFontFamilies):

Source/WebKit/blackberry:

* Api/WebSettings.cpp:
(BlackBerry::WebKit::WebSettings::standardSettings):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123934 268f45cc-cd09-0410-ab3c-d52691b4dbfc
use createUninitialized when creating TypedArray from another array
https://bugs.webkit.org/show_bug.cgi?id=92518

Patch by Arnaud Renevier <a.renevier@sisa.samsung.com> on 2012-07-27
Reviewed by Kenneth Russell.

PerformanceTests:

* Bindings/typed-array-construct-from-array.html: Added.

Source/WebCore:

When creating a Typed Array from another array, we fill it with values
from the source array. So, we can create it uninitialized. This is
make constructor about 35% faster when constructed with another typed
array.

Test: fast/canvas/webgl/array-constructor.html

* bindings/js/JSArrayBufferViewHelper.h:
(WebCore::constructArrayBufferViewWithTypedArrayArgument):
(WebCore::constructArrayBufferView):

Source/WTF:

Expose a createUninitialized static method on TypedArray classes.

* wtf/Float32Array.h:
(Float32Array):
(WTF::Float32Array::createUninitialized):
(WTF):
* wtf/Float64Array.h:
(Float64Array):
(WTF::Float64Array::createUninitialized):
(WTF):
* wtf/Int16Array.h:
(Int16Array):
(WTF::Int16Array::createUninitialized):
(WTF):
* wtf/Int32Array.h:
(Int32Array):
(WTF::Int32Array::createUninitialized):
(WTF):
* wtf/Int8Array.h:
(Int8Array):
(WTF::Int8Array::createUninitialized):
(WTF):
* wtf/Uint16Array.h:
(Uint16Array):
(WTF::Uint16Array::createUninitialized):
(WTF):
* wtf/Uint32Array.h:
(Uint32Array):
(WTF::Uint32Array::createUninitialized):
(WTF):
* wtf/Uint8Array.h:
(Uint8Array):
(WTF::Uint8Array::createUninitialized):
(WTF):
* wtf/Uint8ClampedArray.h:
(Uint8ClampedArray):

LayoutTests:

Add test to check that constructing a Typed Array with nan values does
not result in random values.

* fast/canvas/webgl/array-constructor-expected.txt: Added.
* fast/canvas/webgl/array-constructor.html: Added.

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