Don't use 'using namespace std' in the header.

That's harmful.

The episode: I've wasted some time on debugging FocusController.cpp, which includes SpatialNavigation.h.
I couldn't notice that std::next() was unexpectedly used instead of NodeTraversal::next().

BUG=None

Review URL: https://chromiumcodereview.appspot.com/23313004

git-svn-id: svn://svn.chromium.org/blink/trunk@156532 bbb929c8-8fbe-4397-9dbb-9b2b20218538
WebCrypto: Add exception messages for algorithm normalization failures.

----------
Overview
----------

There are many problems that can occur during algorithm normalization, and they all have the same exception type (TypeError).

Without a good exception description, it is difficult for users of the API to know what went wrong (I have been experiencing this very problem while writing layout tests)

This change additionally enforces the range on numeric parameters (i.e. [EnforceRange]), which was previously a FIXME. This behavior isn't part of the WebCrypto spec yet, however it will be in a future update (https://www.w3.org/Bugs/Public/show_bug.cgi?id=23017).

----------
Examples
----------

Here are some examples of the new exception messages:

(1) "Algorithm: AES-CBC: AesCbcParams: iv: Missing or not a ArrayBufferView"

(Meaning: Didn't specify the iv parameter for AES-CBC. Users can see what is expected by looking at the "AesCbcParams" dictionary in the specification)

(2) "Algorithm: HMAC: HmacParams: hash: Missing or not a dictionary."

(Meaning: Didn't specify the hash attribute for an HMAC Algorithm. Users can see what is expected by looking at the HmacParams dictionary in the specification)

(3) "Algorithm: HMAC: HmacParams: hash: Algorithm: name: Missing or not a string."

(Meaning: Didn't specify "hash.name" for an HMAC Algorithm)

(4) "Algorithm: HMAC: HmacParams: hash: Algorithm: Unrecognized algorithm name."

(Meaning: specified hash.name, however it didn't identify a registered algorithm).

(5) "Algorithm: HMAC: HmacParams: hash: Algorithm: AES-CBC: Unsupported operation."

(Meaning: the "hash" specified for HMAC was AES-CBC, which is NOT a valid digest. This error message would be better if it said: "Does not support digest". I will re-visit that in a follow-up CL, since it requires some extra work)

----------
Implementation
----------

The implementation works by keeping a stack of string literals which describe the context of the error. A stack works better than an individual string, since algorithm identifiers can be nested and property names alone are ambiguous.

There is very little overhead to keeping track of the context while parsing algorithm identifiers, since string literals are cheap to push into a stack (no extra allocations). A final string is constructed only on failure by joining all the literals in the stack with ": ".

BUG=245025
R=abarth@chromium.org

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

git-svn-id: svn://svn.chromium.org/blink/trunk@156533 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Node::lazyAttach should not synchronously attach inside recalcStyle

There was a hack in Node::lazyAttach for <object> since the loader
callback can happen inside ::attach which triggers a reattach to show
the fallback content, but this breaks InsertionPoint::detach calling
lazyReattach since now we'll call attach() for each distributed node
inside the detach of the insertion point (and its ancestor) which means
the nodes are reattached as if their parent was display: none.

To fix this we move the hack for <object> to HTMLObjectElement and make
lazyAttach never synchronously attach.

BUG=277160

Review URL: https://chromiumcodereview.appspot.com/22790006

git-svn-id: svn://svn.chromium.org/blink/trunk@156534 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Add support for the object-fit CSS property.

This is hidden behind an "experimental" runtime flag named
"ObjectFitPosition". Once object-fit's "sister" property, object-position,
is implemented, the plan is to also put that behind this flag, too.

This is an implementation of object-fit as described in
http://www.w3.org/TR/2012/CR-css3-images-20120417/#object-fit

Object-fit is used to maintain the aspect ratio of replaced content
within its content box. All object-fit values except the initial one
('fill') will always ensure that the aspect ratio is retained, in
different ways (fit inside the content box, cover the content box, or
use intrinsic size). Painting is always clipped against the content
box, regardless of the 'overflow' property.

Video elements used to behave like 'object-fit:contain', while the
initial value is, as mentioned above, 'fill'. Therefore we need a
section for video in the UA style sheet.

Introducing RenderImageResource::intrinsicSize(). We cannot use
imageSize(), since it may return the extrinsic size for SVG images.

Parts of this patch (both code and layout tests) are based on work
originally done by Simon Fraser <simon.fraser@apple.com>.
See https://bugs.webkit.org/show_bug.cgi?id=52040

BUG=236331
R=pdr@chromium.org

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

Patch from Morten Stenshorne <mstensho@opera.com>.

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