Bug 1827953 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
Bug 1826681 implemented an MVP for communicating WebGPU shader compilation messages emitted by [`GPUDevice.createShaderModule`] to the user via the tab's JS console. However, there are some things about this experience that we'd like to take some additional time to refine, in order to achieve a _joyful_ experience, instead of merely a functional one. We'd like to make more bugs based on research in this bug. The current (non-exhaustive) list of things we've thought about so far:

1. JS-native `console` logging uses the call stack of currently running JS, but our current native usage of the [`Console` API] [`GPUDevice.createShaderModule`] doesn't emit this. This can be observed by viewing an attachment called `desired-behavior-3-aggregated-callout.html` in bug 1826681.

    We should see if we can preserve the calling context of `createShaderModule` for presentation when presenting shader compilation messages.
1. Should we add a way in the WebGPU API (implementation-specific? prefs?) to control whether the current console groups should be expanded by default? This would let users remove a debugging step when they are constantly tweaking shaders and refreshing.
1. How can we leverage source maps when the user provides a [`GPUShaderModuleDescriptor.sourceMap`](https://www.w3.org/TR/webgpu/#dom-gpushadermoduledescriptor-sourcemap) to better contextualize diagnostics? See also bug 1827947. 
1. Should we tweak the format of messages specifically for presentation in the JS console? It's possible that we will be able to provide a superior experience in general, i.e., by printing source links to view the `createShaderModule` code in console. See also 1827947.

[`GPUDevice.createShaderModule`]: https://developer.mozilla.org/en-US/docs/Web/API/GPUDevice/createShaderModule

[`Console` API]: https://searchfox.org/mozilla-central/rev/ad732108b073742d7324f998c085f459674a6846/dom/console/Console.h
Revision 1 by
on 
Bug 1826681 implemented an MVP for communicating WebGPU shader compilation messages emitted by [`GPUDevice.createShaderModule`] to the user via the tab's JS console. However, there are some things about this experience that we'd like to take some additional time to refine, in order to achieve a _joyful_ experience, instead of merely a functional one. We'd like to make more bugs based on research in this bug. The current (non-exhaustive) list of things we've thought about so far:

1. JS-native `console` logging uses the call stack of currently running JS, but our current native usage of the [`Console` API] [`GPUDevice.createShaderModule`] doesn't emit this. This can be observed by viewing an attachment called `desired-behavior-3-aggregated-callout.html` in bug 1826681.

    We should see if we can preserve the calling context of `createShaderModule` for presentation when presenting shader compilation messages.
1. Should we add a way in the WebGPU API (implementation-specific? prefs?) to control whether the current console groups should be expanded by default? This would let users remove a debugging step when they are constantly tweaking shaders and refreshing.
1. How can we leverage source maps when the user provides a [`GPUShaderModuleDescriptor.sourceMap`](https://www.w3.org/TR/webgpu/#dom-gpushadermoduledescriptor-sourcemap) to better contextualize diagnostics? See also bug 1827947. 
1. Should we tweak the format of messages specifically for presentation in the JS console? It's possible that we will be able to provide a superior experience in general, i.e., by printing source links to view the `createShaderModule` code in console. See also bug 1827947.

[`GPUDevice.createShaderModule`]: https://developer.mozilla.org/en-US/docs/Web/API/GPUDevice/createShaderModule

[`Console` API]: https://searchfox.org/mozilla-central/rev/ad732108b073742d7324f998c085f459674a6846/dom/console/Console.h
Revision 2 by
on 
Bug 1826681 implemented an MVP for communicating WebGPU shader compilation messages emitted by [`GPUDevice.createShaderModule`] to the user via the tab's JS console. However, there are some things about this experience that we'd like to take some additional time to refine, in order to achieve a _joyful_ experience, instead of merely a functional one. We'd like to make more bugs based on research in this bug. The current (non-exhaustive) list of things we've thought about so far:

1. JS-native `console` logging uses the call stack of currently running JS, but our current native usage of the [`Console` API] [`GPUDevice.createShaderModule`] doesn't emit this. This can be observed by viewing the attachment called `desired-behavior-3-aggregated-callout.html` in bug 1826681 in Nightly.

    We should see if we can preserve the calling context of `createShaderModule` for presentation when presenting shader compilation messages.
1. Should we add a way in the WebGPU API (implementation-specific? prefs?) to control whether the current console groups should be expanded by default? This would let users remove a debugging step when they are constantly tweaking shaders and refreshing.
1. How can we leverage source maps when the user provides a [`GPUShaderModuleDescriptor.sourceMap`](https://www.w3.org/TR/webgpu/#dom-gpushadermoduledescriptor-sourcemap) to better contextualize diagnostics? See also bug 1827947. 
1. Should we tweak the format of messages specifically for presentation in the JS console? It's possible that we will be able to provide a superior experience in general, i.e., by printing source links to view the `createShaderModule` code in console. See also bug 1827947.

[`GPUDevice.createShaderModule`]: https://developer.mozilla.org/en-US/docs/Web/API/GPUDevice/createShaderModule

[`Console` API]: https://searchfox.org/mozilla-central/rev/ad732108b073742d7324f998c085f459674a6846/dom/console/Console.h
Revision 3 by
on 
Bug 1826681 implemented an MVP for communicating WebGPU shader compilation messages emitted by [`GPUDevice.createShaderModule`] to the user via the tab's JS console. However, there are some things about this experience that we'd like to take some additional time to refine, in order to achieve a _joyful_ experience, instead of merely a functional one. We'd like to make more bugs based on research in this bug.

Bugs blocking this one are part of the scope of this issue. The current (non-exhaustive) list of things we've thought about so far, but haven't broken out into separate bugs yet:

1. Should we add a way in the WebGPU API (implementation-specific? prefs?) to control whether the current console groups should be expanded by default? This would let users remove a debugging step when they are constantly tweaking shaders and refreshing.
1. How can we leverage source maps when the user provides a [`GPUShaderModuleDescriptor.sourceMap`](https://www.w3.org/TR/webgpu/#dom-gpushadermoduledescriptor-sourcemap) to better contextualize diagnostics? See also bug 1827947. 
1. Should we tweak the format of messages specifically for presentation in the JS console? It's possible that we will be able to provide a superior experience in general, i.e., by printing source links to view the `createShaderModule` code in console. See also bug 1827947.

[`GPUDevice.createShaderModule`]: https://developer.mozilla.org/en-US/docs/Web/API/GPUDevice/createShaderModule

[`Console` API]: https://searchfox.org/mozilla-central/rev/ad732108b073742d7324f998c085f459674a6846/dom/console/Console.h

Back to Bug 1827953 Comment 0