[webcrypto] Add layout test for generated AES keys.

BUG=245025

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

git-svn-id: svn://svn.chromium.org/blink/trunk@172425 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Revert of Make data: urls always parse async (https://codereview.chromium.org/210253003/)

Reason for revert:
Seems to have broken many browser_tests:
http://build.chromium.org/p/chromium.webkit/builders/Linux%20Tests%20%28dbg%29/builds/2364/steps/browser_tests/logs/stdio
http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chromeos_rel/builds/18723/steps/browser_tests%20%28with%20patch%29

Original issue's description:
> Make data: urls always parse async
> 
> Turns out Chrome has long had the behavior of issuing
> loads and delivering load events async for data: urls,
> but not actually doing the parsing async. This changes
> makes the parsing of data:text/html content always async.
> 
> NOTE: The new async test (loader/iframe-sync-loads.html)
> does not change before before/after this test, it's
> there to confirm that we were already behaving async
> with regards to when the content appeared in the iframe.
> 
> This finally makes it possible to take a JS string
> and run it through the HTML parser async.  I'll fix
> <iframe srcdoc> to also be async in a follow-up patch.
> 
> I wrote a test to check sync/async behavior of various
> loading methods for iframes. Gecko has async behavior
> for all 3 of these cases in my test, where as Chrome
> on Linux has sync behavior for javascript:
> 
> This is covered by 3 additional tests:
> fast/dom/document-contentType-data-uri.html:
> - text/html content is now async, matches FF
> 
> accessibility/loading-iframe-sends-notification.html
> - had to re-write this test to not assume that the iframe
> would be laid out before its onload was fired.
> 
> scrollingcoordinator/non-fast-scrollable-region-transformed-iframe.html
> - This was hitting crbug.com/365509 which I worked around by
> calling setUseMockScrollbars earlier.
> 
> BUG=308321, 365509
> 
> Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=172401

TBR=abarth@chromium.org,japhet@chromium.org,dmazzoni@chromium.org,eseidel@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=308321, 365509

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

git-svn-id: svn://svn.chromium.org/blink/trunk@172426 bbb929c8-8fbe-4397-9dbb-9b2b20218538
HTMLDetailsElement should fire a 'toggle' event

As per the specification, a 'toggle' event should be fired whenever the 'open'
attribute is added to or removed from a details element:
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#attr-details-open

Firefox 28 and IE11 do not support this yet.

R=arv@chromium.org, tkent@chromium.org
BUG=366105
TEST=fast/html/details-open-toggle-event.html

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

git-svn-id: svn://svn.chromium.org/blink/trunk@172427 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Seperate repaint and layout requirements of StyleDifference (Step 2)

Step 1 (https://codereview.chromium.org/236203020/) added a new
StyleDifference class to replace the original StyleDifference enum and
let callers use the new class.

Step 2 let RenderStyle directly generate the new StyleDifference.
Original implications between StyleDifference levels (e.g layout
implies repaint) are still kept, so Step 2 still doesn't change any
functionality.

Next steps will remove the implications and optimize repaints on
layout.

BUG=358460
TEST=All existing layout tests
R=jchaffraix@chromium.org

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

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