Track controls show metadata and chapter tracks
https://bugs.webkit.org/show_bug.cgi?id=122468

Patch by Brendan Long <b.long@cablelabs.com> on 2013-10-10
Reviewed by Darin Adler.

Source/WebCore:

Test: media/video-controls-captions-trackmenu-only-captions-descriptions-and-subtitles.html

* page/CaptionUserPreferences.cpp:
(WebCore::CaptionUserPreferences::sortedTrackListForMenu): Only show captions, descriptions and subtitles in the track controls.

LayoutTests:

Add a test to make sure we don't show metadata and chapter tracks in the track controls.

* media/video-controls-captions-trackmenu-only-captions-descriptions-and-subtitles-expected.txt: Added.
* media/video-controls-captions-trackmenu-only-captions-descriptions-and-subtitles.html: Added.
* platform/efl/TestExpectations: Skip, uses caption button, not track menu.
* platform/mac/TestExpectations: Skip, track menu tests all fail on Mac.
* platform/win/TestExpectations: Same.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157290 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Layout Test fast/css/font-face-download-error.html is flaky
https://bugs.webkit.org/show_bug.cgi?id=122636

Reviewed by Darin Adler.

* fast/css/font-face-download-error-expected.txt: TEST COMPLETE is now printed
after the test is complete.

* fast/css/font-face-download-error.html: Changed to properly wait for fonts to load.
Also, updated to use a proper async test implementation.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157291 268f45cc-cd09-0410-ab3c-d52691b4dbfc
contentEditable with "position:relative" paragraphs is buggy
https://bugs.webkit.org/show_bug.cgi?id=33950

Patch by Santosh Mahto <santosh.ma@samsung.com> on 2013-10-10
Reviewed by Darin Adler.

Source/WebCore:

When paragraph is positioned(relative/absolute/fixed) then deleting
that paragraph cause wrong merging of other(below) paragraphs. This is
happening because positioned element is treated as special element and
on deletion complete paragraph element is removed. The ranges become
paragraph. This issue happens when all the content of special element
are deleted. So the merging of paragraph is avoided in this scenario.

Test: editing/deleting/deleting-relative-positioned-special-element.html

* editing/DeleteSelectionCommand.cpp:
(WebCore::DeleteSelectionCommand::initializeStartEnd):Avoid merging
block when special candidate are included in deletion range

LayoutTests:

LayoutTests:

Added a testcase to verify that when paragraph is relative positioned
then deleting the all content of paragraph should not incorrectly collapse the
others(below) paragraphs.
And Rebaseline the test expectation.

* editing/deleting/5546763-expected.txt: Updated.
* editing/deleting/deleting-relative-positioned-special-element-expected.txt: Added.
* editing/deleting/deleting-relative-positioned-special-element.html: Added.
* editing/unsupported-content/table-delete-001.html: Adjusted to dump
as markup.
* editing/unsupported-content/table-delete-003.html: Adjusted to dump
as markup.

Below tests had wrong cursor position previously now corrected and
both expected file has been changed to markup dump.
* platform/mac/editing/unsupported-content/table-delete-001-expected.txt:
* platform/mac/editing/unsupported-content/table-delete-003-expected.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157292 268f45cc-cd09-0410-ab3c-d52691b4dbfc
FTL shouldn't pass i1's into llvm.webkit.stackmap's
https://bugs.webkit.org/show_bug.cgi?id=122629
<rdar://problem/15203037>

Reviewed by Sam Weinig and Nadav Rotem.
        
LLVM's stackmap support requires that we only pass operands with legal types (i.e. types
that are hardware-representable). i1, which the FTL previously used for Booleans, is not
legal.
        
We have two options: either add support in LLVM to legalize stackmap operands, or add
support to the FTL to legalize stackmap operands. It's easier to fix this in FTL, and
that's what this patch does.

* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157293 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Make EventPath private to EventDispatcher.cpp
https://bugs.webkit.org/show_bug.cgi?id=122638

Reviewed by Darin Adler.

Move the declaration of EventPath into EventDispatcher.cpp since EventPath is only used in this file.
Also make EventDispatcher a namespace since it is never instantiated since r157250.

* dom/EventDispatcher.cpp:
(WebCore::EventPath::isEmpty):
(WebCore::EventPath::size):
(WebCore::EventPath::contextAt):
(WebCore::EventPath::lastContextIfExists):
* dom/EventDispatcher.h:
* inspector/InspectorInstrumentation.h:
(WebCore::InspectorInstrumentation::willDispatchEvent):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157294 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[sh4] Fix build after r157209.
https://bugs.webkit.org/show_bug.cgi?id=122643

Patch by Julien Brianceau <jbriance@cisco.com> on 2013-10-11
Reviewed by Ryosuke Niwa.

* assembler/MacroAssemblerSH4.h: Add framePointerRegister declaration.
* assembler/SH4Assembler.h: Add firstRegister() declaration.
(JSC::SH4Assembler::firstRegister):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157295 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION (r155607): Javascript site does not load visually on panerabread.com
https://bugs.webkit.org/show_bug.cgi?id=122461

Reviewed by Simon Fraser.

Do not modify the composited layer backing's internal layer structure directly
when the clipping behaviour changes.

When we directly create/destroy RenderLayerBacking::m_ancestorClippingLayer to
reflect the new clipping state, other, depending layers need updating. In order to
not to corrupt the internal hierarchy, mark the compositing layers dirty and let
the normal updating mechanism take care of creating/destroying the ancestor layers.

Source/WebCore:

Existing tests are extended.

* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::checkIfDescendantClippingContextNeedsUpdate):
(WebCore::RenderLayer::styleChanged):
* rendering/RenderLayer.h:
* rendering/RenderLayerBacking.h:

LayoutTests:

* compositing/overflow/clipping-behaviour-change-is-not-propagated-to-descendants-expected.txt:
* compositing/overflow/clipping-behaviour-change-is-not-propagated-to-descendants.html:
* compositing/overflow/clipping-behaviour-change-is-not-propagated-to-descendants2-expected.txt:
* compositing/overflow/clipping-behaviour-change-is-not-propagated-to-descendants2.html:
* platform/mac/compositing/overflow/clipping-behaviour-change-is-not-propagated-to-descendants-expected.txt:
* platform/mac/compositing/overflow/clipping-behaviour-change-is-not-propagated-to-descendants2-expected.txt:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157296 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Make RenderLayer not arena-allocated.
<https://webkit.org/b/87523>

Reviewed by Antti Koivisto.

Let RenderLayerModelObject store its RenderLayer in a unique_ptr.
Layers are relatively low-volume objects and this looks neutral
on our performance tests.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157297 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Use after free in WebCore::DisplayRefreshMonitorClient::fireDisplayRefreshIfNeeded
http://webkit.org/b/121033

Reviewed by Darin Adler.

Source/WebCore:

Add an ASSERT to detect if an animation client will be removed
during the callback dispatch.

Test: fast/animation/request-animation-frame-remove-client.html

* platform/graphics/DisplayRefreshMonitor.cpp:
(WebCore::DisplayRefreshMonitor::displayDidRefresh):

LayoutTests:

Test that assertion fires if you try to remove potential client while in a
animation dispatch.

* TestExpectations: Mark test as crashing.
* fast/animation/request-animation-frame-remove-client-expected.txt: Added.
* fast/animation/request-animation-frame-remove-client.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157298 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebCore: Use after free in WebCore::DisplayRefreshMonitorClient::fireDisplayRefreshIfNeeded
https://bugs.webkit.org/show_bug.cgi?id=121033

Patch by Darin Adler <darin@apple.com> on 2013-10-10
Reviewed by Dean Jackson.

For safe iteration, use a set rather than a vector, and remove the clients from
the set if they are removed during iteration.

Test: fast/animation/request-animation-frame-remove-client.html

* platform/graphics/DisplayRefreshMonitor.cpp:
(WebCore::DisplayRefreshMonitor::DisplayRefreshMonitor): Initialize the
m_clientsToBeNotified pointer to null.
(WebCore::DisplayRefreshMonitor::removeClient): If there is a m_clientsToBeNotified
set, remove from it as well as the real m_clients set.
(WebCore::DisplayRefreshMonitor::displayDidRefresh): Use a HashSet instead of a
vector for the copy of the clients set we iterate.

* platform/graphics/DisplayRefreshMonitor.h: Moved some of the BlackBerry-specific
part of this out of the header. Added a new HashSet pointer, m_clientsToBeNotified,
to be used to remove clients during the notification process. Also added a FIXME.

* platform/graphics/blackberry/DisplayRefreshMonitorBlackBerry.cpp: Moved the
DisplayAnimationClient class in here.

LayoutTests: Use after free in WebCore::DisplayRefreshMonitorClient::fireDisplayRefreshIfNeeded
http://webkit.org/b/121033

Update test to indicate it no longer crashes.

* TestExpectations: Mark test as passing.
* fast/animation/request-animation-frame-remove-client-expected.txt:
* fast/animation/request-animation-frame-remove-client.html:

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