Use available width for replaced element with intrinsic ratio but no dimensions

Prior to this patch, we walked up the ancestor chain to find a
specified width for replaced content with intrinsic ratio but no
intrinsic size nor any specified dimensions.

This is clearly wrong when the containing block has no specified width
but an implicitly set width through the constraint equation. In that
case we would walk past the containing block and possible find an
ancestor with specified width to size against.

An other illustration of why it's wrong in the context of a stf
container where we would possibly go outside the stf container to
fetch a width.

Both scenarios illustrated by tests.

After this patch, we instead always use the available width of the
container, to properly size inside a container with no specified size.

http://www.w3.org/TR/CSS2/visudet.html#inline-replaced-width

BUG=387705

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

git-svn-id: svn://svn.chromium.org/blink/trunk@176929 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Use IDL argument default values in modules/indexeddb/

Replace bogus 'null' default values for DOMString arguments with the
actual default values from the spec, and remove the handling of null
strings in the C++ implementation.

Also replace [Default=Undefined] on some boolean arguments with the
default value 'false' from the spec, which has the same effect.

BUG=258153

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

git-svn-id: svn://svn.chromium.org/blink/trunk@176930 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Rename Blink to blink in Trace Events.

We currently have some trace events name 'Blink' and some named 'blink'. This
CL renames all of the 'Blink' trace events to be 'blink' for consistency.

This makes the chrome://tracing UI less confusing as you no longer have to
realize there are both 'Blink' and 'blink' categories to be enabled.

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

git-svn-id: svn://svn.chromium.org/blink/trunk@176931 bbb929c8-8fbe-4397-9dbb-9b2b20218538
IDL: Fix handling of nullable NodeFilter / XPathNSResolver arguments

Arguments of NodeFilter and XPathNSResolver have a special case that adds
a ".release()" suffix to the argument expression. This special case didn't
trigger if the argument was nullable.

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

git-svn-id: svn://svn.chromium.org/blink/trunk@176933 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Use IDL argument default values in modules/encoding/

Replace bogus 'null' default values for DOMString/ScalarValueString
arguments with the actual default values from the spec, and remove the
handling of null strings in the C++ implementation.

BUG=258153

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

git-svn-id: svn://svn.chromium.org/blink/trunk@176934 bbb929c8-8fbe-4397-9dbb-9b2b20218538
DevTools: [CodeMirror] roll codemirror presubmit instructions

This patch adds link to CodeMirror roll instructions in the
error message of CodeMirror presubmit check.

R=apavlov, pfeldman

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

git-svn-id: svn://svn.chromium.org/blink/trunk@176935 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Handle multiple fragments in the getCharNumberAtPosition SVGTextQuery

The start position (and thus indirectly end position) used to compute the
extents of a glyph to check against the point is computed based on the
'processedCharacter' query data state. Said state is only updated after
each text box has been processed, meaning that for a text box with
multiple fragments, the offset of the fragment within the box needs to be
included to get the correct start/end position.

BUG=387725

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

git-svn-id: svn://svn.chromium.org/blink/trunk@176936 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Optimize SVGTextQuery's character offset ligature adjustment query

For queries that take a code unit to compute some property for (basically
all *OfChar calls), the <start, end> range is mapped to the closest
glyph-boundary to allow queries within ligatures.
This adjustment step is O(N), N=number of glyphs within a text node, and
is performed for each fragment within a text box.
This means that for text boxes with a large number of fragments - and,
consequently, a large number of glyphs - there'll be O(N^2) behavior.
Since the <start, end> range is invariant for most queries, it should
suffice to compute the adjusted range once per text node [1].
The easiest way to achieve this is by adding a simple cache and reuse the
result of an adjustment query (for every fragment in a text box.)

This improves the runtime of the test in the bug from ~13s to ~120ms (or
approximately a factor 100) locally.

[1] This CL however only perform caching per text box in order to minimize
modifications to the actual adjustment code.

BUG=267504

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

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