Block execution of failed 'crossorigin' <script>s.

The HTML spec tells us that if a script element has a 'crossorigin'
attribute, a potentially CORS enabled fetch of its source URL must be
performed:

 http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#dfnReturnLink-39
 http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#potentially-cors-enabled-fetch

If the CORS cross-origin request status of that fetch is not a success
due to a failed CORS resource sharing check, the implementation must
act as if no script resource has been obtained.

No such CORS check was in place for parser inserted elements, allowing
a cross-origin CORS resource that either didn't permit the script
access or the resource wasn't CORS enabled, to load in the presence of
'crossorigin'.

Address this here by interposing a CORS check prior to starting script
execution. This (tries) to mirror how the operations are sequenced in
the underlying spec.

Specifically,

  ScriptLoader::executePotentiallyCrossOriginScript()

now performs the needed access check for fetched scripts _if_ the
fetch was initiated as potentially CORS-enabled. That is, if the
script was fetched from same-origin or the CORS check passes in the
cross-origin case, then script execution can go ahead. If not and a
cross-origin script, a console error message is added and an error
event is dispatched. Script execution does not go ahead.

To support the above, the ResourceFetcher::canAccess() predicate over
resources now needs to be informed if the resource fetch was initiated
in a potentially CORS enabled manner. If it was, the required CORS
resource sharing check will be performed.

By making the "CORS enabled" property of a fetch something that a
loader keeps separate from the (potentially cached) resource, we can
simplify the underlying structure a bit, removing the
RequestOriginPolicy portion from the resource options.

As a result, FetchRequest now instead keeps track of any origin
restrictions of the fetch resource + the canAccess() predicate must be
supplied with the "CORS enabled" setting to use when checking access
to the actual resource.

R=mkwst,abarth
BUG=286684

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

git-svn-id: svn://svn.chromium.org/blink/trunk@162417 bbb929c8-8fbe-4397-9dbb-9b2b20218538
[CSS Regions] Add performance test for selection

Patch already landed in WebKit. See http://trac.webkit.org/changeset/159488

Add new performance test for selection in CSS Regions. It checks a selection
from the first region to the last one, passing through all the regions.

Test is skipped for now while implementation of selection in CSS Regions is
still evolving.

BUG=319305

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

git-svn-id: svn://svn.chromium.org/blink/trunk@162418 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Reorder CustomElement creation code to come after normal element creation

esprehn saw this code lighting up a bit during profiling. I don't have a perf test that
shows meaningful differences on my workstation, but the new code should theoretically
make the most common case (of constructing built-in elements) slightly faster.

The only possible change in behavior here is if the embedder were to try and
override a built-in HTML element. This sounds unproblematic to me, but it's
possible we should codify this somewhere.

No test changes because It's not possible to test the behavioral change with a layout test,
since it's already impossible (by design) to override builtin elements with document.register().

R=dominicc@chromium.org, esprehn@chromium.org

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

git-svn-id: svn://svn.chromium.org/blink/trunk@162419 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Add include stdlib.h to files using malloc, free, etc but not including stdlib.

R=abarth@chromium.org, thakis@chromium.org, adamk@chromium.org
BUG=82098

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

Patch from Alexander Taran <alextaran@chromium.org>.

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