GitLab

Some tracing with performance.now() suggests this will shave about 300ms
off the critical path for loading a file.

We would previously wait for the window 'load' event which indicated
that the <iframe> subresource (and all *its* subresources) had fully
loaded. This was "safe" but too conservative. There's a tip in the spec:
https://html.spec.whatwg.org/multipage/web-messaging.html#posting-messages
which suggests to have the <iframe> send a message to its parent to
indicate that it's ready to process messages, which this CL does (saving
~100ms).

For the other ~200ms, the steps involved in handling the launch event to
open the file and determine related files are now allowed to run before
the iframe is ready to receive messages. Only the final postMessage that
triggers the load must wait for the iframe to be ready.

Sample trace for loading a file in a directory with 75 files after this
change that explains the "300ms" improve:

<privileged>
75~85 ms: JS starts (t=0 in privileged)
t+5ms: launch message received
t+80ms ms: waiting for iframe
t+200ms: iframe "ready" received
t+300ms: privileged 'load' event received <-- we used to start "launch" here.

<unprivileged>
75~85 ms: JS starts (t=0 in unprivileged)
t+50ms: iframe ready (app_main.js executed, app is still null)
t+180ms: load in iframe begins
t+570ms: load done [warm start]
t+1050ms: load done [cold start]

Covered by existing tests, which were hammered with some invocations of
  browser_tests --test-launcher-jobs=20 --gtest_filter='*MediaApp*' \
      --gtest_repeat=10
to flush out any flakes.

Bug: b/157949149
Change-Id: Ie1c3ca79bb9f7b5d323967ee653943ac7901afd5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2227716Reviewed-by: dstockwell <dstockwell@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#774904}