Make sure to use CSSValueID and CSSPropertyID rather than integers
https://bugs.webkit.org/show_bug.cgi?id=117481

Reviewed by Benjamin Poulain.

This will ensure that types are enforced when passing arguments in various
css functions. Having a compile time check make sure that no mistakes
will be done over the type.

The parser was also patched to directly use CSSValueID over integers.
This patch also fixes various call sites abusing the usage of integers.
This is part 1 of 2.

No new tests : existing ones should cover.

* WebCore.xcodeproj/project.pbxproj: copy CSSValueKeywords.h as it could be used in WebKit/ for example.
* css/CSSComputedStyleDeclaration.cpp:
(WebCore::valueForRepeatRule):
(WebCore::cssIdentifierForFontSizeKeyword):
(WebCore::identifierForFamily):
(WebCore::valueForFamily):
* css/CSSGrammar.y.in:
* css/CSSParser.cpp:
(WebCore::parseColorValue):
(WebCore::parseKeywordValue):
(WebCore::CSSParser::parseValidPrimitive):
(WebCore::CSSParser::parseValue):
(WebCore::CSSParser::parseContent):
(WebCore::CSSParser::parseBackgroundColor):
(WebCore::CSSParser::parseFillPositionComponent):
(WebCore::CSSParser::parse3ValuesFillPosition):
(WebCore::CSSParser::parseFillRepeat):
(WebCore::CSSParser::parseAnimationProperty):
(WebCore::CSSParser::parseCounterContent):
(WebCore::CSSParser::parseLineHeight):
(WebCore::CSSParser::parseFontSize):
(WebCore::CSSParser::createFontWeightValueKeyword):
(WebCore::CSSParser::parseFontWeight):
(WebCore::parseDeprecatedGradientColorStop):
(WebCore::parseGradientColorOrKeyword):
(WebCore::CSSParser::parseDeprecatedRadialGradient):
(WebCore::CSSParser::rewriteSpecifiers):
* css/CSSParser.h:
* css/CSSParserValues.h:
* css/CSSPrimitiveValue.h:
* css/CSSValuePool.cpp:
(WebCore::CSSValuePool::createIdentifierValue):
* css/CSSValuePool.h:
* css/StylePropertySet.cpp:
(WebCore::MutableStylePropertySet::setProperty):
* css/StylePropertySet.h:
* dom/StyledElement.cpp:
(WebCore::StyledElement::setInlineStyleProperty):
(WebCore::StyledElement::addPropertyToPresentationAttributeStyle):
* dom/StyledElement.h:
* editing/EditingStyle.cpp:
(WebCore::HTMLFontSizeEquivalent::attributeValueAsCSSValue):
(WebCore::EditingStyle::prepareToApplyAt):
* editing/EditorCommand.cpp:
(WebCore::executeApplyStyle):
(WebCore::executeFontSize):
* html/HTMLElement.cpp:
(WebCore::unicodeBidiAttributeForDirAuto):
(WebCore::HTMLElement::applyAlignmentAttributeToStyle):
* html/HTMLFontElement.cpp:
(WebCore::HTMLFontElement::cssValueFromFontSizeNumber):
(WebCore::HTMLFontElement::collectStyleForPresentationAttribute):
* html/HTMLFontElement.h:
* html/HTMLTableElement.cpp:
(WebCore::leakBorderStyle):
* html/track/TextTrackCue.cpp:
(WebCore::TextTrackCue::getCSSWritingDirection):
(WebCore::TextTrackCue::getCSSWritingMode):
* html/track/TextTrackCue.h:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151754 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove the SegmentedVector inline segment to shrink CodeBlock by 6X
https://bugs.webkit.org/show_bug.cgi?id=117808

Reviewed by Geoffrey Garen.

SegmentedVector allocation isn't super hot, but we do tend to have many
live SegmentedVectors at runtime, particularly in CodeBlocks, so the
right tradeoff is to allocate segments out-of-line as needed.

This reduces startup memory usage @ google.com by about 6MB.

No regression on SunSpider.

* wtf/SegmentedVector.h:
(WTF::SegmentedVector::SegmentedVector):
(WTF::SegmentedVector::at):
(WTF::SegmentedVector::append):
(WTF::SegmentedVector::removeLast):
(WTF::SegmentedVector::clear):
(WTF::SegmentedVector::deleteAllSegments): No more inline segment.

(WTF::SegmentedVector::ensureSegmentsFor): This code used to assume
that there was always a 0 segment, so the math would underflow if there
were no 0 segment. I udpated the math to account for having no segments.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151755 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fixed reviewer name

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151756 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Use the PlatformEvent timestamp when creating a DOM Event
https://bugs.webkit.org/show_bug.cgi?id=117179

Patch by Benjamin Poulain <bpoulain@apple.com> on 2013-06-19
Reviewed by Darin Adler.

Source/WebCore: 

Previously, the platform event's timestamp was ignored by WebCore and each
new event would get a new timestamp by calling WTF::currentTime().

The problem is there can be a significant delay between the input event and
it being dispatched to JavaScript. Computing the velocity/acceleration of the cursor
is impossible since the delay vary from event to events.
On WebKit2, the delay per event typically vary between 0 and 30ms.

This patch changes the Event creation code to use the timer passed by the underlying platform event.

* WebCore.exp.in:
* dom/Event.cpp:
(WebCore::Event::Event):
* dom/Event.h:
* dom/GestureEvent.cpp:
(WebCore::GestureEvent::create):
(WebCore::GestureEvent::GestureEvent):
* dom/GestureEvent.h:
* dom/KeyboardEvent.cpp:
(WebCore::KeyboardEvent::KeyboardEvent):
* dom/KeyboardEvent.h:
* dom/MouseEvent.cpp:
(WebCore::MouseEvent::create):
(WebCore::MouseEvent::MouseEvent):
(WebCore::SimulatedMouseEvent::SimulatedMouseEvent):
* dom/MouseEvent.h:
* dom/MouseRelatedEvent.cpp:
(WebCore::MouseRelatedEvent::MouseRelatedEvent):
* dom/MouseRelatedEvent.h:
* dom/TouchEvent.cpp:
(WebCore::TouchEvent::TouchEvent):
* dom/UIEvent.cpp:
(WebCore::UIEvent::UIEvent):
* dom/UIEvent.h:
* dom/UIEventWithKeyState.h:
(WebCore::UIEventWithKeyState::UIEventWithKeyState):
* dom/WheelEvent.cpp:
(WebCore::WheelEvent::WheelEvent):
(WebCore::WheelEventDispatchMediator::WheelEventDispatchMediator):
* dom/WheelEvent.h:
(WebCore::WheelEvent::create):
* page/EventHandler.cpp:
(WebCore::EventHandler::dispatchDragEvent):
* platform/mac/PlatformEventFactoryMac.mm:
(WebCore::PlatformMouseEventBuilder::PlatformMouseEventBuilder):
(WebCore::PlatformWheelEventBuilder::PlatformWheelEventBuilder):
(WebCore::PlatformKeyboardEventBuilder::PlatformKeyboardEventBuilder):
(WebCore::PlatformGestureEventBuilder::PlatformGestureEventBuilder):

Source/WebKit/mac: 

* WebView/WebPDFView.mm:
(-[WebPDFView PDFViewWillClickOnLink:withURL:]):

Source/WebKit2: 

* Shared/mac/WebEventFactory.mm:
(WebKit::WebEventFactory::createWebMouseEvent):
(WebKit::WebEventFactory::createWebWheelEvent):
(WebKit::WebEventFactory::createWebKeyboardEvent):
(WebKit::WebEventFactory::createWebGestureEvent):

Tools: 

* WebKitTestRunner/mac/EventSenderProxy.mm:
(WTR::EventSenderProxy::mouseDown):
(WTR::EventSenderProxy::mouseUp):
(WTR::EventSenderProxy::mouseMoveTo):
(WTR::EventSenderProxy::keyDown):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151757 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rebaseline 24bit-22khz-resample on Mac

The result did not match the expectation after a system update.

Patch by Benjamin Poulain <bpoulain@apple.com> on 2013-06-19

* platform/mac-wk2/webaudio/codec-tests/wav/24bit-22khz-resample-expected.wav:
Comparing the files, they have the exact same length, sample rate, bit per sample and binary size.
I cannot ear a difference in the files.


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