Unreviewed attempted build fix for Gtk after r142412
* WebKitTestRunner/gtk/PlatformWebViewGtk.cpp:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142413 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, rolling out r142413.
http://trac.webkit.org/changeset/142413
https://bugs.webkit.org/show_bug.cgi?id=109383

didn't fix the gtk build (Requested by thorton on #webkit).

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

* WebKitTestRunner/gtk/PlatformWebViewGtk.cpp:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142414 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed attempted build fix for Gtk after r142412

* WebKitTestRunner/gtk/PlatformWebViewGtk.cpp:
(WTR::PlatformWebView::PlatformWebView):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142415 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION (r132422): Page content and scrollbars are incorrectly offset after restoring a page from the page cache
https://bugs.webkit.org/show_bug.cgi?id=109317
<rdar://problem/12649131>

Reviewed by Simon Fraser.

Mark all scrolling that occurs beneath FrameView::layout as programmatic.

Test: platform/mac-wk2/tiled-drawing/tiled-drawing-scroll-position-page-cache-restoration.html

* page/FrameView.cpp:
(WebCore::FrameView::layout):

Add a test that ensures that scroll position is correctly restored for pages coming out of the page cache when tiled drawing is enabled.

* platform/mac-wk2/tiled-drawing/resources/go-back.html: Added.
* platform/mac-wk2/tiled-drawing/resources/scroll-and-load-page.html: Added.
* platform/mac-wk2/tiled-drawing/tiled-drawing-scroll-position-page-cache-restoration.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142416 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Consolidate the way WTF_USE_PTHREADS is enabled
https://bugs.webkit.org/show_bug.cgi?id=108191

Patch by Laszlo Gombos <l.gombos@samsung.com> on 2013-02-10
Reviewed by Benjamin Poulain.

.:

Remove duplicated definition of WTF_USE_PTHREADS.

WTF_USE_PTHREADS is defined to 1 on all OS(UNIX) environments in
Platform.h.

* Source/cmake/OptionsBlackBerry.cmake:
* Source/cmake/OptionsEfl.cmake:

Source/WTF:

Define WTF_USE_PTHREADS to 1 on all OS(UNIX) environments.

* WTF.gyp/WTF.gyp: Remove duplicated definition of WTF_USE_PTHREADS.
* wtf/Platform.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142417 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed.  Rolled Chromium DEPS to r181645.  Requested by
"James Robinson" <jamesr@chromium.org> via sheriffbot.

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

* DEPS:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142418 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[V8] Remove V8GCController::m_edenNodes and make minor DOM GC more precise
https://bugs.webkit.org/show_bug.cgi?id=108579

Reviewed by Adam Barth.

Currently V8GCController::m_edenNodes stores a list of nodes whose
wrappers have been created since the latest GC. The reason why we
needed m_edenNodes is that there was no way to know a list of wrappers
in the new space of V8. By using m_edenNodes, we had been approximating
'wrappers in the new space' by 'wrappers that have been created since
the latest GC'.

Now V8 provides VisitHandlesForPartialDependence(), with which WebKit
can know a list of wrappers in the new space. By using the API, we can
remove V8GCController::m_edenNodes. The benefit is that (1) we no longer
need to keep m_edenNodes and that (2) it enables more precise minor
DOM GC (Remember that m_edenNodes was just an approximation).

Performance benchmark: https://bugs.webkit.org/attachment.cgi?id=185940
The benchmark runs 300 iterations, each of which creates 100000 elements.
The benchmark measures average, min, median, max and stdev of execution times
of the 300 iterations. This will tell us the worst-case overhead of this change.

Before:
  mean=59.91ms, min=39ms, median=42ms, max=258ms, stdev=47.48ms

After:
  mean=58.75ms, min=35ms, median=41ms, max=250ms, stdev=47.32ms

As shown above, I couldn't observe any performance regression.

No tests. No change in behavior.

* bindings/v8/DOMDataStore.h:
(WebCore::DOMDataStore::setWrapperInObject):
* bindings/v8/DOMWrapperWorld.h:
(DOMWrapperWorld):
(WebCore::DOMWrapperWorld::getWorldWithoutContextCheck):
* bindings/v8/V8Binding.h:
(WebCore):
(WebCore::worldForEnteredContextIfIsolated):
(WebCore::worldForEnteredContextWithoutContextCheck):
* bindings/v8/V8DOMWindowShell.cpp:
(WebCore::V8DOMWindowShell::initializeIfNeeded):
* bindings/v8/V8GCController.cpp:
(WebCore::gcTree):
(WebCore):
(MinorGCWrapperVisitor):
(WebCore::MinorGCWrapperVisitor::MinorGCWrapperVisitor):
(WebCore::MinorGCWrapperVisitor::notifyFinished):
(WebCore::MajorGCWrapperVisitor::MajorGCWrapperVisitor):
(WebCore::V8GCController::gcPrologue):
(WebCore::V8GCController::minorGCPrologue):
(WebCore::V8GCController::majorGCPrologue):
* bindings/v8/V8GCController.h:
(V8GCController):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142419 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed gardening. Rebaselined svg/custom/foreign-object-skew.svg.

* platform/chromium-mac-snowleopard/svg/custom/foreign-object-skew-expected.png:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142420 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed gardening. Marked fast/frames/seamless/seamless-inherited-origin.html as FAIL.

* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142421 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Enable more of webkit_unit_tests in component builds
https://bugs.webkit.org/show_bug.cgi?id=109369

Patch by James Robinson <jamesr@chromium.org> on 2013-02-10
Reviewed by Darin Fisher.

Updates all webkit_unit_tests (except for LevelDBTest) to go through the Platform API instead of directly
calling into webkit_support so they work in component builds.

* WebKit.gyp:
* tests/AssociatedURLLoaderTest.cpp:
* tests/EventListenerTest.cpp:
* tests/FrameTestHelpers.cpp:
(WebKit::FrameTestHelpers::createWebViewAndLoad):
(QuitTask):
(WebKit::FrameTestHelpers::QuitTask::run):
(FrameTestHelpers):
(WebKit::FrameTestHelpers::runPendingTasks):
* tests/FrameTestHelpers.h:
(FrameTestHelpers):
* tests/ListenerLeakTest.cpp:
* tests/PopupMenuTest.cpp:
* tests/PrerenderingTest.cpp:
* tests/ScrollingCoordinatorChromiumTest.cpp:
(WebKit::ScrollingCoordinatorChromiumTest::~ScrollingCoordinatorChromiumTest):
(WebKit::ScrollingCoordinatorChromiumTest::navigateTo):
* tests/URLTestHelpers.cpp:
(WebKit::URLTestHelpers::registerMockedURLLoad):
* tests/WebFrameTest.cpp:
* tests/WebImageTest.cpp:
(WebKit::readFile):
* tests/WebPageNewSerializerTest.cpp:
* tests/WebPageSerializerTest.cpp:
* tests/WebPluginContainerTest.cpp:
(WebKit::WebPluginContainerTest::TearDown):
(WebKit::TEST_F):
* tests/WebViewTest.cpp:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142422 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Fix Android scrollbar size
https://bugs.webkit.org/show_bug.cgi?id=109374

Reviewed by James Robinson.

This shrinks scrollbars to 3 device-independent pixels (usually 6
physical pixels) and deletes the edge fade. Although the Android
system theme does have an edge fade, it's a much sharper cliff
than we had (against black, the colors go 64 -> 64 -> 52 -> 21 -> 0)
and I can't perceive any difference compared with no fade at all.

No new tests (due for rewrite in a week anyway).

* platform/chromium/ScrollbarThemeChromiumAndroid.cpp:
(WebCore):
(WebCore::ScrollbarThemeChromiumAndroid::paintThumb):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142423 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[V8] Rename isolated() to getWorld(), rename worldForEnteredContextIfIsolated() to worldForEnteredContext()
https://bugs.webkit.org/show_bug.cgi?id=109039

Reviewed by Adam Barth.

This is a follow-up patch for r141983.
Rename methods for consistency.

No tests. No change in behavior.

* bindings/v8/DOMDataStore.cpp:
(WebCore::DOMDataStore::current):
* bindings/v8/DOMWrapperWorld.h:
(WebCore::DOMWrapperWorld::getWorld):
* bindings/v8/ScriptController.cpp:
(WebCore::ScriptController::shouldBypassMainWorldContentSecurityPolicy):
(WebCore::ScriptController::currentWorldContext):
* bindings/v8/V8Binding.h:
(WebCore::worldForEnteredContext):
* bindings/v8/WorldContextHandle.cpp:
(WebCore::WorldContextHandle::WorldContextHandle):
* bindings/v8/custom/V8DocumentCustom.cpp:
(WebCore::wrap):
* bindings/v8/custom/V8HTMLDocumentCustom.cpp:
(WebCore::wrap):
* bindings/v8/custom/V8SVGDocumentCustom.cpp:
(WebCore::wrap):
* bindings/v8/custom/V8XMLHttpRequestCustom.cpp:
(WebCore::V8XMLHttpRequest::constructorCallbackCustom):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142424 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add sisa.samsung.com to team.html
https://bugs.webkit.org/show_bug.cgi?id=109394

Patch by Laszlo Gombos <l.gombos@samsung.com> on 2013-02-10
Reviewed by Dirk Schulze.

* team.html:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142425 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed gardening. Rebaselined an image.

* platform/chromium-mac-snowleopard/svg/custom/foreign-object-skew-expected.png:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142426 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Make the existing HTMLPreloadScanner threading-aware
https://bugs.webkit.org/show_bug.cgi?id=107807

Reviewed by Adam Barth.

The HTMLPreloadScanner and CSSPreloadScanner do a number of things.
CSSPreloadScanner is mostly just a helper class for HTMLPreloadScanner.
HTMLPreloadScanner runs its own copy of the HTMLTokenizer and uses
HTMLTokenizer::updateStateFor to emulate enough of the TreeBuilder
to get a realistic stream of tokens.  It does some additional TreeBuilder
emulation, including tracking template tags and base tags, but mostly
just scans the token stream for start-tags and looks for URLs in them.
It tracks when it has seen a <style> tag and starts sending all character tokens
to the CSSPreloadScanner until a </style> tag is seen.
It also (unfortunately) knows some about the loader guts and how to construct
a proper CachedResourcRequest and issue a preload.

This patch changes the model so that the preload scanners only know how to produce
PreloadRequest objects and append them to a passed-in vector.

This changes the preload-scanner behavior so that preloads are now all issued in one large
batch at the end of scanning, instead of as we hit each resource.  It's possible that
we'll wait to instead check for preload requests more often, at a possible tradeoff
to tokenizing speed.

An alternate approach might be to pass in a preload-delegate of sorts which knew how
to either build a vector, or send requests immediately.  For now the build-a-vector-always
approach seems clean, and does not seem to slow down our PerformanceTest microbenchmarks at least.

This patch has 2 main pieces:
- Remove Document and (and loader) dependencies from HTMLPreloadScanner/CSSPreloadScanner
  This is done through introduction of a new HTMLResourcePreloader class which holds
  a Document* and knows how to talk to the CachedResourceLoader.
- Clean-up HTMLPreloadScanners token-loop to not be tied to having a Tokenizer.
  (On a background thead, the HTMLPreloadScanner won't own the tokenizer, it will just
   be passed in tokens and expected to issue loads if necessary.)

This passes all of the LayoutTests using the main thread parser.

This patch does not make the HTMLPreloadScanner 100% ready for threading
(it still uses AtomicString which is currently not-OK on the parser thread)
but it's very close.  Two further (already written) patches will complete this.

* CMakeLists.txt:
* GNUmakefile.list.am:
* Target.pri:
* WebCore.gypi:
* WebCore.vcproj/WebCore.vcproj:
* WebCore.vcxproj/WebCore.vcxproj:
* WebCore.xcodeproj/project.pbxproj:
* html/parser/CSSPreloadScanner.cpp:
(WebCore::CSSPreloadScanner::CSSPreloadScanner):
(WebCore::CSSPreloadScanner::scan):
(WebCore::CSSPreloadScanner::emitRule):
* html/parser/CSSPreloadScanner.h:
(CSSPreloadScanner):
* html/parser/HTMLDocumentParser.cpp:
(WebCore::HTMLDocumentParser::HTMLDocumentParser):
(WebCore::HTMLDocumentParser::pumpTokenizer):
(WebCore::HTMLDocumentParser::insert):
(WebCore::HTMLDocumentParser::append):
(WebCore::HTMLDocumentParser::appendCurrentInputStreamToPreloadScannerAndScan):
* html/parser/HTMLDocumentParser.h:
(HTMLDocumentParser):
* html/parser/HTMLPreloadScanner.cpp:
(WebCore::isStartTag):
(WebCore):
(WebCore::isStartOrEndTag):
(WebCore::PreloadTask::processAttributes):
(WebCore::PreloadTask::charset):
(PreloadTask):
(WebCore::PreloadTask::resourceType):
(WebCore::PreloadTask::shouldPreload):
(WebCore::PreloadTask::createPreloadRequest):
(WebCore::HTMLPreloadScanner::HTMLPreloadScanner):
(WebCore::HTMLPreloadScanner::scan):
(WebCore::HTMLPreloadScanner::processPossibleTemplateTag):
(WebCore::HTMLPreloadScanner::processPossibleStyleTag):
(WebCore::HTMLPreloadScanner::processPossibleBaseTag):
(WebCore::HTMLPreloadScanner::processToken):
* html/parser/HTMLPreloadScanner.h:
(HTMLPreloadScanner):
* html/parser/HTMLResourcePreloader.cpp: Added.
(WebCore):
(WebCore::isStringSafeToSendToAnotherThread):
(WebCore::PreloadRequest::isSafeToSendToAnotherThread):
(WebCore::PreloadRequest::completeURL):
(WebCore::PreloadRequest::resourceRequest):
(WebCore::HTMLResourcePreloader::preload):
* html/parser/HTMLResourcePreloader.h: Added.
(WebCore):
(PreloadRequest):
(WebCore::PreloadRequest::create):
(WebCore::PreloadRequest::PreloadRequest):
(HTMLResourcePreloader):
(WebCore::HTMLResourcePreloader::HTMLResourcePreloader):
(WebCore::HTMLResourcePreloader::createWeakPtr):
* loader/cache/CachedResourceRequest.h:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142427 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Make the Plug-in XPCService build work even when building in Xcode
<rdar://problem/13011186>
https://bugs.webkit.org/show_bug.cgi?id=109392

Reviewed by Anders Carlsson.

* Configurations/DebugRelease.xcconfig:
Add a DEBUG_OR_RELEASE variable to test against.
* Configurations/PluginService.32.xcconfig:
* Configurations/PluginService.64.xcconfig:
In non-production builds, don't link against WebKit2, so that we don't get warnings about WebKit2.framework
not containing the right architectures. This is ok, as these services are not used in non-production builds.

* NetworkProcess/EntryPoint/mac/XPCService/NetworkService.Development/Info.plist:
* NetworkProcess/EntryPoint/mac/XPCService/NetworkService.Development/NetworkServiceMain.Development.mm:
* NetworkProcess/EntryPoint/mac/XPCService/NetworkService/Info.plist:
* NetworkProcess/EntryPoint/mac/XPCService/NetworkService/NetworkServiceMain.mm:
* PluginProcess/EntryPoint/mac/XPCService/PluginService.32/Info.plist:
* PluginProcess/EntryPoint/mac/XPCService/PluginService.32/PluginService.32.Main.mm:
* PluginProcess/EntryPoint/mac/XPCService/PluginService.64/Info.plist:
* PluginProcess/EntryPoint/mac/XPCService/PluginService.64/PluginService.64.Main.mm:
* PluginProcess/EntryPoint/mac/XPCService/PluginService.Development/Info.plist:
* PluginProcess/EntryPoint/mac/XPCService/PluginService.Development/PluginService.Development.Main.mm:
* WebProcess/EntryPoint/mac/XPCService/WebContentService.Development/Info.plist:
* WebProcess/EntryPoint/mac/XPCService/WebContentService.Development/WebContentServiceMain.Development.mm:
* WebProcess/EntryPoint/mac/XPCService/WebContentService/Info.plist:
* WebProcess/EntryPoint/mac/XPCService/WebContentService/WebContentServiceMain.mm:
Switch off the the old idiom of defining a macro for the initializer function, and instead set
it in the Info.plist, so the XPCServiceBootstrapper can grab it.

* Shared/EntryPointUtilities/mac/XPCService/XPCServiceBootstrapper.Development.h:
(WebKit::XPCServiceEventHandler):
* Shared/EntryPointUtilities/mac/XPCService/XPCServiceBootstrapper.h:
(WebKit::XPCServiceEventHandler):
Get the entry point from the bundle, rather than the macro. This is not only a bit less gross,
but also allows us to build without having linked against WebKit2.framework.

* UIProcess/Plugins/mac/PluginProcessProxyMac.mm:
(WebKit::shouldUseXPC):
Re-enable using XPC for plug-ins.

* WebKit2.xcodeproj/project.pbxproj:
Update project.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142428 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add adobe.com to team.html
https://bugs.webkit.org/show_bug.cgi?id=109396

Patch by Dirk Schulze <dschulze@adobe.com> on 2013-02-10
Reviewed by Laszlo Gombos.

* team.html:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142429 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed gardening. Rebaselined an image.

* platform/chromium-mac-snowleopard/svg/custom/foreign-object-skew-expected.png:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142430 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed gardening. Marked http/tests/css/css-image-loading.html as SLOW.

* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142431 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed gardening. Rebaselined an image.

* platform/chromium-mac/fast/backgrounds/repeat/negative-offset-repeat-transformed-expected.png:

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