[BlackBerry] Maintain the directionality of the selection after modifying the selection using key events.
https://bugs.webkit.org/show_bug.cgi?id=111078

Reviewed by Yong Li.

PR 295224.

When using the key navigation to modify the selection, reset the
directionality of the selection to the original to prevent
changing the anchor.

Reviewed Internally by Nima Ghanavatian.

* WebKitSupport/SelectionHandler.cpp:
(BlackBerry::WebKit::SelectionHandler::updateOrHandleInputSelection):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144355 268f45cc-cd09-0410-ab3c-d52691b4dbfc
CodeBlock::valueProfile() has a bogus assertion
https://bugs.webkit.org/show_bug.cgi?id=111106
<rdar://problem/13131427>

Reviewed by Mark Hahnenberg.
        
This was just a bad assertion: m_bytecodeOffset == -1 means that the value profile is constructed but not initialized.
ValueProfile constructs itself in a safe way; you can call any method you want on a constructed but not initialized
ValueProfile. CodeBlock first constructs all ValueProfiles (by growing the ValueProfile vector) and then initializes
their m_bytecodeOffset later. This is necessary because the initialization is linking bytecode instructions to their
ValueProfiles, so at that point we don't want the ValueProfile vector to resize, which implies that we want all of
them to already be constructed. A GC can happen during this phase, and the GC may want to walk all ValueProfiles.
This is safe, but one of the ValueProfile getters (CodeBlock::valueProfile()) was asserting that any value profile
you get has had its m_bytecodeOffset initialized. This need not be the case and nothing will go wrong if it isn't.

The solution is to remove the assertion, which I believe was put there to ensure that my m_valueProfiles refactoring
a long time ago was sound: it used to be that a ValueProfile with m_bytecodeOffset == -1 was an argument profile; now
all argument profiles are in m_argumentValueProfiles instead. I think it's safe to say that this refactoring was done
soundly since it was a long time ago. So we should kill the assertion - I don't see an easy way to make the assertion
sound with respect to the GC-during-CodeBlock-construction issue, and I don't believe that the assertion is buying us
anything at this point.

* bytecode/CodeBlock.h:
(JSC::CodeBlock::valueProfile):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144356 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL][WebGL] Enable compositing/webgl/webgl-reflection.html.
https://bugs.webkit.org/show_bug.cgi?id=110688

Patch by Kondapally Kalyan <kalyan.kondapally@intel.com> on 2013-02-28
Reviewed by Laszlo Gombos.

This patch adds platform specific test expectation files for the
test and enables it for efl port.

* platform/efl/TestExpectations:
* platform/efl/compositing/webgl/webgl-reflection-expected.png: Added.
* platform/efl/compositing/webgl/webgl-reflection-expected.txt: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144357 268f45cc-cd09-0410-ab3c-d52691b4dbfc
EXT_draw_buffers needs implementation
https://bugs.webkit.org/show_bug.cgi?id=109331

Reviewed by Kenneth Russell.

Source/Platform: 

Add EXT_draw_buffers support for chromium port.

* chromium/public/WebGraphicsContext3D.h:
(WebGraphicsContext3D):
(WebKit::WebGraphicsContext3D::drawBuffersEXT):

Source/WebCore: 

This patch adds support for EXT_draw_buffers for WebGL.
mac OpenGL port is passing khronos WebGL conformance test with this patch. OpenGL ES port implementation isn't added in this patch.
Also, it has the WebKit side support for chromium port, but pending command buffer implementation.

Besides the basic extension implementation, we also added drawBuffers() wrapper to work around a mac driver bug: i.e., do not enable a buffer if there is no attachment added.

* CMakeLists.txt:
* DerivedSources.make:
* DerivedSources.pri:
* GNUmakefile.list.am:
* Target.pri:
* WebCore.gypi:
* WebCore.xcodeproj/project.pbxproj:
* bindings/js/JSWebGLRenderingContextCustom.cpp:
(WebCore::toJS):
* bindings/v8/V8Binding.h:
(WebCore):
(WebCore::toInt32):
(WebCore::toUInt32):
(WebCore::toFloat):
(WebCore::toInt64):
* bindings/v8/custom/V8WebGLRenderingContextCustom.cpp:
(WebCore::toV8Object):
* html/canvas/EXTDrawBuffers.cpp: Added.
(WebCore):
(WebCore::EXTDrawBuffers::EXTDrawBuffers):
(WebCore::EXTDrawBuffers::~EXTDrawBuffers):
(WebCore::EXTDrawBuffers::getName):
(WebCore::EXTDrawBuffers::create):
(WebCore::EXTDrawBuffers::supported):
(WebCore::EXTDrawBuffers::drawBuffersEXT):
* html/canvas/EXTDrawBuffers.h: Added.
(WebCore):
(EXTDrawBuffers):
* html/canvas/EXTDrawBuffers.idl: Added.
* html/canvas/WebGLExtension.h:
* html/canvas/WebGLFramebuffer.cpp:
(WebCore::WebGLFramebuffer::setAttachmentForBoundFramebuffer):
(WebCore::WebGLFramebuffer::removeAttachmentFromBoundFramebuffer):
(WebCore::WebGLFramebuffer::drawBuffers):
(WebCore):
(WebCore::WebGLFramebuffer::drawBuffersIfNecessary):
* html/canvas/WebGLFramebuffer.h:
(WebGLFramebuffer):
* html/canvas/WebGLRenderingContext.cpp:
(WebCore):
(WebCore::WebGLRenderingContext::initializeNewContext):
(WebCore::WebGLRenderingContext::framebufferRenderbuffer):
(WebCore::WebGLRenderingContext::getExtension):
(WebCore::WebGLRenderingContext::getParameter):
(WebCore::WebGLRenderingContext::getSupportedExtensions):
(WebCore::WebGLRenderingContext::validateFramebufferFuncParameters):
(WebCore::WebGLRenderingContext::getMaxDrawBuffers):
(WebCore::WebGLRenderingContext::getMaxColorAttachments):
* html/canvas/WebGLRenderingContext.h:
(WebCore):
(WebGLRenderingContext):
* platform/chromium/support/Extensions3DChromium.cpp:
(WebCore::Extensions3DChromium::drawBuffersEXT):
(WebCore):
* platform/graphics/Extensions3D.h:
(Extensions3D):
* platform/graphics/GraphicsContext3D.cpp:
(WebCore::GraphicsContext3D::getClearBitsByAttachmentType):
* platform/graphics/chromium/Extensions3DChromium.h:
(Extensions3DChromium):
* platform/graphics/opengl/Extensions3DOpenGL.cpp:
(WebCore::Extensions3DOpenGL::supportsExtension):
(WebCore::Extensions3DOpenGL::drawBuffersEXT):
(WebCore):
* platform/graphics/opengl/Extensions3DOpenGL.h:
(Extensions3DOpenGL):
* platform/graphics/opengl/Extensions3DOpenGLCommon.cpp:
(WebCore::Extensions3DOpenGLCommon::ensureEnabled):
* platform/graphics/opengl/Extensions3DOpenGLCommon.h:
(Extensions3DOpenGLCommon):
* platform/graphics/opengl/Extensions3DOpenGLES.cpp:
(WebCore::Extensions3DOpenGLES::drawBuffersEXT):
(WebCore):
(WebCore::Extensions3DOpenGLES::supportsExtension):
* platform/graphics/opengl/Extensions3DOpenGLES.h:
(Extensions3DOpenGLES):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144358 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[texmap] Remove redundant defines on TextureMapperGL
https://bugs.webkit.org/show_bug.cgi?id=111090

Reviewed by Antonio Gomes.

driverSupportsSubImage() already uses OpenGL ES defines to return
correct support, thus no need for these additional defines.

No behavior changes, thus covered by existing tests.

* platform/graphics/texmap/TextureMapperGL.cpp:
(WebCore::BitmapTextureGL::updateContentsNoSwizzle):


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