Unreviewed GTK gardening.

* platform/gtk/fast/js/global-constructors-expected.txt: Rebaselining after r148236.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148443 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed GTK gardening.

* platform/gtk/TestExpectations: Adding failure expectations for tests introduced in r147829 and r148136.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148444 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] REGRESSION(r147499): HTTP auth dialog doesn't remember passwords anymore
https://bugs.webkit.org/show_bug.cgi?id=114613

Reviewed by Carlos Garcia Campos.

* Source/autotools/SetupAutoconfHeader.m4: Correct definition of ENABLE_CREDENTIAL_STORAGE
so that the ENABLE(CREDENTIAL_STORAGE) macro work properly.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148445 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION (r148360): Failure in webkitpy.tool.multicommandtool_unittest.MultiCommandToolTest.test_command_help
https://bugs.webkit.org/show_bug.cgi?id=114602

Reviewed by Ryosuke Niwa.

* Scripts/webkitpy/tool/multicommandtool_unittest.py:
(CommandTest.test_required_arguments): Reset the static argument_names variable on the TrivialCommand
interface so its value doesn't leak into the following tests.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148446 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WinCairo] Compile fix.
https://bugs.webkit.org/show_bug.cgi?id=114623

Patch by peavo@outlook.com <peavo@outlook.com> on 2013-04-15
Reviewed by Brent Fulgham.

* platform/network/curl/CookieJarCurl.cpp: Added required header files.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148447 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Missing a few packages for building on stock Fedora
https://bugs.webkit.org/show_bug.cgi?id=113916

Reviewed by Philippe Normand.

* gtk/install-dependencies: add packages that are missing.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148449 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Forward userGesture when creating a new window
https://bugs.webkit.org/show_bug.cgi?id=114622

Patch by Andy Chen <andchen@blackberry.com> on 2013-04-15
Reviewed by Rob Buis.

Client could use this info to decide whether the popup should
be blocked.
PR 291898
Reviewed internally by Mike Fenton

* Api/WebPageClient.h:
* WebCoreSupport/ChromeClientBlackBerry.cpp:
(WebCore::ChromeClientBlackBerry::createWindow):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchCreatePage):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148451 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Flaky Test: http/tests/ssl/ping-with-unsafe-redirect.html
        https://bugs.webkit.org/show_bug.cgi?id=114616

        Land expected results for the test.

        * http/tests/ssl/ping-with-unsafe-redirect-expected.txt: Added.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148452 268f45cc-cd09-0410-ab3c-d52691b4dbfc
An inline element with an absolutely positioned child does not correctly calculate/render padding and margin
https://bugs.webkit.org/show_bug.cgi?id=47554

Reviewed by David Hyatt.

Source/WebCore:

When looking for padding/margin to add from the start of a child's parent skip past any leading positioned siblings as
we don't add the padding/margin of the common parent when skipping past them in |skipLeadingWhitespace|. We
don't need to worry about the case of trailing positioned objects as we will account for their parent's
border/margin/padding when we encounter them in |nextSegmentBreak|.

Test: fast/inline/padding-before-leading-positioned-element-contributes-width.html

* rendering/RenderBlockLineLayout.cpp:
(WebCore::previousInFlowSibling):
(WebCore):
(WebCore::inlineLogicalWidth):

LayoutTests:

* fast/inline/padding-before-leading-positioned-element-contributes-width-expected.txt: Added.
* fast/inline/padding-before-leading-positioned-element-contributes-width.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148453 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Crash when favicon is requested
https://bugs.webkit.org/show_bug.cgi?id=114624

Patch by peavo@outlook.com <peavo@outlook.com> on 2013-04-15
Reviewed by Brent Fulgham.

* WebIconDatabase.cpp:
(WebIconDatabase::getOrCreateDefaultIconBitmap): Added NULL pointer check.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148456 268f45cc-cd09-0410-ab3c-d52691b4dbfc
HTMLMediaElement::removeTextTrack should clear track client
https://bugs.webkit.org/show_bug.cgi?id=114630

Reviewed by Jer Noble.

No new tests, this is clean-up that prevents a potential crash.

* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::removeTextTrack): Clear the track client.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148458 268f45cc-cd09-0410-ab3c-d52691b4dbfc
WKR gets stuck when there are many merges
https://bugs.webkit.org/show_bug.cgi?id=114632

Reviewed by Andreas Kling.

Move the last revision forward when it exists in a branch.
Otherwise, we'll be stuck looping over revisions made to merge patches.

* Scripts/webkitpy/tool/commands/newcommitbot.py:
(NewCommitBot.next_work_item):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148461 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WIN] Remove remaining calls to pthread from WTF
https://bugs.webkit.org/show_bug.cgi?id=114563

Reviewed by Brent Fulgham.

Replace pthread_key_create with threadSpecificKeyCreate and
pthread_setspecific with threadSpecificSet from ThreadSpecific.h.
These functions provide a windows-specific implementation for the pthread functions,
but require that the thread has been created with WTF::createThread(),
which is the case for all threads created within WebKit.
To call this function from fastMalloc we must not call fastMalloc in them.
To fulfill this constraint ThreadSpecificWin will allocated its memory through the
original malloc implementation and use the stack for local and static variables.
Keep the Darwin implementation as it is, since it contains some performance tweaks.

* wtf/FastMalloc.cpp:
* wtf/ThreadSpecificWin.cpp:
(WTF::destructorsList):
(WTF::destructorsMutex):
(WTF::threadSpecificKeyCreate):
(WTF::threadSpecificKeyDelete):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148462 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CMake] Add WTF_USE_*_UNICODE variables
https://bugs.webkit.org/show_bug.cgi?id=114556

Reviewed by Brent Fulgham.

WTF_USE_ICU_UNICODE and WTF_USE_WCHAR_UNICODE are used to
reduce duplication in the platform specific CMake files.

.:

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

Source/JavaScriptCore:

* CMakeLists.txt:
* PlatformEfl.cmake:

Source/WebCore:

* CMakeLists.txt:
* PlatformBlackBerry.cmake:
* PlatformEfl.cmake:
* PlatformWinCE.cmake:

Source/WTF:

* wtf/CMakeLists.txt:
* wtf/PlatformBlackBerry.cmake:
* wtf/PlatformEfl.cmake:
* wtf/PlatformWinCE.cmake:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148463 268f45cc-cd09-0410-ab3c-d52691b4dbfc
After switching to another space and back, video races to catch up with audio
https://bugs.webkit.org/show_bug.cgi?id=114634

Reviewed by Tim Horton.

In Mountain Lion and previous, report that a view is "not visible" when its window
is not in the active space. This causes us to notify AVFoundation that its CAImageQueues
will not be serviced and results in not having the "catch up" behavior when returning
to the browser's space.

* UIProcess/API/mac/PageClientImpl.mm:
(WebKit::PageClientImpl::isViewVisible):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148464 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Crash from null m_webSettings in WebPagePrivate
https://bugs.webkit.org/show_bug.cgi?id=114633
RIM PR 303745

Patch by Liam Quinn <lquinn@blackberry.com> on 2013-04-15
Reviewed by Rob Buis.
Internally reviewed by Leo Yang.

Speculative fix suggested by George Staikos--initialize m_webSettings first thing in the init() method.

* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::init):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148466 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove files related to quota and proximity events from the Xcode project
https://bugs.webkit.org/show_bug.cgi?id=114635

Reviewed by Benjamin Poulain.

* WebCore.xcodeproj/project.pbxproj:
* history/PageCache.cpp:
* page/DOMWindow.cpp:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148467 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Call directly RenderBlock::deleteLineBoxTree
https://bugs.webkit.org/show_bug.cgi?id=102761

Reviewed by Darin Adler.

Instead of implementing RenderLineBoxList::deleteLineBoxTree logic inside
RenderBlock::determineStartPosition, we can reuse the code. The commentaries added
in the changeset #86628 are not valid anymore, nextRootBox is casting m_nextLineBox
and nextLineBox is returning m_nextLineBox.

* rendering/RenderBlockLineLayout.cpp:
(WebCore::RenderBlock::determineStartPosition):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148468 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LLInt SH4 backend implementation
https://bugs.webkit.org/show_bug.cgi?id=112886

Patch by Julien Brianceau <jbrianceau@nds.com> on 2013-04-15
Reviewed by Oliver Hunt.

Source/JavaScriptCore:

* dfg/DFGOperations.cpp:
(JSC):
* jit/JITStubs.cpp:
* llint/LLIntOfflineAsmConfig.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* offlineasm/arm.rb:
* offlineasm/ast.rb:
* offlineasm/backends.rb:
* offlineasm/instructions.rb:
* offlineasm/mips.rb:
* offlineasm/risc.rb:
* offlineasm/sh4.rb: Added.

Source/WTF:

* wtf/Platform.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148474 268f45cc-cd09-0410-ab3c-d52691b4dbfc
HeapTimer lifetime should be less complicated
https://bugs.webkit.org/show_bug.cgi?id=114529

Reviewed by Oliver Hunt.

Right now our HeapTimer lifetime is rather complicated. HeapTimers are "owned" by the JSGlobalData,
but there's an issue in that there can be races between a thread that is trying to tear down a JSGlobalData
and the HeapTimer's fire function. Our current code for tearing down HeapTimers is an intricate and delicate
dance which probably contains subtle bugs.

We can make our lives easier by changing things around a bit.

1) We should free the API lock from being solely owned by the JSGlobalData so we don't have to worry about
   grabbing the lock out of invalid memory when our HeapTimer callback fires.

2) We should also make it so that we deref the JSGlobalData first, then unlock the API lock so that when we
   have the lock, the JSGlobalData is in one of two states: fully valid or completely destroyed, and we know exactly which one.

3) The JSLock can tell us this information by keeping a back pointer to the JSGlobalData. When the JSGlobalData's
   destructor is called, it clears this pointer in the JSLock. Other clients of the API lock can then check
   this pointer to determine whether or not the JSGlobalData is still around.

4) The CFRunLoopTimer will use the API lock as its context rather than the HeapTimer itself. The only way
   the HeapTimer's callback can get to the HeapTimer is through the API lock's JSGlobalData pointer.

5) The CFRunLoopTimerContext struct has two fields for retain and release callbacks for the context's info field.
   We'll provide these callbacks to ref() and deref() the JSLock as necessary. Thus, the timer becomes the other
   owner of the JSLock apart from the JSGlobalData.

* API/APIShims.h: Remove the cruft that was required by the previous design, such as RefGlobalDataTag.
(JSC::APIEntryShimWithoutLock::APIEntryShimWithoutLock):
(JSC::APIEntryShimWithoutLock::~APIEntryShimWithoutLock):
(APIEntryShimWithoutLock):
(JSC::APIEntryShim::APIEntryShim):
(JSC::APIEntryShim::~APIEntryShim): Protect the API lock with a RefPtr, deref the JSGlobalData, which could destroy it,
then unlock the API lock. This ordering prevents others from obtaining the API lock while the JSGlobalData is in the
middle of being torn down.
(JSC::APIEntryShim::init): We now take the lock, then ref the JSGlobalData, which is the opposite order of when we
tear down the shim.
* heap/Heap.cpp:
(JSC::Heap::setActivityCallback): Use PassOwnPtr now.
(JSC::Heap::activityCallback): Ditto.
(JSC::Heap::sweeper): Ditto.
(JSC):
* heap/Heap.h:
(Heap):
* heap/HeapTimer.cpp:
(JSC::retainAPILock): Retain callback for CFRunLoopTimerContext struct.
(JSC::releaseAPILock): Release callback for the CFRunLoopTimerContext struct.
(JSC::HeapTimer::HeapTimer): Use the API lock as the context's info field rather than the HeapTimer.
(JSC::HeapTimer::timerDidFire): Grab the API lock. Return early if the JSGlobalData has already been destroyed.
Otherwise, figure out which kind of HeapTimer we are based on the CFRunLoopTimerRef passed to the callback and
call the HeapTimer's callback.
* heap/HeapTimer.h:
(HeapTimer):
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::create): PassOwnPtr all the things.
* heap/IncrementalSweeper.h:
(IncrementalSweeper):
* jsc.cpp:
(jscmain): We use an APIEntryShim instead of a RefPtr for the JSGlobalData because we need to
tear down the JSGlobalData while we still hold the lock, which the APIEntryShim handles correctly.
* runtime/GCActivityCallback.h:
(DefaultGCActivityCallback):
(JSC::DefaultGCActivityCallback::create):
* runtime/JSGlobalData.cpp:
(JSC::JSGlobalData::JSGlobalData):
(JSC::JSGlobalData::~JSGlobalData): Notify the API lock that the JSGlobalData is being torn down.
* runtime/JSGlobalData.h:
(JSGlobalData):
(JSC::JSGlobalData::apiLock):
* runtime/JSLock.cpp:
(JSC::JSLockHolder::JSLockHolder): Ref, then lock (just like the API shim).
(JSC):
(JSC::JSLock::willDestroyGlobalData):
(JSC::JSLockHolder::init):
(JSC::JSLockHolder::~JSLockHolder): Protect, deref, then unlock (just like the API shim).
(JSC::JSLock::JSLock):
* runtime/JSLock.h: Add back pointer to the JSGlobalData and a callback for when the JSGlobalData is being
torn down that clears this pointer to notify other clients (i.e. timer callbacks) that the JSGlobalData is no
longer valid.
(JSLockHolder):
(JSLock):
(JSC::JSLock::globalData):
* testRegExp.cpp:
(realMain): We use an APIEntryShim instead of a RefPtr for the JSGlobalData because we need to
tear down the JSGlobalData while we still hold the lock, which the APIEntryShim handles correctly.


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