Created attachment 409686 [details] Test HTML page to reproduce the bug If one calls suspend() on an audio context before any node has been created, the call succeeds (and state right after is indeed "suspended") but the intent is ignored: the audio context still switches to "running" automatically when a first node gets created. This is counter-intuitive. Steps to Reproduce: Run the following code in response to some user gesture. See attached file for an HTML page that contains the test. const AudioContext = window.AudioContext || window.webkitAudioContext; const audioContext = new AudioContext(); await audioContext.suspend(); const node = audioContext.createOscillator(); Actual state after creation of the oscillator node is "running". Since the code explicitly called suspend(), I would rather expect the audio context to remain in a "suspended" state. Working around this behavior is easy, one can either: 1. call suspend() after creating the first node 2. call resume() before suspend() leading to the following (weird) workaround: const AudioContext = window.AudioContext || window.webkitAudioContext; const audioContext = new AudioContext(); await audioContext.resume(); await audioContext.suspend(); const node = audioContext.createOscillator(); The attached HTML page renders 3 buttons. First button illustrates the bug. Second and third button illustrate the workarounds. I note that this may warrant an update to the Web Audio API specification, as it does not explicitly state that the initial transition to running (delayed in Webkit as allowed by the spec) needs to take the [[suspended by user]] flag into account. It seems reasonable to assume that when the developer calls suspend(), they actually mean it, though!