webarchive/ignore-noscript-if-scripting.html expected results should use .webarchive extension
https://bugs.webkit.org/show_bug.cgi?id=93736
<rdar://problem/12077654>

Reviewed by Eric Seidel.

Because the test uses dumpDOMAsWebArchive(), the expected results extension should be .webarchive instead of .txt.
* webarchive/ignore-noscript-if-scripting-enabled-expected.webarchive: Renamed from LayoutTests/webarchive/ignore-noscript-if-scripting-enabled-expected.txt.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125354 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Remove QtSenderStack now we do not support __qt_sender__ anymore in Qt bridge
https://bugs.webkit.org/show_bug.cgi?id=93767

Reviewed by Kenneth Rohde Christiansen.

Dead code after patch of bug 93649.

* bridge/qt/qt_instance.h:
(QtInstance):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125355 268f45cc-cd09-0410-ab3c-d52691b4dbfc
WebCore::findAtomicString(PropertyName) always convert the name to 16bits
https://bugs.webkit.org/show_bug.cgi?id=93685

Reviewed by Geoffrey Garen.

Source/WebCore: 

* bindings/js/JSDOMBinding.cpp:
(WebCore::findAtomicString):
Use the new AtomicString::find() to avoid calling StringImpl::characters().

Source/WTF: 

Previously, WebCore::findAtomicString() was causing a conversion for the 8bit property name
to a 16bits due to the call to StringImpl::character16().

This patch fixes the issue by adding support for both 8bits and 16bits string in AtomicString::find().

* wtf/text/AtomicString.cpp:
(HashAndCharacters):
(WTF::HashAndCharactersTranslator::hash):
(WTF::HashAndCharactersTranslator::equal):
(WTF::HashAndCharactersTranslator::translate):
Use a template to make the struct and the translator independant of the CharacterType.

(WTF::AtomicString::add):
(WTF::findString):
(WTF::AtomicString::find): Change the API to take a StringImpl*. AtomicString can use
it efficiently to find the right string.
* wtf/text/AtomicString.h:
(AtomicString):
* wtf/text/StringImpl.h:
(StringImpl): Adapt the friends translator to support the template.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125356 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Do the DecimalNumber to String conversion on 8 bits
https://bugs.webkit.org/show_bug.cgi?id=93683

Patch by Benjamin Poulain <bpoulain@apple.com> on 2012-08-11
Reviewed by Andreas Kling.

Source/WebCore: 

Numbers converted to string for CSS are unlikely to ever be concatenated with a 16bits string.
This patch change the conversion to be done to 8bits string in order to reduce memory allocations.

* css/CSSPrimitiveValue.cpp:
(WebCore::formatNumber):
* inspector/InspectorValues.cpp:
(WebCore::InspectorBasicValue::writeJSON):
* platform/graphics/Color.cpp:
(WebCore::Color::serialized): Instead of allocating a static WTF::String, we can simply append the
string literal to the output vector.

Source/WTF: 

Modify DecimalNumber to do the conversion to string on LChar instead of UChar.

* wtf/DecimalNumber.cpp:
(WTF::DecimalNumber::toStringDecimal):
(WTF::DecimalNumber::toStringExponential):
* wtf/DecimalNumber.h:
(DecimalNumber):
* wtf/dtoa.h:
* wtf/text/StringBuffer.h:
(WTF::StringBuffer::operator[]): StringBuffer::operator[] was incorrectly typed to UChar, making
the method impossible to instanciate with LChar.
* wtf/text/WTFString.h:
(String):
(WTF::String::adopt): String::adopt() is modified to work with both LChar and UChar. StringImpl
already support that.
(WTF::appendNumber): Add support for any type that can instanciate the template.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125357 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Make it possible to run the WebProcess as an XPC service
https://bugs.webkit.org/show_bug.cgi?id=92814

Reviewed by Anders Carlsson.

In this initial implementation, we are only using the XPC service
to launch the WebProcess, and then using the xpc_connection to send
over a mach_port to the WebProcess which is then used for creating
the CoreIPC connection.  In the future, we will switch to using the
xpc_connection for all messaging.

When the XPC service is enabled (it is compiled out by default for now), both
the XPC service and the old spawned process are runtime choosable.  This allows
the connect to pre-existing process workflow to continue to work.

There are a few additional caveats of this initial implementation:
    - It is only set up for the WebProcess (not for the PluginProcess)
    - The WebProcess shim does not work.
    - It requires a new environment variable to be set when launching
      to find the right service to launch (__XPC_DYLD_FRAMEWORK_PATH).

* Configurations/WebKit2Service.xcconfig: Added.
Add new configuration file for the service.

* Platform/CoreIPC/Connection.h:
(CoreIPC::Connection::Identifier::Identifier):
(CoreIPC::Connection::identifierIsNull):
Added to encapsulate the concept of a null identifier, now that it
is not possible to just compare to null.

* Platform/CoreIPC/mac/ConnectionMac.cpp:
(CoreIPC::Connection::platformInvalidate):
(CoreIPC::Connection::platformInitialize):
Change Connection::Identifier on the Mac to be a struct instead of
a typedef to a mach_port. This allows for the Connection to get both
the listening port and a reference to the xpc_connection (if it
compiled in). For now, all we do is retain the xpc_connection when it
is given to us, and release on Connection invalidation.

* PluginProcess/PluginProcess.cpp:
(WebKit::PluginProcess::createWebProcessConnection):
* PluginProcess/mac/PluginProcessMainMac.mm:
(WebKit::PluginProcessMain):
* WebProcess/Plugins/PluginProcessConnectionManager.cpp:
(WebKit::PluginProcessConnectionManager::getPluginProcessConnection):
Use the Connection::Identifier constructor.

* UIProcess/Launcher/ProcessLauncher.h:
(LaunchOptions):
Add a UseXPC option to the LaunchOptions so we can dynamically choose whether to use it.

(ProcessLauncher):
Make processTypeAsString public to allow better factoring in the implementation file
using static functions.

* UIProcess/Launcher/mac/ProcessLauncherMac.mm:
Factor out the different launching options into helper functions. Always start by
trying to connect to a pre-existing process.

(WebKit::launchXPCService):
Create a new xpc_connection to our service, and give it a unique instance UUID.
Then, send a bootstrap message with a mach_port and wait for a reply to complete
the launch procedure.
 
(WebKit::tryPreexistingProcess):
Move the code to connect to a preexisting process to its own helper function.

(WebKit::ProcessLauncher::launchProcess):
Clean up a bit, calling the helper functions and adding call to launch the XPC service
if it is enabled.

* UIProcess/Launcher/mac/ThreadLauncherMac.mm:
(WebKit::webThreadBody):
(WebKit::ThreadLauncher::createWebThread):
Switch to using the constructor version of Identifier.

* UIProcess/Plugins/PluginProcessProxy.cpp:
(WebKit::PluginProcessProxy::PluginProcessProxy):
Don't try to use the XPC service for plugins yet.
 
(WebKit::PluginProcessProxy::didFinishLaunching):
Use Connection::identifierIsNull instead of explicit null check.

* UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::connect):
If XPC is compiled in (it currently is not) enable it by default.

* WebKit2.xcodeproj/project.pbxproj:
Add the new files and targets.

* WebKit2Service: Added.
* WebKit2Service/Info.plist: Added.
Add the paper work needed for an XPC service. Importantly, set up the XPC
service to be an Application service type, use NSApplicationMain as its run
loop, and allow for multiple instantiations. Also make sure the service acts
like the WebProcess binary by making it a LSUIElement, enabling LSFileQuarantine,
and setting the principle class to NSApplication.

* WebKit2Service/MainMacService.mm: Added.
(WebKit2ServiceEventHandler):
(main):
The initialization of the XPC service is quite a bit different than the
WebProcess version, since we don't get passed parameters in argv. Instead,
we initiate the XPC service via xpc_main, and wait for the bootstrap message
we sent in ProcessLauncherMac.mm. When we receive that message we can load 
WebKit2 framework and initialize the WebProcess normally (we also get the mach_port
for the CoreIPC connection in that bootstrap message).

* WebProcess/mac/WebProcessMainMac.mm:
(WebKit::WebProcessMainXPC):
Add a variant of WebProcessMain that is used for the XPC service case, where we don't
have command line arguments and don't need to talk to the mach bootstrap server.

(WebKit::WebProcessMain):
* mac/MainMac.cpp: Removed.
* mac/MainMacProcess.cpp: Copied from Source/WebKit2/mac/MainMac.cpp.
Rename MainMac to MainMacProcess to signify that it is different from the XPC
service main.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125358 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Enable XPC Service based WebProcess with runtime flag
https://bugs.webkit.org/show_bug.cgi?id=93773

Reviewed by Dan Bernstein.

Source/WebKit2: 

Use the XPC Service for WebProcess code path if WEBKIT_USE_XPC_SERVICE_FOR_WEB_PROCESS
is set in the environment.

* UIProcess/Launcher/mac/ProcessLauncherMac.mm:
(WebKit::launchXPCService):
Fix issue that was causing this code not to compile. This was not caught before since
the code was not being built.
        
* UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::connect):
Switch from hard coding always using the XPC Service code path if
HAVE(XPC) was true, to doing it conditionally on an environment variable.

Source/WTF: 

* wtf/Platform.h:
Define HAVE_XPC on 10.7 and later.

Tools: 

Convert --use-web-process-xpc-service passed to run-safari (and similar scripts)
to setting WEBKIT_USE_XPC_SERVICE_FOR_WEB_PROCESS=YES in the environment and setting
up __XPC_DYLD_FRAMEWORK_PATH and __XPC_DYLD_INSERT_LIBRARIES variables. NOTE: using
the XPC service is not the default code path.

* Scripts/webkitdirs.pm:
(shouldUseXPCServiceForWebProcess):
(determineShouldUseXPCServiceForWebProcess):
Add functions to extract --use-web-process-xpc-service from ARGV and set a
global variable.

(printHelpAndExitForRunAndDebugWebKitAppIfNeeded):
Add help text for --use-web-process-xpc-service.

(runMacWebKitApp):
Set the WEBKIT_USE_XPC_SERVICE_FOR_WEB_PROCESS environment variable and DYLD
if --use-web-process-xpc-service was passed on the command line.

(execMacWebKitAppForDebugging):
Set the WEBKIT_USE_XPC_SERVICE_FOR_WEB_PROCESS environment variable and DYLD
if --use-web-process-xpc-service was passed on the command line. Also, bail
if both --use-web-process-xpc-service and --target-web-process are passed on
the command line, as we don't currently support using both.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125361 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove ability to run MiniBrowser in threaded mode, it hasn't worked for a long time
https://bugs.webkit.org/show_bug.cgi?id=93774

Reviewed by Dan Bernstein.

Remove support for opening windows using the shared thread WKContextRef. WKContextGetSharedThreadContext()
is going away, due to not working for a long time, and the first step is removing all the callers.

While here, remove the BrowserStatisticsWindow, which was not providing interesting information.

* MiniBrowser/MiniBrowser.xcodeproj/project.pbxproj:
* MiniBrowser/mac/AppDelegate.h:
* MiniBrowser/mac/AppDelegate.m:
(-[BrowserAppDelegate init]):
(-[BrowserAppDelegate newWindow:]):
(-[BrowserAppDelegate openPanelDidEnd:returnCode:contextInfo:]):
* MiniBrowser/mac/BrowserStatisticsWindow.xib: Removed.
* MiniBrowser/mac/BrowserStatisticsWindowController.h: Removed.
* MiniBrowser/mac/BrowserStatisticsWindowController.m: Removed.
* MiniBrowser/mac/MainMenu.xib:
* MiniBrowser/win/BrowserView.cpp:
(BrowserView::create):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125362 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WK2] Get rid of ProcessModelSharedSecondaryThread
https://bugs.webkit.org/show_bug.cgi?id=93652

Reviewed by Dan Bernstein.

The threaded model for WebKit2 has been broken a long time and its continued existence in
the code only serves to confuse. It's time to say good bye to it.

* UIProcess/API/C/WKContext.cpp:
* UIProcess/API/C/WKContextPrivate.h:
Remove WKContextGetSharedThreadContext().

* UIProcess/ProcessModel.h:
Remove ProcessModelSharedSecondaryThread from the ProcessModel enum.

* UIProcess/WebContext.cpp:
* UIProcess/WebContext.h:
Remove WebContext::sharedThreadContext().

* UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::~WebProcessProxy):
(WebKit::WebProcessProxy::connect):
(WebKit::WebProcessProxy::isLaunching):
* UIProcess/WebProcessProxy.h:
Remove the ThreadLauncher member and stop deriving from ThreadLauncher::Client.

* UIProcess/Launcher/ThreadLauncher.cpp: Removed.
* UIProcess/Launcher/ThreadLauncher.h: Removed.
* UIProcess/Launcher/efl/ThreadLauncherEfl.cpp: Removed.
* UIProcess/Launcher/gtk/ThreadLauncherGtk.cpp: Removed.
* UIProcess/Launcher/mac/ThreadLauncherMac.mm: Removed.
* UIProcess/Launcher/qt/ThreadLauncherQt.cpp: Removed.
* UIProcess/Launcher/win/ThreadLauncherWin.cpp: Removed.
* WebKit2.xcodeproj/project.pbxproj:
* win/WebKit2.vcproj:
* CMakeLists.txt:
* GNUmakefile.list.am:
* PlatformEfl.cmake:
* Target.pri:
Remove ThreadLauncher files.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125363 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix the build.

* Platform/CoreIPC/Connection.h:
Add missing include.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125364 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Unreviewed trivial build fix: Newer Qt versions don't implicitly include qwindowsysteminterface.h
through the QTestLib headers anymore.

* DumpRenderTree/qt/EventSenderQt.cpp:
* WebKitTestRunner/Target.pri:
* WebKitTestRunner/qt/EventSenderProxyQt.cpp:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125365 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Convert meta method code to JSC C API
Reduce size of QtConnectionObject and prevent it from keeping QtInstance
objects staying alive
Replace use of internal Weak<> API with semi-public JSWeakObjectMap
Changed convertQVariantToValue to use the JSC C API
Conversion WIP
Ported valueRealType to C API
Increase use of JSObjectRef - WIP
More conversion WIP
Simplify unboxig
Conversion WIP