Fix & clarify some comments in compositing. Rename clippedByAncestor to more accurately
describe what it actually does.

BUG=

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173017 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Make default for deep parameter in importNode false, as specified in:

http://dom.spec.whatwg.org/#document

Update tests to reflect this change. It matches Firefox behavior.

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173018 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Auto-rebaseline for r172887

http://src.chromium.org/viewvc/blink?view=revision&revision=172887

BUG=320139
TBR=leviw@chromium.org

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173019 bbb929c8-8fbe-4397-9dbb-9b2b20218538
[FastTextAutosizer] Remove printing checks from enabled()

This is first of two patches to refactor our enabled() code for
understandability. This patch removes the document->printing() check
from enabled() and refactors updatePageInfo to reduce duplicated code.
When printing is enabled / disabled, updatePageInfo is always called
which is what enables this refactoring. Printing doesn't change often so
there's no reason to check it multiple times for each block :)

Cleanups:
1) enabled() has been merged into shouldHandleLayout() since all callers
always checked both.
2) We had duplicated logic for the two cases when we should reset
multipliers in updatePageInfo. These have been combined and changing
"m_hasAutosized" has been moved out of resetMultipliers and into
updatePageInfo so almost no PageInfo-related state is modified outside
updatePageInfo.
3) Unnecessary calls to m_document->page()->mainFrame() have been
removed in updatePageInfo.

This change is a little messy but I hope it's clear how much of this
will be cleaned up once enabled() goes away. Slimming down enabled()
will be a perf win as well.

BUG=367864

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173020 bbb929c8-8fbe-4397-9dbb-9b2b20218538
ServiceWorker: "minimal" end-to-end sample as a W3C test

A few NYI things are commented out.

Also removes [NoInterfaceObject] from ServiceWorkerContainer since
script should be able to see the type.

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173022 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Separate repaint and layout requirements of StyleDifference (Step 3)

Step 1 and 2 replaced StyleDifference enum with StyleDifference class
but still didn't change any functionality.

This change allows multiple types of flags set in StyleDifference, in
the following cases:

1. Both needsRepaint and needsPositionedMovement: This was a full layout
   when StyleDifference enum couldn't express the exact needs of the
   case. Now we can do a repaint and positioned movement without full
   layout.

2. Both needsRepaintLayer and needsFullLayout: Previously, the needs of
   repainting layer must be checked again (about clip, transform,
   opacity etc.) in RenderLayerModelObject::styleWillChange() if layout
   is also needed. Now we can go through the normal needsRepaintLayer
   path.

3. Both needsRepaint and needsFullLayout: Previously as the repaint
   needs couldn't be explicitly expressed, we have to do a full repaint.
   In this change we still keep the original behavior unchanged.
   Will optimize in later changes.

4. Both contextSensitiveProperties and needsLayout: Now this is
   resolved by RenderObject::adjustStyleDifference() to layout only
   or case 1, 2 or 3.

Only case 2 changes the visible behavior. All rebaselined layout tests
are in this case. The extra repaint rects are because now the code
schedules both direct repaints and repaints caused by layer position
change.

BUG=358460
TEST=existing layout tests, several rebaselined.

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173023 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Make sure we correctly dispatch custom events having the same names as unprefixed animations events

If support for unprefixed animations is disabled and a custom event happens
to have the same type name then we should dispatch them no matter.

As inside blink we dispatch unprefixed events (no matter if the support is on
or off), we had a piece of code which was retargeting the name to unprefixed when
the support was off. This was not working in the case of custom events as they were
being retargeted to prefixed. I'm glad we can get rid of this condition when the
support of unprefixed animations ships.

I've added a set of tests in the stable/ directory to specifically covers the fact
that the unprefixed animations support is off. These two tests can be removed when
unprefixed animations are default. The other tests in the regular animations/ directory
are for regression testing.

BUG=367537

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

git-svn-id: svn://svn.chromium.org/blink/trunk@173024 bbb929c8-8fbe-4397-9dbb-9b2b20218538
[New Multicolumn] Faster and more direct RenderMultiColumnSet::multiColumnFlowThread().

No need to go via the parent block to get the flow thread.

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

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