Web Animations: Implement AnimationClock and fix start time of animations

We currently update the current time of the DocumentTimeline only when
serviceAnimations is called and when we set the zero time. As a result,
when we start animations/transitions (without any currently running),
their start time will be incorrect since the current time won't have
been updated recently.

This patch adds an AnimationClock to fix this issue. The
DocumentTimeline will pass time updates on to the clock when it gets
them (serviceAnimations). The clock has a notion of being 'frozen',
which corresponds to having an up to date time.  When it is not frozen,
the next call to AnimationClock::currentTime() will update the time, so
newly started animations have up to date times. We always unfreeze after
a document style recalc finishes, and freeze at the end of updateTime().

Note that the AnimationClock is on Document and not the DocumentTimeline
since a TransitionTimeline is going to be added in a later patch which
will need to refer to the same clock.

The TestExpectation change is for a test which waits 200ms before
starting an animation.

BUG=258896

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=160071

Review URL: https://codereview.chromium.org/26491013

git-svn-id: svn://svn.chromium.org/blink/trunk@160171 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Invert logic that prevented style sharing in findSharedStyle().

https://src.chromium.org/viewvc/blink?view=rev&revision=159972 contained
a bug that prevented style sharing. This patch inverts the logic
so that if the parent supports style sharing, we do not return 0 from
SharedStyleFinder::findSharedStyle().

BUG=309935

Review URL: https://codereview.chromium.org/33183010

git-svn-id: svn://svn.chromium.org/blink/trunk@160172 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Move some checks from SharedStyleFinder::canShareStyleWithElement to Element::supportsStyleSharing

The checks for tagName and full screen can be decided before we even
put the element into the candidate list. This reduces the number of
checks when looking for a sharing candidate and also opens spaces in
the candidate list for elements which can actually share since putting
<iframe> or other elements in the list was just wasting space and
evicting elements that possibly could have shared.

This may improve sharing on pages with many <option> elements since
previously we would have filled the sharing list with them even though
none of them can actually share. Now we'll skip even putting them in
the list so after recalcing style on a <select> with many elements we'll
still have a style sharing list full of elements to share with the elements
that are after the <select>.

Review URL: https://codereview.chromium.org/34153004

git-svn-id: svn://svn.chromium.org/blink/trunk@160173 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Remove HTMLMediaElement.startTime

It was replaced with initialTime in August 2010:
http://html5.org/r/5310

BUG=309473

Review URL: https://codereview.chromium.org/32583003

git-svn-id: svn://svn.chromium.org/blink/trunk@160174 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Support <input type=image> for submission to a <dialog>

As described in
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#submit-dialog

BUG=304827

Review URL: https://codereview.chromium.org/31823002

git-svn-id: svn://svn.chromium.org/blink/trunk@160175 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Add a clarification comment to WebSocketHandshake::m_response

Explains what kind of change can be made from the original data received from
the server.

BUG=none

Review URL: https://codereview.chromium.org/31753002

git-svn-id: svn://svn.chromium.org/blink/trunk@160176 bbb929c8-8fbe-4397-9dbb-9b2b20218538
scroll: Tell the platform layer whether it can be scrolled by the user.

BUG=175502

Review URL: https://codereview.chromium.org/33413002

git-svn-id: svn://svn.chromium.org/blink/trunk@160177 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Remove code in Editor::rangeOfString() that unnecessarily resets the searchRange after the first find operation.

Currently, Editor::RangeOfString() sets the start and end positions for the searchRange depending on the findOptions.findNext option's value. If 'StartInSelection' has been set (for findNext) then the start of the searchRange would point to the start of the current active (matched) selection.
Thus the search would begin from this point and the current active selection will be returned as the result/matched range in case the search keyword is same as for the previous find operation.

But, right after this resultRange is obtained, we have code (in rangeOfString()) that compares the new resultRange with the current active range and if found to be the same (which would be the case when the search keyword remains the same), it resets the start and end positions of the searchRange, this time from after the current active selection, irrespective of whatever the findOptions.findNext value is set to, and then performs another find operation to get a new resultRange. This new resultRange (if found) would thus lie beyond the previous active (matched) selection.

This results in erroneous behavior for scenarios wherein, even though the user/application doesn't move to the next match, simply performing another find operation using the same keyword would unnecessarily increment the activeMatch range as well as count.

I found this code to have been added in the patch: http://trac.webkit.org/changeset/14782. However, the changelog just states: "(WebCore::Frame::findString): Moved from FrameMac. Compare a selection created using the found range with the current selection in case the current selection is the found range minus some collapsed whitespace on the edges."

This change should not cause any of the existing tests (layout as well as unit tests) to fail.

Review URL: https://codereview.chromium.org/34503002

git-svn-id: svn://svn.chromium.org/blink/trunk@160178 bbb929c8-8fbe-4397-9dbb-9b2b20218538