Use std::unique_ptr in JSClassRef and JSCallbackObject
https://bugs.webkit.org/show_bug.cgi?id=138402

Reviewed by Geoffrey Garen.

* API/JSCallbackObject.h: Use std::unique_ptr instead of OwnPtr|PassOwnPtr.
(JSC::JSCallbackObjectData::setPrivateProperty): ditto.
* API/JSClassRef.cpp: ditto.
* API/JSClassRef.h: ditto.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@175651 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, EFL build fix since r175647

* CMakeLists.txt: Remove DeleteButton.cpp and DeleteButtonController.cpp.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@175652 268f45cc-cd09-0410-ab3c-d52691b4dbfc
PutById inline caches should have a store barrier when it triggers a structure transition.
<https://webkit.org/b/138441>

Reviewed by Geoffrey Garen.

After r174025, we no longer insert DFG store barriers when the payload of a
PutById operation is not a cell.  However, this can lead to a crash when we have
PutById inline cache code transitioning the structure and re-allocating the
butterfly of an old gen object.  The lack of a store barrier in that inline
cache results in the old gen object not being noticed during an eden GC scan.
As a result, its newly allocated butterfly will not be kept alive, which leads
to a stale butterfly pointer and, eventually, a crash.

It is also possible that the new structure can be collected by the eden GC if
(at GC time):
1. It is in the eden gen.
2. The inline cache that installed it has been evicted.
3. There are no live eden gen objects referring to it.

The chances of this should be more rare than the butterfly re-allocation, but
it is still possible.  Hence, the fix is to always add a store barrier if the
inline caches performs a structure transition.

* jit/Repatch.cpp:
(JSC::emitPutTransitionStub):
- Added store barrier code based on SpeculativeJIT::storeToWriteBarrierBuffer()'s
  implementation.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@175653 268f45cc-cd09-0410-ab3c-d52691b4dbfc
AX: add "alt" as an overriding synonym of "-webkit-alt" (now in the CSS4 spec)
https://bugs.webkit.org/show_bug.cgi?id=138393

Reviewed by Dean Jackson.

Source/WebCore:

Add official "alt" CSS keyword and map -webkit-alt to that.

Test: platform/mac/accessibility/alt-for-css-content.html

* css/CSSComputedStyleDeclaration.cpp:
(WebCore::ComputedStyleExtractor::propertyValue):
* css/CSSParser.cpp:
(WebCore::CSSParser::parseValue):
* css/CSSPropertyNames.in:
* css/StyleResolver.cpp:
(WebCore::StyleResolver::applyProperty):

LayoutTests:

* platform/mac/accessibility/alt-for-css-content-expected.txt: Added.
* platform/mac/accessibility/alt-for-css-content.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@175654 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Assertion hit DOMTimer::updateTimerIntervalIfNecessary()
https://bugs.webkit.org/show_bug.cgi?id=138440

Reviewed by Geoffrey Garen.

Source/WebCore:

We sometimes hit the ASSERT(repeatInterval() == previousInterval)
assertion in DOMTimer::updateTimerIntervalIfNecessary() when visiting
the following pages:
http://lifehacker.com/the-healthiest-foods-for-one-handed-snacking-while-gami-1654728164
http://longform.org/posts/like-something-the-lord-made

After debugging, the issue turned out to be that we are comparing
floating point numbers using ==, and the check sometimes fails even
though the values really close to each other. This patch updates the
DOMTimer code to use WTF::withinEpsilon() instead of operator==()
to compare the floating point intervals.

I confirmed manually that the assertion is no longer hit.

* page/DOMTimer.cpp:
(WebCore::DOMTimer::updateTimerIntervalIfNecessary):
* platform/graphics/FloatQuad.cpp:
(WebCore::FloatQuad::isRectilinear):
(WebCore::withinEpsilon): Deleted.

Source/WTF:

Move the withinEpsilon() function to WTF to avoid code duplication.

* wtf/MathExtras.h:
(WTF::withinEpsilon):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@175655 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Avoid backing store for opacity:0 descendant layers
https://bugs.webkit.org/show_bug.cgi?id=138448

Reviewed by Dean Jackson.

Source/WebCore:

If a composited layer has no rendered content but a painting zero-opacity descendant
layer, than we can avoid making backing store.

When the opacity on such a child changes, we need to trigger a tree rebuild
to force the backing store to come back (this could be optimized later).

Tests: compositing/backing/no-backing-for-opacity-0-child.html
       compositing/backing/toggle-opacity-0-child.html

* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::calculateClipRects):
* rendering/RenderLayerCompositor.cpp:
(WebCore::styleChangeRequiresLayerRebuild):
* rendering/RenderObject.cpp:
(WebCore::RenderObject::containerForRepaint):

LayoutTests:

Test for no backing store with opacity:0 child, and that we get backing
store when dynamically changing the opacity to non-0.

* compositing/backing/no-backing-for-opacity-0-child-expected.txt: Added.
* compositing/backing/no-backing-for-opacity-0-child.html: Added.
* compositing/backing/toggle-opacity-0-child-expected.txt: Added.
* compositing/backing/toggle-opacity-0-child.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@175656 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Revert r175441 as it seems to be causing intermittent crashes in DOMTimer
https://bugs.webkit.org/show_bug.cgi?id=138449

Unreviewed roll out.

Revert r175441 as it seems to be causing intermittent crashes in DOMTimer due
to the scriptExecutionContext going away. See <rdar://problem/18883681>.

* page/DOMTimer.cpp:
(WebCore::DOMTimer::install):
(WebCore::DOMTimer::fired):
(WebCore::NestedTimersVector::NestedTimersVector): Deleted.
(WebCore::NestedTimersVector::~NestedTimersVector): Deleted.
(WebCore::NestedTimersVector::registerTimer): Deleted.
(WebCore::NestedTimersVector::begin): Deleted.
(WebCore::NestedTimersVector::end): Deleted.

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