updateDescendantDependentFlags before updating compositing

This CL changes makes the compositing update call updateDescendantDependentFlags
before entering InCompositingUpdate because updateDescendantDependentFlags can
generate dirtiness that the compositing update needs to clean.

Also, remove a number of unnecessary calls to updateDescendantDependentFlags and
one unnecessary call to updateZOrderLists.  Now that these functions are called
only during the compositing update, we know that this information is already
up-to-date.

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

git-svn-id: svn://svn.chromium.org/blink/trunk@176637 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Revert of Add unittest for OpenTypeSanitizer (https://codereview.chromium.org/316343004/)

Reason for revert:
Crashes on WebKit Android (Nexus4) bot:

http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Android%20%28Nexus4%29/builds/14966

[----------] 1 test from OpenTypeSanitizerTest
[ RUN      ] OpenTypeSanitizerTest.TestWOFF
../../third_party/WebKit/Source/platform/fonts/opentype/OpenTypeSanitizerTest.cpp:54: Failure
Expected: (buffer->size()) >= (4u), actual: 0 vs 4
[ CRASHED      ]

Original issue's description:
> Add unittest for OpenTypeSanitizer
> 
> Since TestingPlatformSupport::unitTestSupport() doesn't implement required methods(webKitRootDir and readFromFile), I needed to put this test in platform_web_unittest_files.
> 
> BUG=371267
> 
> Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=176593

TBR=jamesr@chromium.org
NOTRY=true

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

git-svn-id: svn://svn.chromium.org/blink/trunk@176638 bbb929c8-8fbe-4397-9dbb-9b2b20218538
There's no reason for RenderLayerStackingNode::collectLayers to call updateDescendantDependentFlags

RenderLayerStackingNode::collectLayers doesn't read any descendant-dependent
information.

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

git-svn-id: svn://svn.chromium.org/blink/trunk@176639 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Have GlyphBuffer track vertical advances and pass this to Skia.

This is quicker than having Skia figure it out after the fact, since we
already know in the simple text path that there are no vertical advances
(and so drawPosTextH can be safely used).

BUG=387166

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

git-svn-id: svn://svn.chromium.org/blink/trunk@176640 bbb929c8-8fbe-4397-9dbb-9b2b20218538
DevTools: Remove worker's targets on corresponding events

BUG=

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

git-svn-id: svn://svn.chromium.org/blink/trunk@176641 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Always preload all tokens before parsing

If Android WebView tests break from this change,
please disable those tests: crbug.com/387101

This change is in preparation for re-writing the path
through which tokens are handled on the main thread
to allow them to be batched and deferred until more
important work is done:
https://codereview.chromium.org/258013009/

Currently the threaded parser uses the main thread's
MessageQueue as its work-queue and we'll commonly
queue 10 chunks of work in the main thread MessageQueue
even if the first chunk takes a long time we'll still have to
process the next 9 before we can do more important things
like put up a frame because we don't have a separate
queue for parser work.  258013009 will fix that.

http/tests/security/script-crossorigin-loads-correctly-credentials-2.html
originally started failing with this change and it
turns out that always-preloading found a real bug
in CORS handling with preloads. The ResourceFetcher
was incorrectly always reusing an in-flight preload
request, even if the CORS state didn't match. Nate
helped me re-order the calls in requestResource to fix it.

This change also discovered 2 other bugs in the preloader.
1. a preload request != LinkPrefect request
and one will cancel the other. crbug.com/379893
2. The preloader has no concept of script type and will
blindly issue preloads for all <script href> regardless
of <script type>.  I decided this didn't matter in practice.
Making the <script type> handling threadsafe isn't
worth the trouble.

I would anticipate that this change might make some
speed-index scores better (we'll now be preloading
all tokens slightly sooner, especially those
which are in the same chunk as a long inline
script block for instance), but may make non-network
PLT scores lower (due to extra mallocs required
to process every chunk since more loads will
be preloaded just before their actually loaded).

BUG=356292

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

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

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