ASSERTION FAILED: name[0] == '@' && length >= 2 in WebCore::CSSParser::detectAtToken
https://bugs.webkit.org/show_bug.cgi?id=134632

Source/WebCore:

At-rules must consist of at least two characters: the '@' symbol followed by
an identifier name. The failure of this condition makes the assertion fail.

The length of an at-rule is currently calculated by pointer arithmetic on
the 'result' pointer, which is expected to be set to the end of the at-rule
identifier by the WebCore::*CSSTokenizer::parseIdentifier method.
If the at-rule token is a sequence of 8-bit-only characters then
'result' will point correctly at the end of the identifier. However, if
the at-rule contains a 16-bit Unicode escape then 'result' will not be
updated correctly anymore, hence it cannot be used for length calculation.
The patch makes the parseIdentifier bump the result pointer even in the 16-bit slow case.

Patch by Renata Hodovan, backported from Chromium: https://codereview.chromium.org/241053002

Patch by Martin Hodovan <mhodovan.u-szeged@partner.samsung.com> on 2014-08-05
Reviewed by Darin Adler.

Test: fast/css/atrule-with-escape-character-crash.html

* css/CSSParser.cpp:
(WebCore::CSSParser::realLex):

LayoutTests:

Added test demonstrates that at-rules containing 16-bit Unicode characters
can be handled properly.

Patch by Martin Hodovan <mhodovan.u-szeged@partner.samsung.com> on 2014-08-05
Reviewed by Darin Adler.

* fast/css/atrule-with-escape-character-crash-expected.txt: Added.
* fast/css/atrule-with-escape-character-crash.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@172036 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: shown() called on a content view when stepping over an instruction in the debugger
https://bugs.webkit.org/show_bug.cgi?id=135311

Patch by Saam Barati <sbarati@apple.com> on 2014-08-05
Reviewed by Timothy Hatcher.

ContentViewContainer should not repeatedly call ContentView.prototype.shown
on ContentViews that are already visible. ContentViewContainer now passes
a flag to BackForwardEntry.prototype.prepareToShow indicating whether it should
call the shown function on the ContentView it is about to display.
ContentViewContainer.prototype.showBackForwardEntryForIndex passes in this
flag based on its ContentView being visible.

* UserInterface/Models/BackForwardEntry.js:
(WebInspector.BackForwardEntry.prototype.prepareToShow):
* UserInterface/Views/ContentViewContainer.js:
(WebInspector.ContentViewContainer.prototype.showBackForwardEntryForIndex):
(WebInspector.ContentViewContainer.prototype.replaceContentView):
(WebInspector.ContentViewContainer.prototype.closeAllContentViewsOfPrototype):
(WebInspector.ContentViewContainer.prototype.shown):
(WebInspector.ContentViewContainer.prototype._showEntry):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@172038 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION: Extremely flashy scrolling while a page is still loading (because of flush throttling)
https://bugs.webkit.org/show_bug.cgi?id=135603
<rdar://problem/17876385>

Reviewed by Andreas Kling.

* page/FrameView.cpp:
(WebCore::determineLayerFlushThrottleState):
        
    Disable throttling after user has scrolled the page.
    This is consistent with the speculative tiling. It also gets enabled on first scroll.

(WebCore::FrameView::setWasScrolledByUser):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@172039 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: cannot navigate between multiple applicable dashboards
https://bugs.webkit.org/show_bug.cgi?id=135130

Reviewed by Timothy Hatcher.

Add navigation arrows between dashboards when multiple dashboards are applicable.
For example, the user should be able to go back to the default dashboard while paused
at a breakpoint. Dashboards form a stack based on when they are first introduced.

* UserInterface/Views/DashboardContainerView.css:
(.toolbar .dashboard): Increase padding-right a bit to make room for arrows.
(.toolbar .dashboard:not(.visible)): Fix a bug where higher dashboards in the dashboard stack
can shine through when animating between two lower dashboards that have transparent background.
This ensures that at most two dashboards (namely, the ones being animated) are displayed.

(.dashboard-container .advance-arrow): Main style class for navigation arrows.
(.dashboard-container .advance-arrow:hover):
(.dashboard-container .advance-arrow:active):
(.dashboard-container .advance-arrow.inactive):
(.toolbar.label-only .dashboard-container .advance-arrow): Make arrows slightly smaller when
the dashboards get shorter.

(.dashboard-container .advance-arrow.advance-forward):
(.dashboard-container .advance-arrow.advance-backward):
* UserInterface/Views/DashboardContainerView.js:
(WebInspector.DashboardContainerView): Arrow styles are updated when a dashboard is shown,
hidden, or closed. When moving away, we dismiss (i.e., set zero opacity) arrows at animation
start. When the animation finishes, redisplay arrows that are applicable for the new dashboard.

(WebInspector.DashboardContainerView.prototype._advanceForwardArrowClicked):
(WebInspector.DashboardContainerView.prototype._advanceBackwardArrowClicked):
(WebInspector.DashboardContainerView.prototype._dismissAdvanceArrows):
(WebInspector.DashboardContainerView.prototype._updateAdvanceArrowVisibility):
(WebInspector.DashboardContainerView.prototype._showDashboardAtIndex): There was a bug here
where it would unconditionally use the same animation direction when showing a dashboard, but
it was hard to spot without arrows that must correlate with the animation direction.

(WebInspector.DashboardContainerView.prototype.animationEnded):
(WebInspector.DashboardContainerView.prototype._showDashboardView):
(WebInspector.DashboardContainerView.prototype._hideDashboardView):
(WebInspector.DashboardContainerView.prototype._closeDashboardView):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@172044 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Media iOS] Ensure there is a nice default fallback for missing wireless target names
https://bugs.webkit.org/show_bug.cgi?id=135488
<rdar://problem/17879156>

Reviewed by Antoine Quint.

Antoine found me on iMessage to tell me I'm an idiot and that I've
forgotten how to write JavaScript. Embarrassingly, this code is what
I originally had, but then second-guessed myself.

* Modules/mediacontrols/mediaControlsiOS.js:
(ControllerIOS.prototype.updateWirelessPlaybackStatus): No need for the local
variable or conditional statement, since null and "" both evaluate as false.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@172047 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rename MAC_LONG_PRESS feature flag to LONG_MOUSE_PRESS.
https://bugs.webkit.org/show_bug.cgi?id=135276

Patch by Peyton Randolph <prandolph@apple.com> on 2014-08-05
Reviewed by Beth Dakin.

Source/JavaScriptCore:

* Configurations/FeatureDefines.xcconfig:

Source/WebCore:

No new tests. Just a compiler flag.

* Configurations/FeatureDefines.xcconfig:

Source/WebKit/mac:

* Configurations/FeatureDefines.xcconfig:

Source/WebKit2:

* Configurations/FeatureDefines.xcconfig:

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