After bug 157855 is fixed, getting the scrollTop/Left properties of both documentElement and body elements follow the behavior of other Web engines (Firefox, IE, Opera12, Safari), according to the HTML mode used (strict or quirks):

- in strict mode
documentElement.scrollTop, returns the frame Y scroll position.
body.scrollTop, returns always 0.
- in quirks mode
documentElement.scrollTop, returns always 0.
body.scrollTop, returns the frame Y scroll position.

(Same logic applies for scrollLeft).

However, now Blink has an asymmetry between the way scrollTop/Left values are gotten and the way they are set, regardless of the HTML mode used:

- in both strict and quirks modes
documentElement.scrollTop = xx, is no op
body.scrollTop = xx, sets the frame Y scroll position to "xx"

Patch fixes it making the "set" operations of scrollTop/Left for documentElement and body elements symmetric to their get operations' behavior, according to the HTML mode used. It also makes Blink to match all other Web engines. Result is:

- in strict mode
documentElement.scrollTop, returns the frame Y scroll position.
documentElement.scrollTop = xx, sets the frame Y scroll position to "xx".
body.scrollTop, returns always 0.
body.scrollTop = xx, is no op.

- quirks mode
documentElement.scrollTop, returns always 0.
documentElement.scrollTop = xx, is no op.
body.scrollTop, returns the frame Y scroll position.
body.scrollTop = xx, sets the frame Y scroll position to "xx".

(Same logic applies for scrollLeft).

An optimistic approach was chosen for this behavior change, with respect to not measure the usage of these properties beforehand. Rationale is that all WebSites already have to deal with the Blink divergent behavior and other Web engines behavior anyways, so if Blink starts to follow other engines, there should not be breakages.

New tests:
* fast/dom/Element/scrollTop-scrollLeft-strict-quirks-modes.html
Updated existing tests:
* fast/events/touch/resources/compositor-touch-hit-rects-iframe.html
* fast/events/touch/resources/compositor-touch-hit-rects-iframe-fixed.html
* compositing/scissor-out-of-viewport.html
* fast/multicol/scrolling-overflow.html
* fast/css/zoom-body-scroll.html
* fast/css/resize-corner-tracking-touch.html
* fast/repaint/resources/iframe-scroll-repaint-iframe.html
* fast/events/touch/resources/compositor-touch-hit-rects-iframe-nested.html
* fast/events/touch/gesture/touch-gesture-fully-scrolled-iframe-propagates.html

BUG=303131

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

git-svn-id: svn://svn.chromium.org/blink/trunk@159035 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Remove 3 unused booleans from CSSParserContext

These members were never set nor read.

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

git-svn-id: svn://svn.chromium.org/blink/trunk@159036 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Remove Node::reattach lazy attach performance hack

Now that we always lazy attach we don't need the detachNode hack in
Node::reattach. Instead we can just allow calling into Node::attach
even if attached() is true as long as styleChangeType() is the type
set by lazyAttach. I renamed LazyAttachStyleChange to
NeedsAttachStyleChange as well since that better reflects what it
means.

This removes another tree walk when appending new nodes.

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

git-svn-id: svn://svn.chromium.org/blink/trunk@159037 bbb929c8-8fbe-4397-9dbb-9b2b20218538
[HTML Imports] Add a testcase for "element removed flag".

This change adds a test for "element removed flag" concept in the spec:
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/imports/index.html#dfn-element-removed-flag

Blink already behaves in this way and this test is just for capturing
current behavior.

TEST=import-element-removed-flag.html
R=dglazkov@chromium.org,rafaelw@chromium.org
BUG=302312

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

git-svn-id: svn://svn.chromium.org/blink/trunk@159038 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Refactor fixed layout mode

Previously, the desktop browser would use FrameView's rect
as the layout size while the mobile browser would enable
"fixed layout mode" which then used a layoutSize variable
that it could set instead.

This CL removes "fixed layout mode" as a FrameView concept
and makes the layout size always an explicitly set property
of the main FrameView. Another way to think about it is that
we're now always in a fixed-layout, only we keep
the layout size pegged to the window size (if the
--enable-viewport flag is set, the layout size is set from
@viewport/viewport meta).

Note: WebViewImpl still has a setFixedLayoutSize method 
that's used by Android WebView.

BUG=285397

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

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