DescriptionMake 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.
browser_tests should have been fixed to expect this change
in https://codereview.chromium.org/257723002/
BUG=308321, 365509
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=172401
Patch Set 1 #Patch Set 2 : rebased #Patch Set 3 : Fix failing tests #
Total comments: 2
Patch Set 4 : Hacky fix for AX test #Patch Set 5 : Fix fast/events/drag-and-drop-autoscroll-inner-frame.html #Patch Set 6 : rebased #Messages
Total messages: 48 (0 generated)
|