Consolidate FrameLoader::load() into one function taking a FrameLoadRequest
https://bugs.webkit.org/show_bug.cgi?id=102151

Reviewed by Adam Barth.

Source/WebCore:

There's a FIXME that we have too many FrameLoader::load*() functions. This patch consolidates 3 into 1.
There are still a few more load functions that will be consolidated later. Using FrameLoadRequest as
the interface into FrameLoader will also provide a place to pass in the initiator. Finally, this matches
the refactoring done with CachedResourceRequest and CachedResourceLoader.

No new tests. No change in functionality.

* WebCore.exp.in:
* loader/FrameLoadRequest.h:
(WebCore::FrameLoadRequest::FrameLoadRequest):
(WebCore::FrameLoadRequest::setLockHistory): These are former arguments to load().
(WebCore::FrameLoadRequest::lockHistory): Ditto.
(FrameLoadRequest):
(WebCore::FrameLoadRequest::setShouldCheckNewWindowPolicy): Ditto.
(WebCore::FrameLoadRequest::shouldCheckNewWindowPolicy): Ditto.
(WebCore::FrameLoadRequest::substituteData): Ditto.
(WebCore::FrameLoadRequest::setSubstituteData): Ditto.
(WebCore::FrameLoadRequest::hasSubstituteData): Ditto.
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::load): No change in behavior, just merged it all into one function.
* loader/FrameLoader.h:
(FrameLoader):
* page/DragController.cpp:
(WebCore::DragController::performDrag):

Source/WebKit/blackberry:

* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::load):
(BlackBerry::WebKit::WebPagePrivate::loadString):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDidFailProvisionalLoad):

Source/WebKit/chromium:

* src/WebFrameImpl.cpp:
(WebKit::WebFrameImpl::loadRequest):
(WebKit::WebFrameImpl::loadData):
* src/WebSharedWorkerImpl.cpp:
(WebKit::WebSharedWorkerImpl::initializeLoader):

Source/WebKit/efl:

* ewk/ewk_frame.cpp:
(_ewk_frame_contents_set_internal):

Source/WebKit/gtk:

* webkit/webkitwebframe.cpp:
(webkit_web_frame_load_uri):
(webkit_web_frame_load_data):
(webkit_web_frame_load_request):

Source/WebKit/mac:

* Plugins/WebPluginController.mm:
* WebView/WebFrame.mm:
(-[WebFrame loadRequest:]):
(-[WebFrame _loadData:MIMEType:textEncodingName:baseURL:unreachableURL:]):

Source/WebKit/qt:

* Api/qwebframe.cpp:
(QWebFrame::QWebFrame):
(QWebFrame::load):
(QWebFrame::setHtml):
(QWebFrame::setContent):
* WebCoreSupport/DumpRenderTreeSupportQt.cpp:
(DumpRenderTreeSupportQt::setAlternateHtml):
(qt_dump_set_accepts_editing):
* WebCoreSupport/FrameLoaderClientQt.cpp:
(WebCore::FrameLoaderClientQt::callErrorPageExtension):

Source/WebKit/win:

* WebFrame.cpp:
(WebFrame::loadRequest):
(WebFrame::loadData):

Source/WebKit/wince:

* WebView.cpp:
(WebView::load):

Source/WebKit/wx:

* WebFrame.cpp:
(WebKit::WebFrame::SetPageSource):

Source/WebKit2:

* WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::performFrameLoadURLRequest):
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::loadURLRequest):
(WebKit::WebPage::loadData):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135786 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add hasTouchEventhandlersAt to WebView API
https://bugs.webkit.org/show_bug.cgi?id=102541

Patch by Yusuf Ozuysal <yusufo@google.com> on 2012-11-26
Reviewed by James Robinson.

Adds hasTouchEventHandlersAt to WebWidget API to check for touch event handlers at a
given point. This will be used to distinguish between events not processed by
touch event handlers and event not hitting any touch event handlers. Both are
returning the same ACK message currently. Default implementation returns true to
continue the same behavior as we currently have.

* public/WebWidget.h:
(WebWidget):
(WebKit::WebWidget::hasTouchEventHandlersAt):
* src/WebViewImpl.cpp:
(WebKit::WebViewImpl::hasTouchEventHandlersAt):
(WebKit):
* src/WebViewImpl.h:
(WebViewImpl):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135787 268f45cc-cd09-0410-ab3c-d52691b4dbfc
RenderStyle: Move 'list-style-image' to rare inherited data.
<http://webkit.org/b/103300>

Reviewed by Antti Koivisto.

list-style-image is not nearly common enough to merit a spot in StyleInheritedData.
Move it to StyleRareInheritedData.

134kB progression on Membuster3.

* rendering/style/RenderStyle.cpp:
(WebCore::RenderStyle::diff):
(WebCore::RenderStyle::listStyleImage):
(WebCore::RenderStyle::setListStyleImage):
* rendering/style/StyleInheritedData.cpp:
(WebCore::StyleInheritedData::StyleInheritedData):
(WebCore::StyleInheritedData::operator==):
* rendering/style/StyleInheritedData.h:
(StyleInheritedData):
* rendering/style/StyleRareInheritedData.h:
* rendering/style/StyleRareInheritedData.cpp:
(SameSizeAsStyleRareInheritedData):
(WebCore::StyleRareInheritedData::StyleRareInheritedData):
(WebCore::StyleRareInheritedData::operator==):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135788 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LongPress and LongTap gestures should start drag/drop and open context menu respectively.
https://bugs.webkit.org/show_bug.cgi?id=101545

Patch by Varun Jain <varunjain@chromium.org> on 2012-11-26
Reviewed by Antonio Gomes.

For LongPress, we simulate drag by sending a mouse down and mouse drag
events. If a drag is not started (because maybe there is no draggable
element), then we show context menu instead (which is the current
behavior for LongPress). For LongTap, we use the existing functions that
LongPress uses to summon the context menu. LongPress initiated drag and
drop can be enabled/disabled by the platform using the Setting
touchDragDropEnabled which is disabled by default.

Source/WebCore:

Tests: fast/events/touch/gesture/context-menu-on-long-tap.html
       fast/events/touch/gesture/long-press-on-draggable-element-triggers-drag.html

* page/EventHandler.cpp:
(WebCore::EventHandler::EventHandler):
(WebCore::EventHandler::clear):
(WebCore::EventHandler::handleMouseDraggedEvent):
(WebCore::EventHandler::handleGestureEvent):
(WebCore::EventHandler::handleGestureLongPress):
(WebCore::EventHandler::handleGestureLongTap):
(WebCore):
(WebCore::EventHandler::handleGestureForTextSelectionOrContextMenu):
(WebCore::EventHandler::adjustGesturePosition):
(WebCore::EventHandler::handleDrag):
* page/EventHandler.h:
(EventHandler):
* page/Settings.in:

Source/WebKit/chromium:

* public/WebSettings.h:
* src/WebSettingsImpl.cpp:
(WebKit::WebSettingsImpl::setTouchDragDropEnabled):
(WebKit):
* src/WebSettingsImpl.h:
(WebSettingsImpl):

Tools:

* DumpRenderTree/chromium/TestRunner/src/EventSender.cpp:
(WebTestRunner):
(WebTestRunner::EventSender::EventSender):
(WebTestRunner::EventSender::gestureLongTap):
(WebTestRunner::EventSender::gestureEvent):
* DumpRenderTree/chromium/TestRunner/src/EventSender.h:
(EventSender):
* DumpRenderTree/chromium/TestRunner/src/TestRunner.cpp:
(WebTestRunner::TestRunner::TestRunner):
(WebTestRunner::TestRunner::setTouchDragDropEnabled):
(WebTestRunner):
* DumpRenderTree/chromium/TestRunner/src/TestRunner.h:
(TestRunner):

LayoutTests:

* fast/events/touch/gesture/context-menu-on-long-tap.html: Added.
* fast/events/touch/gesture/long-press-on-draggable-element-triggers-drag.html: Added.
* platform/chromium/fast/events/touch/gesture/context-menu-on-long-tap-expected.txt: Added.
* platform/chromium/fast/events/touch/gesture/long-press-on-draggable-element-triggers-drag-expected.txt: Added.
* touchadjustment/touch-links-longpress-expected.txt:
* touchadjustment/touch-links-longpress.html:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135789 268f45cc-cd09-0410-ab3c-d52691b4dbfc
DataLog to a file should work if there are multiple processes using WTF
https://bugs.webkit.org/show_bug.cgi?id=103323

Reviewed by Mark Hahnenberg.

Whereas before DataLog would open a file with the name you specified, now it'll open a file with the
name plus the PID appended to it. So if you are dealing with multiple processes running with DataLog
to a file enabled, you'll get multiple separate log files.

* wtf/DataLog.cpp:
(WTF::initializeLogFileOnce):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135790 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL] Unreviewed build fix after r135767 without Tiled Backing Store
https://bugs.webkit.org/show_bug.cgi?id=103320

Unreviewed build fix.

Patch by Ryuan Choi <ryuan.choi@gmail.com> on 2012-11-26

* WebProcess/Plugins/Plugin.cpp:
* WebProcess/Plugins/Plugin.h:
(WebCore):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135791 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[V8] Refactor WorkerScriptController
https://bugs.webkit.org/show_bug.cgi?id=103330

Reviewed by Adam Barth.

r135703 just moved methods from WorkerContextExecutionProxy
to WorkerScriptController. We should refactor the methods as a follow-up.

No tests. No change in behavior.

* bindings/v8/WorkerScriptController.cpp:
(WebCore::WorkerScriptController::~WorkerScriptController):
(WebCore::WorkerScriptController::disposeContext):
(WebCore::WorkerScriptController::initializeContextIfNeeded):
(WebCore::WorkerScriptController::evaluate):
(WebCore::WorkerScriptController::disableEval):
* bindings/v8/WorkerScriptController.h:
(WorkerScriptController):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135792 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Node: Remove IsSynchronizingSVGAttributesFlag.
<http://webkit.org/b/103328>

Reviewed by Antti Koivisto.

Animated SVG attributes used to be synchronized by using DOM API which could use unwanted re-entrancy
via callbacks below Element::attributeChanged(). The "is synchronizing SVG attributes" flag was used
to protect against such re-entrancy.

These days, lazy attributes are synchronized using Element::setSynchronizedLazyAttribute() to avoid
issues like this. The flag does nothing, so we can just remove it.

* dom/Node.h:
(WebCore):
* svg/SVGElement.cpp:
(WebCore::SVGElement::attributeChanged):
(WebCore::SVGElement::updateAnimatedSVGAttribute):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135793 268f45cc-cd09-0410-ab3c-d52691b4dbfc
JavaScript fails to handle String.replace() with large replacement string
https://bugs.webkit.org/show_bug.cgi?id=102956
<rdar://problem/12738012>

Reviewed by Oliver Hunt.

Source/JavaScriptCore: 

Fix an issue where we didn't check for overflow when computing the length
of the result of String.replace() with a large replacement string.

* runtime/StringPrototype.cpp:
(JSC::jsSpliceSubstringsWithSeparators):

LayoutTests: 

Add test to ensure that we handle string replacement with a large replacement string.

* fast/js/script-tests/string-replacement-outofmemory.js: Added.
(createStringWithRepeatedChar):
* fast/js/string-replacement-outofmemory-expected.txt: Added.
* fast/js/string-replacement-outofmemory.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135794 268f45cc-cd09-0410-ab3c-d52691b4dbfc
PDFPlugin: Ctrl-click opens a link in a PDF in addition to context menu
https://bugs.webkit.org/show_bug.cgi?id=103282
<rdar://problem/12710892>

Reviewed by Dan Bernstein.

Don't send standard mouse events to PDFKit if a click will also show/hide the context menu.

* WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::handleMouseEvent):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135795 268f45cc-cd09-0410-ab3c-d52691b4dbfc
PDFPlugin: Subframe PDF context menus are in the wrong place
https://bugs.webkit.org/show_bug.cgi?id=103284
<rdar://problem/12727972>

Reviewed by Dan Bernstein.

Event position is in window coordinates, not content coordinates.
Since we have no windowToScreen(), use windowToContents and contentsToScreen
to get to screen coordinate space, which WKPopupContextMenu wants.

* WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::handleContextMenuEvent):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135796 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Ensure that plugins are initialized before using handleEditingCommand/isEditingCommandEnabled/shouldAllowScripting
https://bugs.webkit.org/show_bug.cgi?id=103288

Reviewed by Dan Bernstein.

Other PluginView methods that use m_plugin null-check m_plugin and check
that the plugin has finished initializing before using it. These three
should do the same thing.

* WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::handleEditingCommand):
(WebKit::PluginView::isEditingCommandEnabled):
(WebKit::PluginView::shouldAllowScripting):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135797 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Implement full-featured image cache
https://bugs.webkit.org/show_bug.cgi?id=99784

Reviewed by James Robinson.

Source/WebCore:

Implement a thread-safe image cache to be used with deferred image
decoding. Image cache can now be accessed on any thread.

The patch implements the following logic:
1. Mutex to protect all cache operations.
2. Cache indexing using key (ImageFrameGenerator*, SkISize scaledSize)
3. Cache lookup.
4. Cache insertion.
5. Generation of cache entry by scaling full size image.
6. Generation of cache entries by decoding and scaling.

Classes involved:

ImageDecodingStore

Responsible for owning cache entries and indexing. Pruning and memory
management will be added later.

ImageFrameGenerator

Responsible for generating new cache enties and insert them into
ImageDecodingStore.

LazyDecodingPixelRef

Responsible for cache lookup and lazy generation of cache entries
using ImageFrameGenerator. There is a mutex to protect concurrent
lock operations.

These items are not implemented in this patch:
1. Cache pruning.
2. Setting cache memory limit.
3. Cache deletion.
4. Caching incomplete images and ImageDecoder.

Unit tests added in ImageFrameGeneratorTest.cpp.
Layout tests are under platform/chromium/virtual/fast/images.

* platform/graphics/chromium/DeferredImageDecoder.cpp:
(WebCore::DeferredImageDecoder::~DeferredImageDecoder):
(WebCore::DeferredImageDecoder::createResizedLazyDecodingBitmap):
(WebCore::DeferredImageDecoder::setEnabled):
(WebCore):
(WebCore::DeferredImageDecoder::frameBufferAtIndex):
(WebCore::DeferredImageDecoder::createLazyDecodingBitmap):
* platform/graphics/chromium/DeferredImageDecoder.h:
(DeferredImageDecoder):
* platform/graphics/chromium/ImageDecodingStore.cpp:
(WebCore::ImageDecodingStore::instance):
(WebCore::ImageDecodingStore::initializeOnce):
(WebCore::ImageDecodingStore::shutdown):
(WebCore::ImageDecodingStore::lockCompleteCache):
Lookup complete cache entry using hash key, increment use count.
(WebCore::ImageDecodingStore::lockIncompleteCache): TODO.
(WebCore::ImageDecodingStore::unlockCache):
Lookup cache entry using hash key, decrement use count.
(WebCore):
(WebCore::ImageDecodingStore::insertAndLockCache):
Insert new cache entry and increment use count.
(WebCore::ImageDecodingStore::prune): TODO.
* platform/graphics/chromium/ImageDecodingStore.h:
(WebCore):
(ImageDecodingStore):
(WebCore::ImageDecodingStore::CacheEntry::create):
(WebCore::ImageDecodingStore::CacheEntry::createAndUse):
(CacheEntry):
(WebCore::ImageDecodingStore::CacheEntry::CacheEntry):
(WebCore::ImageDecodingStore::CacheEntry::~CacheEntry):
* platform/graphics/chromium/ImageFrameGenerator.cpp:
(WebCore::ImageFrameGenerator::ImageFrameGenerator):
(WebCore::ImageFrameGenerator::setData):
(WebCore::ImageFrameGenerator::decodeAndScale):
Method for creating new cache entries. This is protected by a mutex
to prevent concurrent operations. Which means only one thread can
generate new cache entries for a set of encoded data.
(WebCore):
(WebCore::ImageFrameGenerator::tryToLockCache):
Tries to lookup a cache entry.
(WebCore::ImageFrameGenerator::tryToScale):
Tries to lookup a full size cache entry and generate a scaled version.
(WebCore::ImageFrameGenerator::tryToDecodeAndScale):
Tries to decode and scale.
* platform/graphics/chromium/ImageFrameGenerator.h:
(WebCore):
(ImageDecoderFactory):
(WebCore::ImageFrameGenerator::create):
(ImageFrameGenerator):
(WebCore::ImageFrameGenerator::setImageDecoderFactoryForTesting):
* platform/graphics/chromium/LazyDecodingPixelRef.cpp:
(WebCore::LazyDecodingPixelRef::LazyDecodingPixelRef):
(WebCore::LazyDecodingPixelRef::onLockPixels):
(WebCore::LazyDecodingPixelRef::onUnlockPixels):
* platform/graphics/chromium/LazyDecodingPixelRef.h:
(WebCore):
(LazyDecodingPixelRef):
* platform/graphics/chromium/ScaledImageFragment.cpp:
(WebCore::ScaledImageFragment::ScaledImageFragment):
* platform/graphics/chromium/ScaledImageFragment.h:
(WebCore):
(WebCore::ScaledImageFragment::create):
(ScaledImageFragment):
(WebCore::ScaledImageFragment::scaledSize):
* platform/graphics/chromium/SkSizeHash.h: Added.
(WTF):

Source/WebKit/chromium:

Added ImageFrameGeneratorTest to test cache logic and generation
of new cache entries.

ImageFrameGeneratorTest.cacheHit
Test that a complete cached entry is reused.

ImageFrameGeneratorTest.cacheMissWithScale
Cache miss for a scaled image but cache hit on a full size image.
Scaled image is created from cached full size image.

ImageFrameGeneratorTest.cacheMissWithDecodeAndScale
Cache miss for both scaled image and full size image.

ImageFrameGeneratorTest.cacheMissWithIncompleteDecode
Test the logic for handling incomplete cache objects.

* WebKit.gypi:
* src/WebKit.cpp:
(WebKit::initializeWithoutV8):
* src/WebSettingsImpl.cpp:
(WebKit::WebSettingsImpl::setDeferredImageDecodingEnabled):
* tests/DeferredImageDecoderTest.cpp:
(WebCore::DeferredImageDecoderTest::SetUp):
(WebCore::DeferredImageDecoderTest::decoderBeingDestroyed):
(WebCore::DeferredImageDecoderTest::frameBufferRequested):
(DeferredImageDecoderTest):
(WebCore::DeferredImageDecoderTest::frameStatus):
* tests/ImageFrameGeneratorTest.cpp: Added.
(WebCore):
(WebCore::fullSize):
(WebCore::scaledSize):
(MockImageDecoderFactory):
(WebCore::MockImageDecoderFactory::create):
(WebCore::MockImageDecoderFactory::MockImageDecoderFactory):
(ImageFrameGeneratorTest):
(WebCore::ImageFrameGeneratorTest::SetUp):
(WebCore::ImageFrameGeneratorTest::TearDown):
(WebCore::ImageFrameGeneratorTest::decoderBeingDestroyed):
(WebCore::ImageFrameGeneratorTest::frameBufferRequested):
(WebCore::ImageFrameGeneratorTest::frameStatus):
(WebCore::ImageFrameGeneratorTest::createCompleteImage):
(WebCore::ImageFrameGeneratorTest::setFrameStatus):
(WebCore::TEST_F):
* tests/MockImageDecoder.h:
(MockImageDecoderClient):
(WebCore::MockImageDecoder::frameBufferAtIndex):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135798 268f45cc-cd09-0410-ab3c-d52691b4dbfc
PNG decode performance: avoid using frame buffer.setRGBA(x,y)
https://bugs.webkit.org/show_bug.cgi?id=103216

Reviewed by Brent Fulgham.

Writing decoded row pixels to the frame buffer with buffer.setRGBA(x,y) is slow compared
to writing direct to the frame buffer address. Use buffer.getAddr() to obtain the output
pixel row address, write the decoded row pixels to that address.

No new tests. Covered by many existing tests.

* platform/image-decoders/ImageDecoder.h:
(WebCore::ImageFrame::setRGBA): Make routine setRGBA(PixelData* dest, ...) public. Test
m_premultiplyAlpha once to minimize code branching in this routine.
* platform/image-decoders/png/PNGImageDecoder.cpp:
(WebCore::PNGImageDecoder::rowAvailable): Write decoded row pixels to the frame buffer
using the pixel address form: buffer.setRGBA(address++, ...).


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135799 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Substitute "allSeparators8Bit" for "allSeperators8Bit" in JSC::jsSpliceSubstringsWithSeparators()
<https://bugs.webkit.org/show_bug.cgi?id=103303>

Reviewed by Simon Fraser.

Fix misspelled word, "Seperators" [sic], in a local variable name in JSC::jsSpliceSubstringsWithSeparators().

* runtime/StringPrototype.cpp:
(JSC::jsSpliceSubstringsWithSeparators):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135800 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Remove deprecated and unused WebGraphicsContext3D compositor binding calls
https://bugs.webkit.org/show_bug.cgi?id=103322

Patch by James Robinson <jamesr@chromium.org> on 2012-11-26
Reviewed by Adam Barth.

Source/Platform:

These have been uncalled for a while.

* chromium/public/WebLayerTreeViewClient.h:
(WebLayerTreeViewClient):

Source/WebKit/chromium:

* src/WebViewImpl.cpp:
* src/WebViewImpl.h:
(WebViewImpl):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135801 268f45cc-cd09-0410-ab3c-d52691b4dbfc
HTML/XML parser helper unconsumeCharacters() can push back 8 bit text as 16 bit text
https://bugs.webkit.org/show_bug.cgi?id=103317

Reviewed by Oliver Hunt.

Changed to use the String directly from the StringBuilder instead of creating our own.
Used toStringPreserveCapacity() in case the caller may want to add to the StringBuilder
even though current callers don't.

No new tests. No change in functionality.

* xml/parser/CharacterReferenceParserInlines.h:
(WebCore::unconsumeCharacters):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135802 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WK2] Expose Accelerated2dCanvas flag set and get in WebKit2
https://bugs.webkit.org/show_bug.cgi?id=103008

Patch by Kyungjin Kim <gen.kim@samsung.com> on 2012-11-26
Reviewed by Gyuyoung Kim.

Add setting APIs for accelerated 2d canvas in WebKit2.

* Shared/WebPreferencesStore.h:
(WebKit):
* UIProcess/API/C/WKPreferences.cpp:
(WKPreferencesSetAccelerated2dCanvasEnabled):
(WKPreferencesGetAccelerated2dCanvasEnabled):
* UIProcess/API/C/WKPreferencesPrivate.h:
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::updatePreferences):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135803 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Check for empty perContextData while creating NP V8 Object.
https://bugs.webkit.org/show_bug.cgi?id=98448

Patch by Istiaque Ahmed <lazyboy@chromium.org> on 2012-11-26
Reviewed by Adam Barth.

Fixes crash in npCreateV8ScriptObject(), if NP Invoke is called from a document
that is no longer displayed in frame (isCurrentlyDisplayedInFrame() ==
false), we have empty perContextData and this results in invalid memory access.

Source/WebCore:

Test: platform/chromium/plugins/empty-per-context-data.html

* bindings/v8/NPV8Object.cpp:
(WebCore::npCreateV8ScriptObject):

LayoutTests:

* platform/chromium/plugins/empty-per-context-data-expected.txt: Added.
* platform/chromium/plugins/empty-per-context-data.html: Added.
* platform/chromium/plugins/resources/script-container.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@135804 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Grapheme cluster functions can be simplified for 8 bit Strings
https://bugs.webkit.org/show_bug.cgi?id=102996

Reviewed by Alexey Proskuryakov.

For 8 bit strings, check for the uncommon CR-LF by looking for any CR.  If there aren't any CR characters,
the number of Extended Grapheme Clusters is equal to the string length.  If we need to handle Tailored
Graheme Clusters, then this will need to change.

No new tests. No change in functionality.

* platform/text/TextBreakIterator.cpp:
(WebCore::numGraphemeClusters):
(WebCore::numCharactersInGraphemeClusters):


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