Wasm-bindgen: Add console support to web-sys

Created on 10 Jul 2018  路  13Comments  路  Source: rustwasm/wasm-bindgen

This is a tracking issue for adding support for the console API to the web-sys crate.

General info on the console API: https://developer.mozilla.org/en-US/docs/Web/API/Console

How to add support for new Web APIs to web-sys: https://rustwasm.github.io/wasm-bindgen/web-sys/supporting-more-web-apis.html

Interfaces

Here is a list of interfaces we need to support:

  • [ ] Console

Example

  • [ ] Modify the existing console logging example in examples/ to use web-sys
help wanted web-sys

Most helpful comment

Two thoughts:

  1. This particular constant is ChromeOnly, so I think we can safely comment it out and get on with our lives.

  2. Might be worth filing that issue upstream with both the webidl crate and the spec anyways.

All 13 comments

Building web-sys after moving the Console webidl file to enabled results in the following console output. I wasn't able to figure out if its an error in the file or the parser or the web-sys crate.

--- stdout
cargo:rerun-if-changed=build.rs
cargo:rerun-if-changed=webidls/enabled
cargo:rerun-if-changed=webidls/enabled/StorageType.webidl
cargo:rerun-if-changed=webidls/enabled/DOMHighResTimeStamp.webidl
cargo:rerun-if-changed=webidls/enabled/Console.webidl
cargo:rerun-if-changed=webidls/enabled/Response.webidl
cargo:rerun-if-changed=webidls/enabled/Event.webidl

--- stderr
Error: compiling WebIDL into wasm-bindgen bindings
  caused by parsing WebIDL source text
  caused by Unrecognized token `Const` found at 2861:2866
Expected one of "(", "ArrayBuffer", "ByteString", "DOMString", "DataView", "Error", "Float32Array", "Float64Array", "FrozenArray", "Identifier", "Int16Array", "Int32Array", "Int8Array", "Promise", "USVString", "Uint16Array", "Uint32Array", "Uint8Array", "Uint8ClampedArray", "any", "boolean", "byte", "double", "float", "long", "object", "octet", "readonly", "record", "sequence", "short", "symbol", "unrestricted", "unsigned" or "void"

@jannikkeye, can you minimize the test case and file a bug upstream?

I'm not entirely sure since I'm rather new to webidl but it seems that const can only appear in an interface: https://heycam.github.io/webidl/#idl-constants

But in console.webidl it appears inside the namespace console: https://github.com/rustwasm/wasm-bindgen/blob/3578a83fe2a4c2ad9be8bfaa26258a8a646e05ab/crates/web-sys/webidls/available/Console.webidl#L14-L76

In case I'm wrong, here's a minimal example to reproduce the issue with webidl-rs:

[Exposed=(Window)]
namespace console {
    const boolean IS_NATIVE_CONSOLE = true;
};

Two thoughts:

  1. This particular constant is ChromeOnly, so I think we can safely comment it out and get on with our lives.

  2. Might be worth filing that issue upstream with both the webidl crate and the spec anyways.

If you comment out the incorrect const, then it builds, but you still don't have access to console functions because they are defined like this:

[Exposed=(Window,Worker,WorkerDebugger,Worklet,System),
 ClassString="Console",
 ProtoObjectHack]
namespace console {
// ...

which I'm guessing means "these are exposed on the (window/worker/...) prototype as console, which has class name Console.

So should web-sys be something like

#[wasm_bindgen]
extern "C" {
    #[wasm_bindgen(js_namespace = console)]
    fn log(s: &str); // not the correct type
}

and then, how do you stop name collisions from functions with the same name in different namespaces? Should web-sys generate modules to match namespaces?

@derekdreery That's basically what is suggested in #253. I think getting webidl namespace support first would be very helpful to get the Console.webidl up and running properly.

Thanks for linking the issue :)

Brain dump:
Rather than being like arbitrarily nested rust modules, a WebIDL namespace is like a global singleton object with methods. So console is like someone has done var console = new Console() at the beginning of each page. So we can still use modules from rust, but we should note the semantic differences.

Now that #678 has landed, what's left to do for this issue?

@eminence If I'm not completely mistaken, generating variadic functions like log and warn are not yet supported. See also #503.

@migerh @eminence I'm work towards adding variadic support in #726. After that lands, I'll modify the webidl frontend to emit variadic functions (where the last arg is a slice/vec). There's also variadic the other way, as in passing a rust callback that is called variadically by javascript. I think we need this to support some callbacks, e.g. for events.

Was this page helpful?
0 / 5 - 0 ratings