• jchaffraix@chromium.org's avatar
    Revert of Always preload all tokens before parsing (https://codereview.chromium.org/302063002/) · 502e53ef
    jchaffraix@chromium.org authored
    Reason for revert:
    This change breaks:
    org.chromium.android_webview.test.AwSettingsTest#testBlockNetworkImagesDoesNotBlockDataUrlImage
    
    Probably because it pre-loads images when "automatically load images" is disabled on Android.
    
    See
    http://build.chromium.org/p/tryserver.chromium/builders/android_dbg_triggered_tests/builds/159696/steps/androidwebview_instrumentation_tests/logs/stdio
    
    Original issue's description:
    > Always preload all tokens before parsing
    > 
    > This change is in preparation for re-writing the path
    > through which tokens are handled on the main thread
    > to allow them to be batched and deferred until more
    > important work is done:
    > https://codereview.chromium.org/258013009/
    > 
    > Currently the threaded parser uses the main thread's
    > MessageQueue as its work-queue and we'll commonly
    > queue 10 chunks of work in the main thread MessageQueue
    > even if the first chunk takes a long time we'll still have to
    > process the next 9 before we can do more important things
    > like put up a frame because we don't have a separate
    > queue for parser work.  258013009 will fix that.
    > 
    > http/tests/security/script-crossorigin-loads-correctly-credentials-2.html
    > originally started failing with this change and it
    > turns out that always-preloading found a real bug
    > in CORS handling with preloads. The ResourceFetcher
    > was incorrectly always reusing an in-flight preload
    > request, even if the CORS state didn't match. Nate
    > helped me re-order the calls in requestResource to fix it.
    > 
    > This change also discovered 2 other bugs in the preloader.
    > 1. a preload request != LinkPrefect request
    > and one will cancel the other. crbug.com/379893
    > 2. The preloader has no concept of script type and will
    > blindly issue preloads for all <script href> regardless
    > of <script type>.  I decided this didn't matter in practice.
    > Making the <script type> handling threadsafe isn't
    > worth the trouble.
    > 
    > I would anticipate that this change might make some
    > speed-index scores better (we'll now be preloading
    > all tokens slightly sooner, especially those
    > which are in the same chunk as a long inline
    > script block for instance), but may make non-network
    > PLT scores lower (due to extra mallocs required
    > to process every chunk since more loads will
    > be preloaded just before their actually loaded).
    > 
    > BUG=356292
    > 
    > Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=175427
    
    TBR=tonyg@chromium.org,japhet@chromium.org,eseidel@chromium.org
    NOTREECHECKS=true
    NOTRY=true
    BUG=356292
    
    Review URL: https://codereview.chromium.org/317703005
    
    git-svn-id: svn://svn.chromium.org/blink/trunk@175512 bbb929c8-8fbe-4397-9dbb-9b2b20218538
    502e53ef
link-and-subresource-test.html 1.09 KB