Commit 90914b5f authored by Johannes Henkel's avatar Johannes Henkel Committed by Commit Bot

[DevTools] Rework the console-worker.js test for flatten=true.

In my rework, I think there could be some race conditions
in the order of the output. I'll do the dry-run for now
and see whether anything manifests. Perhaps it's worth
doing some sorting of the logs, e.g. we could make the
test insensitive to the order of some of the events in
the golden file, by keeping two or three separate logging
streams for each section.

Bug: 991325
Change-Id: Ib9b8fb0732f5efbf9ad619ff12d5a36bccb02a16
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1762823
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Reviewed-by: default avatarAndrey Kosyakov <caseq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#690125}
parent 39753803
Tests how console messages from worker get into page's console once worker is destroyed.
=== console.log event won't get lost despite worker.terminate. ===
Starting worker
Logging in worker: message0
Got log message from page: message0
Stopping worker
-> Posting to worker: message0 (posted after starting worker)
<- Log from page: message0 (posted after starting worker)
Terminating worker
=== Scenario with autoattach enabled and stopped. ===
Starting worker
Logging in worker: message1
Got log message from page: message1
-> Posting to worker: message1
<- Log from page: message1
Starting autoattach
Worker.created
child session for worker created
Sending Runtime.enable to worker
Got console API call from worker: message1
Logging in worker: message2
Got console API call from worker: message2
Got log message from page: message2
Logging in worker: throw1
Got log message from page: Uncaught (in promise) throw1
-> Posting to worker: message2 (posted after runtime enabled)
<-- Console API from worker: message1
<-- Console API from worker: message2 (posted after runtime enabled)
<- Log from page: message2 (posted after runtime enabled)
-> Posting to worker: throw1 (posted after runtime enabled; yields exception in worker)
Stopping autoattach
Logging in worker: message3
Got log message from page: message3
Stopping worker
<- Log from page: Uncaught (in promise) throw1 (posted after runtime enabled; yields exception in worker)
-> Posting to worker: message3 (posted after auto-attach)
<- Log from page: message3 (posted after auto-attach)
Terminating worker
=== Scenario with autoattach from the get-go. ===
Starting autoattach
Starting worker
Worker.created
Logging in worker: message4
child session for worker created
-> Posting to worker: message4 (posted before worker's runtime agent enabled)
Sending Runtime.enable to worker
Got console API call from worker: message4
Got log message from page: message4
Logging in worker: message5
Got console API call from worker: message5
Got log message from page: message5
Stopping worker
-> Posting to worker: message5 (posted after worker's runtime agent enabled)
<- Log from page: message4 (posted before worker's runtime agent enabled)
<-- Console API from worker: message4 (posted before worker's runtime agent enabled)
<-- Console API from worker: message5 (posted after worker's runtime agent enabled)
<- Log from page: message5 (posted after worker's runtime agent enabled)
Terminating worker
=== New worker, with auto-attach still enabled. ===
Starting worker
Worker.created
Logging in worker: message6
Got log message from page: message6
Stopping worker
child session for worker created
-> Posting to worker: message6 (posted just before worker termination)
Terminating worker
<- Log from page: message6 (posted just before worker termination)
Stopping autoattach
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment