LeakExpectations: add more worker tests

BUG=364390
NOTRY=true
TBR=hajimehoshi

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178634 bbb929c8-8fbe-4397-9dbb-9b2b20218538
DevTools: Introduce binding entities for the CSS and debugger domains

Introduced are CSSPresentationModel and DebuggerPresentationModel,
intended to ultimately remove all sdk-workspace bindings from
purely sdk entities. This patch solely migrates the clients
to the new API, leaving the behavior largely intact.

R=vsevik@chromium.org, vsevik

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178636 bbb929c8-8fbe-4397-9dbb-9b2b20218538
DevTools: Make heap_snapshot_worker a top-level module

This makes all module directories consistently rooted at "front_end/".
TextUtils.js is also moved into "common", since it has nothing to do with "ui".

R=vsevik@chromium.org, pfeldman, vsevik

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178637 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Mark 63 inspector/ tests as flaky on Linux ASAN

(and clean up old expectations for these tests)

BUG=395997,395676
TBR=sergeyv@chromium.org
NOTRY=true
NOTREECHECKS=true

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178638 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Rebaseline date format/calendar tests on Linux

With ICU 52 [1], some date format/month/week names have changed and
related tests need to be rebaselined on Linux. They're rebaselined
locally and updated results are checked in.

On Windows, the following tests need to be rebasedlined for a different
reason (see https://src.chromium.org/viewvc/blink?revision=176244 by
eae).

fast/forms/month/month-appearance-l10n.html
fast/forms/datetimelocal/datetimelocal-appearance-l10n.html

Mark them as such and label them with 'Bug(eae)'.

Mac OS also appears to need rebaseline for the above tests. Filed
http://crbug.com/395877 and added the entries for them.

[1] https://src.chromium.org/viewvc/chrome?view=rev&revision=277111

BUG=378919
TEST=layout tests changed pass on Linux/Android.
R=eae@chromium.org
TBR=eae, tkent

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

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

This change unifies instant event phase name between Chromium and Blink. Now it is 'I' in both projects.

BUG=None
R=loislo@chromium.org, pfeldman@chromium.org

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178641 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Introduce DEFINE_ELEMENT_DATA_TYPE_CASTS, and use it

As a step to use toFoo, this cl introduces DEFINE_ELEMENT_DATA_TYPE_CASTS, which generates
toUniqueElementData() and toShareableElementData(). Those functions will detect bad type cast.

BUG=309516

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178643 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Scheduler: Don't shut down the scheduler too soon

We shouldn't terminate the scheduler before ensuring background
threads such as the HTML parser have been stopped. This is
because those threads may schedule new work, leading to a crash
as we're trying to post tasks into a non-existing scheduler.

This patch moves the call to tear down the scheduler right
before terminating blink's Platform abstraction and right after
terminating WTF, as WTF also has a dependency on the scheduler
(callOnMain).

BUG=395420

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178644 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Ship the File constructor.

BUG=394971

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178645 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Have LocalDOMWindow own a set of PostMessageTimer

Now PostMessageTimer in LocalDOMWindow is not owned by anyone and
destroyed only when the timer is fired. It means that if the timer isn't
fired, the timer is not destroyed forever.

This CL fixes this bug by having LocalDOMWindow own generated
PostMessageTimers and all generated timers will be destoryed at the
latest when the LocalDOMWindow is destoryed.

Now LocalDOMWindow refers the window, which causes a circular reference.
This CL also fixes this.

BUG=395010

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178646 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Oilpan: move 2D Canvas and WebGL objects to the heap.

This adds Oilpan transition types to the WebGL object hierarchy, along
with some remaining Canvas 2D objects. 

Notes:

- Oilpan does not allow destructors to access other garbage collected
  objects and we want all WebGL script accessible objects to be under
  the control of Oilpan and be garbage collected. To follow and
  fulfill both, we cannot make the objects that the destructors depend
  on for fetching out the graphics context (which they use to finalize
  their platform resources) be garbage collected. For
  WebGLSharedObjects (and WebGLRenderingContextBase) that means that
  WebGLContextGroup cannot be on the heap/garbage-collected, and for
  WebGLContextObjects, the WebGLRenderingContextBase's DrawingBuffer
  cannot be on the heap either.
  
  See details below for how this is done for WebGLContextObject's; the
  changes to WebGLContextGroup and WebGLSharedObject is along similar
  lines.
  
- In terms of file footprint of the changes here, the WebGLExtension-derived
  objects make up a significant portion. Their switch in transition
  types for their create() constructor method is all standard and
  repetitive.

- The release of platform resources when finalizing WebGL objects
  requires some extra care with Oilpan. That release is done using a
  platform graphics context object (blink::WebGraphicsContext3D), which
  is owned by a DrawingBuffer. As finalization order isn't deterministic
  with Oilpan, we have to arrange for that DrawingBuffer's context
  object to remain alive until all objects that need it for platform
  resource release have been finalized. And we cannot rely on fetching
  the context object from another WebGL object on the Oilpan heap, as it
  may or may not have been finalized.

  To address, the (off heap) DrawingBuffer is shared among all objects 
  that need it for finalization, using an off-heap RefCounted abstraction 
  (WebGLSharedWebGraphicsContext3D). When all objects have been finalized, 
  that shared object will be destructed and its underlying DrawingBuffer 
  (and, indirectly, its blink::WebGraphicsContext3D object) is let go of. 

  As a result, each WebGLContextObject adds a RefPtr<> to this shared 
  DrawingBuffer/WebGraphicsContext3D with Oilpan enabled. 

R=haraken@chromium.org,ager@chromium.org,junov@chromium.org,bajones@chromium.org,kbr@chromium.org
BUG=340522

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178647 bbb929c8-8fbe-4397-9dbb-9b2b20218538
[oilpan]: Remove support for tracing off-heap hashmaps.

With this change we can no longer trace off-heap hashmaps. To make this work I changed the ExecutionContext to be WillBeHeapSupplementable and moved the IDBPendingTransactionMonitor to the heap. Finally I changed the way we trace through supplementables. Specifically we only trace our supplements for HeapSupplementable and PersistentHeapSupplementable.

R=ager@chromium.org, erik.corry@gmail.com, haraken@chromium.org, oilpan-reviews@chromium.org, tkent@chromium.org, vegorov@chromium.org, zerny@chromium.org, sigbjornf@opera.com
BUG=

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178648 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Fix bugs in clip parent calculations

I noticed two bugs in the clip parent code - when walking up the layers
in the stacking tree looking for clipping layers, I'd forgotten to
consider the layers themselves (I'd only considered their clipping
containers). I'd also incorrectly gated promotion for having a clip
parent on having an ancestor scrolling layer that needed composited
scrolling. This condition was bogus: we often need a clip parent
precisely because we have no ancestor scrolling layer (eg, we're fixed
positioned and have 'escaped' our ancestor scrollers in tree order).

BUG=None

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178649 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Oilpan: fix compilation after r178648.

R=haraken@chromium.org
BUG=
NOTRY=true
NOTREECHECKS=true

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178651 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Ship image-rendering: pixelated to stable.

This also adds the value to DevTools.

Intent to Ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zSasd2LL8Mc

BUG=317991,106662,260739,134040

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178653 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Oilpan: WebAudio: Reduce RefPtr and raw pointers to AudioNode.

- Replace Vector<PannerNode*> in AudioListener with
  WillBeHeapVector<RawPtrWillBeMember<PannerNode>>.

- Replace RefPtr<MediaElementAudioSourceNode> in MediaElementAudioSourceNode
  with RefPtrWillBePersistent<MediaElementAudioSourceNode>.

- Replace RefPtr<OfflineAudioDestinationNode> in OfflineAudioDestinationNode
  with RefPtrWillBePersistent<OfflineAudioDestinationNode>

These pointers are not connection-references. We can safely replace
them to Oilpan types.

BUG=395940,395941

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178654 bbb929c8-8fbe-4397-9dbb-9b2b20218538
DevTools: refine DataGrid member types.

BUG=

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178655 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Clarify font-weight parsing for 100-900 keywords

The current parsing for font-weight is slightly confusing as it has
branches for keywords 100 to 900 to be parsed as keywords (CSSValueID)
or numbers. These won't get parsed as keywords so we don't need to have
CSSValue100 to CSSValue900 in the range we check.

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178656 bbb929c8-8fbe-4397-9dbb-9b2b20218538
DevTools: Serialize debugger model interactions on TargetBreakpoint

NOTRY=true

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

git-svn-id: svn://svn.chromium.org/blink/trunk@178657 bbb929c8-8fbe-4397-9dbb-9b2b20218538
DevTools: Do not skip appending arguments in ScriptFunctionCall.

We should not skip appending arguments, as it may shift arguments order.
Instead append "undefined".

R=yurys

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

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