[Chromium] Define new setSharedWorkerRepository function in preparation for removing WebKitPlatformSupport::sharedWorkerRepository()
https://bugs.webkit.org/show_bug.cgi?id=95861

Reviewed by Adam Barth.

Followup patch to Chromium will call this new function, then we can remove all references to the legacy function on WebKitPlatformSupport.

* public/WebSharedWorkerRepository.h:
(WebKit):
* src/SharedWorkerRepository.cpp:
(WebKit):
(WebKit::setSharedWorkerRepository):
(WebKit::sharedWorkerRepository):
(WebCore::SharedWorkerRepository::isAvailable):
(WebCore::SharedWorkerRepository::connect):
(WebCore::SharedWorkerRepository::documentDetached):
(WebCore::SharedWorkerRepository::hasSharedWorkers):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128087 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Javascript in foreground tabs should not wait synchronously for plug-ins to load
<rdar://problem/12067415> and https://bugs.webkit.org/show_bug.cgi?id=96167

Reviewed by Geoff Garen.

Source/WebKit2:

Synchronously waiting for initialization to complete when javascript accesses the plug-in script object severely
reduces the effectiveness of having an asynchronous NPP_New.

Such as with background tabs that have never been viewed, we already have cases where JS calls into the plug-in
element fail because we haven't bothered to initialize the plug-in.

We get a huge win by expanding that to foreground tabs that simply haven't finished initializing their plug-ins.

* WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::scriptObject): If initialization is not complete just return 0 - They can get at the script object later.

Remove the notion of "wait for asynchronous initialization" altogether:
* WebProcess/Plugins/Netscape/NetscapePlugin.h:
(NetscapePlugin):
* WebProcess/Plugins/PDF/BuiltInPDFView.h:
(BuiltInPDFView):
* WebProcess/Plugins/Plugin.h:
(Plugin):
* WebProcess/Plugins/PluginProxy.cpp:
* WebProcess/Plugins/PluginProxy.h:
(PluginProxy):

Tools:

Enhance the "Slow NPP_New" plug-in to also be able to return properties to javascript.

* DumpRenderTree/TestNetscapePlugIn/Tests/SlowNPPNew.cpp:
(PluginObject):
(SlowNPPNew::PluginObject::PluginObject):
(SlowNPPNew::PluginObject::~PluginObject):
(SlowNPPNew::PluginObject::hasProperty):
(SlowNPPNew::PluginObject::getProperty):
(SlowNPPNew::NPP_GetValue):
(SlowNPPNew):

LayoutTests:

* platform/mac-wk2/plugins/script-object-access-fails-during-slow-initialization-expected.txt: Added.
* platform/mac-wk2/plugins/script-object-access-fails-during-slow-initialization.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128088 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: highlight of paint rectangles is broken
https://bugs.webkit.org/show_bug.cgi?id=96276

Reviewed by Vsevolod Vlasov.

* inspector/InspectorOverlay.cpp:
(WebCore::InspectorOverlay::drawRectHighlight): Fix JS method name to match the one in InspectorOverlayPage.html


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128089 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] gradient-with-scaled-ancestor.html rebaseline
https://bugs.webkit.org/show_bug.cgi?id=96110

Patch by Alex Sakhartchouk <alexst@chromium.org> on 2012-09-10
Reviewed by Adrienne Walker.

Fixed a bug in the test, rebaselining the results at proper resolution.

* platform/chromium-linux-x86/fast/hidpi/gradient-with-scaled-ancestor-expected.png: Removed.
* platform/chromium-linux/fast/hidpi/gradient-with-scaled-ancestor-expected.png:
* platform/chromium-mac-snowleopard/fast/hidpi/gradient-with-scaled-ancestor-expected.png:
* platform/chromium-mac/fast/hidpi/gradient-with-scaled-ancestor-expected.png:
* platform/chromium-win-xp/fast/hidpi/gradient-with-scaled-ancestor-expected.png: Removed.
* platform/chromium-win/fast/hidpi/gradient-with-scaled-ancestor-expected.png:
* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128090 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[JSC] Use StringBuilder::appendNumber() instead of String::number()
https://bugs.webkit.org/show_bug.cgi?id=96236

Reviewed by Benjamin Poulain.

* API/JSContextRef.cpp:
(JSContextCreateBacktrace):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128091 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] gradient-with-scaled-ancestor.html rebaseline
https://bugs.webkit.org/show_bug.cgi?id=96110

Patch by Alex Sakhartchouk <alexst@chromium.org> on 2012-09-10
Reviewed by Adrienne Walker.

Fixed a bug in the test, rebaselining the results at proper resolution.

* platform/chromium-linux-x86/fast/hidpi/gradient-with-scaled-ancestor-expected.png: Removed.
* platform/chromium-linux/fast/hidpi/gradient-with-scaled-ancestor-expected.png:
* platform/chromium-mac-snowleopard/fast/hidpi/gradient-with-scaled-ancestor-expected.png:
* platform/chromium-mac/fast/hidpi/gradient-with-scaled-ancestor-expected.png:
* platform/chromium-win-xp/fast/hidpi/gradient-with-scaled-ancestor-expected.png: Removed.
* platform/chromium-win/fast/hidpi/gradient-with-scaled-ancestor-expected.png:
* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128092 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebKit/chromium: [chromium] Add unused GestureTapCancel
https://bugs.webkit.org/show_bug.cgi?id=96183

Patch by Rick Byers <rbyers@chromium.org> on 2012-09-10
Reviewed by Adam Barth.

This adds a new 'tap cancel' gesture type.  This is temporarily unused,
so that we can change chromium to start sending the gesture type
without breaking anything.

* public/WebInputEvent.h:
* src/PageWidgetDelegate.cpp:
(WebKit::PageWidgetDelegate::handleInputEvent):
* src/WebInputEventConversion.cpp:
(WebKit::PlatformGestureEventBuilder::PlatformGestureEventBuilder):
* src/WebPopupMenuImpl.cpp:
(WebKit::WebPopupMenuImpl::handleInputEvent):
* src/WebViewImpl.cpp:
(WebKit::WebViewImpl::handleGestureEvent):

Tools: Add handling of new GestureTapCancel in DRT

https://bugs.webkit.org/show_bug.cgi?id=96183

Patch by Rick Byers <rbyers@chromium.org> on 2012-09-10
Reviewed by Adam Barth.

* DumpRenderTree/chromium/TestWebPlugin.cpp:
(TestWebPlugin::handleInputEvent):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128093 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[V8] Constructors try to handle errors that cannot occur
https://bugs.webkit.org/show_bug.cgi?id=96304

Patch by Adam Barth <abarth@chromium.org> on 2012-09-10
Reviewed by Kentaro Hara.

There's no reason for constructors to indirect through the Frame. Now
that we can reliably get the Document from the v8::Context, we can just
grab it without worrying about handling error conditions related to not
being able to find the Document.

* bindings/scripts/CodeGeneratorV8.pm:
(GenerateNamedConstructorCallback):
* bindings/scripts/test/V8/V8TestNamedConstructor.cpp:
(WebCore::V8TestNamedConstructorConstructorCallback):
* bindings/v8/custom/V8AudioContextCustom.cpp:
(WebCore::V8AudioContext::constructorCallback):
* bindings/v8/custom/V8HTMLImageElementConstructor.cpp:
(WebCore::v8HTMLImageElementConstructorCallback):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128094 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[V8] V8HTMLDocument::write and friends should not indirect through Frame
https://bugs.webkit.org/show_bug.cgi?id=96289

Patch by Adam Barth <abarth@chromium.org> on 2012-09-10
Reviewed by Eric Seidel.

There is no reason why document.write and friends need to indirect
through the Frame to find the active document. This patch makes these
functions work the same as the JSC versions.

* bindings/v8/BindingState.cpp:
* bindings/v8/BindingState.h:
    - This patch removes the last callers of activeFrame, so we can
      remove the function entirely.
* bindings/v8/custom/V8HTMLDocumentCustom.cpp:
(WebCore::V8HTMLDocument::writeCallback):
(WebCore::V8HTMLDocument::writelnCallback):
(WebCore::V8HTMLDocument::openCallback):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128095 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Refactored op_tear_off* to support activations that don't allocate space for 'arguments'
https://bugs.webkit.org/show_bug.cgi?id=96231

Reviewed by Gavin Barraclough.

This is a step toward smaller activations.

As a side-effect, this patch eliminates a load and branch from the hot path
of activation tear-off by moving it to the cold path of arguments tear-off. Our
optimizing assumptions are that activations are common and that reifying the
arguments object is less common.

* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dump):
* bytecode/Opcode.h:
(JSC::padOpcodeName): Updated for new opcode lengths.

* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::addConstantValue): Added support for JSValue()
in the bytecode, which we use when we have 'arguments' but no activation.

(JSC::BytecodeGenerator::emitReturn): Always emit tear_off_arguments
if we've allocated the arguments registers. This allows tear_off_activation
not to worry about the arguments object anymore.

Also, pass the activation and arguments values directly to these opcodes
instead of requiring the opcodes to infer the values through special
registers. This gives us more flexibility to move or eliminate registers.

* dfg/DFGArgumentsSimplificationPhase.cpp:
(JSC::DFG::ArgumentsSimplificationPhase::run):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGNode.h:
(Node): Updated for new opcode lengths.

* dfg/DFGOperations.cpp: Activation tear-off doesn't worry about the
arguments object anymore. If 'arguments' is in use and reified, it's
responsible for aliasing back to the activation object in tear_off_arguments.

* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile): Don't pass the arguments object to
activation tear-off; do pass the activation object to arguments tear-off.

* interpreter/Interpreter.cpp:
(JSC::Interpreter::privateExecute): Ditto.

* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_tear_off_activation):
(JSC::JIT::emit_op_tear_off_arguments):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_tear_off_activation):
(JSC::JIT::emit_op_tear_off_arguments):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm: Same change in a few more execution engines.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128096 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed fix of webkit-lint for Chromium gardening

* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128097 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Silence a warning when running update-webkit-localizable-strings
https://bugs.webkit.org/show_bug.cgi?id=96307

Reviewed by John Sullivan.

Since both the blockedPluginByContentSecurityPolicyText and insecurePluginVersionText strings use exact the same wording,
use WEB_UI_STRING_KEY to indicate that they are different.

* English.lproj/Localizable.strings:
Update the localizable strings file.

* platform/LocalizedStrings.cpp:
(WebCore::blockedPluginByContentSecurityPolicyText):
(WebCore::insecurePluginVersionText):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128098 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Update the css3/filters test expectations to match the bots.
90+ of these tests never failed, so adding the whole css3/filters
directory was incorrect.
* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128099 268f45cc-cd09-0410-ab3c-d52691b4dbfc
offlineasm has some impossible to implement, and unused, instructions
https://bugs.webkit.org/show_bug.cgi?id=96310

Reviewed by Mark Hahnenberg.

* offlineasm/armv7.rb:
* offlineasm/instructions.rb:
* offlineasm/x86.rb:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128100 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        [WK2] Add an API to open a page in same process
        https://bugs.webkit.org/show_bug.cgi?id=96306

        Reviewed by Anders Carlsson.

        The name "related" inspired by <http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts>.

        * UIProcess/API/mac/WKView.h: Added an API. It's unwieldy, but I blame
        WKBrowsingContextGroup, not the related view.

        * UIProcess/API/mac/WKViewPrivate.h: Matching SPI for clients that mostly use
        C APIs.

        * UIProcess/API/mac/WKView.mm:
        (-[WKView initWithFrame:processGroup:browsingContextGroup:]): Use new back-end
        signature.
        (-[WKView initWithFrame:processGroup:browsingContextGroup:relatedToView:]):
        Get page from WKView, and call back-end.
        (-[WKView initWithFrame:contextRef:pageGroupRef:]): Reimplement existing method
        by calling new, more powerful one.
        (-[WKView initWithFrame:contextRef:pageGroupRef:relatedToPage:]): Just one change,
        pass relatedPage to the context.

        * UIProcess/WebContext.cpp: (WebKit::WebContext::createWebPage): If related page
        is not null, use its process.

        * UIProcess/WebContext.h: (WebContext): Updated createWebPage signature.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128101 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[V8] setNamedHiddenWindowReference doesn't need to be a special case
https://bugs.webkit.org/show_bug.cgi?id=96198

Reviewed by Nate Chapin.

Prior to this patch, the DOMWindow cached its properties on the outter
global object rather than on the Holder of the properties. (We cache
properties to prevent their DOM wrappers from being garbage collected
too early.) There doesn't seem to be any reason why DOMWindow need to
be special-cased in this regard. We can just cache the properities on
their Holders, as usual.

* bindings/scripts/CodeGeneratorV8.pm:
(GenerateNormalAttrGetter):
* bindings/v8/V8DOMWrapper.cpp:
* bindings/v8/V8DOMWrapper.h:
(V8DOMWrapper):
* bindings/v8/custom/V8LocationCustom.cpp:
* page/Location.idl:
    - Previously, Location had a custom toV8 function so that
      document.location would cache its wrapper in the same place as
      window.location. However, that's no longer necessary as the
      DOMWindow now holds its Document in a hidden property, which
      means the DOMWindow keeps the cached location property on
      Document alive anyway.


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

        * UIProcess/WebContext.h: Added a default value for relatedPage argment - if
        you don't have one, null is fine.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128103 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rebaselined for Chromium.

* platform/chromium/http/tests/security/contentSecurityPolicy/source-list-parsing-nonascii-expected.txt: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128104 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed Rebaseline for Chromium Win XP.

* platform/chromium-win-xp/fast/hidpi/gradient-with-scaled-ancestor-expected.png: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128105 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Change -data-blackberry-webworks-context to -data-webworks-context
because not all webworks apps are blackberry apps.
https://bugs.webkit.org/show_bug.cgi?id=96297

Patch by Genevieve Mak <gmak@rim.com> on 2012-09-10
Reviewed by Antonio Gomes.

PR #193726
Rubber Stamped interally by Mike Fenton.

* WebKitSupport/DOMSupport.cpp:
(BlackBerry::WebKit::DOMSupport::webWorksContext):

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