New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 658558 link

Starred by 18 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Aug 2017
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Support top-level await in DevTools console/REPL

Reported by, Oct 22 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36

Steps to reproduce the problem:
1. Open DevTools
2. Run some code that uses await at the top-level

What is the expected behavior?
It would be nice (this is a feature request) if the existing wrapper function in which REPL code runs were an async function. This would still allow return usage as DevTools does today, but also enable the usage of async/await without a wrapper function and promise management.

Twitter discussion:

What went wrong?
An exception is thrown because the REPL does not evaluate input in an async function. In the attached screenshot, the first console input throws an Error, but it would be awesome to support that use-case.  We deal with so much asynchronicity on the web, it seems like a REPL should cater to it.

Did this work before? N/A 

Chrome version: 54.0.2840.59  Channel: stable
OS Version: OS X 10.10.5
Flash Version: Shockwave Flash 23.0 r0
Screen Shot 2016-10-20 at 11.15.56 PM.png
96.1 KB View Download

Comment 1 by, Oct 22 2016

Working example code:

    (async () => `Homepage: ${(await fetch(location.href)).status}`)().then(console.log)

Ideal example code:

    `Homepage: ${(await fetch(location.href)).status}`

Screen Shot 2016-10-22 at 7.45.25 PM.png
69.7 KB View Download
async functions will be shipped in Chrome 55.

Comment 3 by, Oct 23 2016

I'm using Canary - you can see they are clearly supported in the screenshot, just not at the top-level.
await expressions must be in an async function, they cannot appear at the top-level by themselves.

Components: Platform>DevTools>JavaScript
Labels: -Pri-2 -OS-Mac OS-All Pri-1
Status: Assigned (was: Unconfirmed)
Aleksey, can we do something useful here?

Comment 6 by, Oct 24 2016

Not sure if I'm way off track here: as far as I know, code entered via the console is already evaluated within a function. I'm simply suggesting that be made an async function. The semantics of global await don't really apply within a REPL since it's not trying to faithfully replicate a global execution context.
Labels: -Pri-1 Pri-2
We don't wrap expression in console with function or with any other synthetic blocks - just run code as is. You can think about every new command in console as <script>.. command ..</script> added to page.
JavaScript in future will probably use top level await for modules or something else and there is no plans to support top level await in spec [1].
I'm worried that by allowing await in console we can teach users to use await in this manner in script body for example.
In general I'd like to avoid any big difference between result of executing code in console and in global scope with <script> tag.


Comment 8 by, Dec 1 2016

Sorry for asking, but do you have a reference to the (devtools?) source
where I can see how the REPL evaluates input?  It seems strange it can
support things like $0 and $() despite that being only available in
Feel free to ask any questions! I'm happy to answer.

We pass string to DevTools backend which is located in V8 [1]. Here we compile and evaluate this string as regular script. Right before evaluation of string on global object we install our command line API ($0, dir(), ...) [2]. It is installed with using of native V8 API [3]. Right after evaluation we removes installed command line api methods.

One year ago we used synthetic with block: "with(commandLineAPI) { evaluate(expression); }". We migrated to another way of injecting command line api to make possible using of some ES6 features in our console like let, const, classes (they don't work inside of with block).

Ahh, perfect. I didn't realize it was able to inject those via the V8 API.
Labels: -Pri-2 Pri-3
Labels: -Type-Bug Type-Feature
 Issue 673441  has been merged into this issue.
Issue 675967 has been merged into this issue.

Comment 15 by, Mar 3 2017

> I'm worried that by allowing await in console we can teach users to use await in this manner in script body for example.
> In general I'd like to avoid any big difference between result of executing code in console and in global scope with <script> tag.

I wonder if there is some way to allow for top-level await to support easy debugging of async code without leading developers into bad habits?  Perhaps a checkbox or setting that enables it but is disabled by default?

As a workaround for this, developers can create a function that wraps up the async code:
var wrapper = async (awaitable) => { var result = await awaitable(); console.log(result); }

wrapper(() => fetch(location.href));

Unfortunately, this is only marginally better than the original proposed workaround and requires that function be added at some point.

Comment 16 by, May 23 2017

Just an update - Safari allows top-level await in their console:
46.9 KB View Download
19.4 KB View Download
They support it only for single expression. If you start typing something like
var r = await fetch(...);
var json = await r.json();

or like:
console.log(await fetch());

As far as I know it doesn't work. I think we prefer to have full await support or don't have it at all.
Node seems interested in supporting this as well:

Comment 19 by, May 31 2017

 Issue 727924  has been merged into this issue.

Comment 20 by, May 31 2017

> I think we prefer to have full await support or don't have it at all.

Latter please. Also notice

Comment 21 by, Jun 28 2017

 Issue 733619  has been merged into this issue.

Comment 22 by, Jul 20 2017

You might have a look at the library I implemented in <>, which kind of takes comment 17 to the extreme and allows you to execute `await. a = fetch("/")` (instead of `a = await fetch("/")`) in the console.
Project Member

Comment 23 by, Aug 11 2017

The following revision refers to this bug:

commit e8111c396fef38da6654093433b4be93bed01dce
Author: Alexey Kozyatinskiy <>
Date: Fri Aug 11 00:28:29 2017

[DevTools] support top-level await in console

If expression could be successfully compiled without preprocessing -
we do nothing.
Otherwise if function contains await expression:
  - if variable is var or variable is top-level we remove variable kind
    to make it available in global scope.
  - function definitions: function foo() {} -> foo = function foo() {}
  - top-level class definitions: class Foo {} -> Foo = class Foo {},

Bug:  chromium:658558 
Change-Id: I8e9d26b93c3e53a966e43ec9c72b931a45c1a294
Commit-Queue: Aleksey Kozyatinskiy <>
Reviewed-by: Andrey Lushnikov <>
Cr-Commit-Position: refs/heads/master@{#493612}

Status: Fixed (was: Assigned)

Comment 25 Deleted

Comment 26 by, Aug 28 2017

Labels: DevTools-Release-Notes-62

Sign in to add a comment