[EFL][WK2] WebProcess keeps on waiting for UIProcess
https://bugs.webkit.org/show_bug.cgi?id=97646

Patch by Regina Chung <heejin.r.chung@samsung.com> on 2012-10-11
Reviewed by Kenneth Rohde Christiansen.

Set LayerTreeRenderer to active so UIProcess can send RenderNextFrame message to WebProcess
after accelerated compositing(AC) mode is entered, so WebProcess can start flushing changes to UIProcess.

* UIProcess/API/efl/EflViewportHandler.cpp: Added API for setting LayerTreeRenderer's active state.
(WebKit::EflViewportHandler::setActive):
(WebKit):
* UIProcess/API/efl/EflViewportHandler.h:
(EflViewportHandler):
* UIProcess/API/efl/ewk_view.cpp: Sets LayerTreeRenderer's active status to true after entering AC mode.
(ewk_view_accelerated_compositing_mode_enter):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131091 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed.  Rolled DEPS.

Patch by Sheriff Bot <webkit.review.bot@gmail.com> on 2012-10-11

* DEPS:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131092 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Removed some more static assumptions about inline object capacity
https://bugs.webkit.org/show_bug.cgi?id=98603

Reviewed by Filip Pizlo.

* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): Use JSObject::allocationSize()
for a little more flexibility. We still pass it a constant inline capacity
because the JIT doesn't have a strategy for selecting a size class based
on non-constant capacity yet. "INLINE_STORAGE_CAPACITY" is a marker for
code that makes static assumptions about object size.

* jit/JITInlineMethods.h:
(JSC::JIT::emitAllocateBasicJSObject):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm: Ditto for the rest of our many execution engines.

* runtime/JSObject.h:
(JSC::JSObject::allocationSize):
(JSC::JSFinalObject::finishCreation):
(JSC::JSFinalObject::create): New helper function for computing object
size dynamically, since we plan to have objects of different sizes.

(JSC::JSFinalObject::JSFinalObject): Note that our m_inlineStorage used
to auto-generate an implicit C++ constructor with default null initialization.
This memory is not observed in its uninitialized state, and our LLInt and
JIT allocators do not initialize it, so I did not add any explicit code
to do so, now that the implicit code is gone.

(JSC::JSObject::offsetOfInlineStorage): Changed the math here to match
inlineStorageUnsafe(), since we can rely on an explicit data member anymore.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131093 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rebaseline these tests after v8-i18n roll.

* platform/chromium/fast/js/kde/StringObject-expected.txt:
* platform/chromium/fast/js/kde/function_length-expected.txt: Added.
* platform/chromium/fast/js/kde/inbuilt_function_tostring-expected.txt: Added.
* platform/chromium/fast/js/string-prototype-properties-expected.txt:
* platform/chromium/inspector-protocol/runtime-getProperties-expected.txt:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131094 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Improve the comment describing mainWorldScriptContext
https://bugs.webkit.org/show_bug.cgi?id=99092

Reviewed by James Robinson.

* public/WebFrame.h:
(WebFrame):
    - Add some more text about what this API does so that folks who
      call it know what they need to worry about.


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