Tried repro with 65.0.3293.0 (Official Build) canary (64-bit) on Mac. It does repro if --site-per-process is specified and does not repro otherwise. Tagging appropriately.

It is a warning, so I'm not sure if there is a regression in actual functionality. Please provide data on what the impact is other than a warning on the console.

Along with the warning, the AudioContext is 'suspended'.

I just noticed that you can also reproduce the same bug opening the link in new tab using cmd+click.

+mlamouri who implemented the cross-origin play support for an AudioContext.

Able to reproduce this issue on reported version 65.0.3293.0 Canary build. But unable to reproduce this issue on equivalent dev build i.e;65.0.3293.0 dev even on enabling or disabling --site-per-process flag. Attaching screencast for reference.

As we are able to reproduce this issue on canary build marking this as Untriaged and removing Needs-Bisect label. Please add Needs-Bisect if required.

Thanks!

This is broken for me on Chrome "Version 63.0.3239.108 (Official Build) (64-bit)", Win 7 x64 professional.

It is absolutely not simply warning: it also breaks (by muting all audio) 95% of the Web Audio examples I've tried and almost all my projects.

Here's (attached) the very simplest example that breaks things for me. It simply creates an audiocontext, and starts an oscillator connected to the output.
When serving as a local file ("file:///..."), the audio context will never work and you'll never hear the sound.
Interestingly, when served using a dev server to serve the same file, the iframe detection will kick in when opening a new tab (copying and pasting the localhost address), but no longer when refreshing the page!
I've had a personal project of mine behave differently whether I refresh using ctrl+R or by clicking on the refresh button as well...

Deleted: chromebug.zip 399 bytes

chromebug.zip 399 bytes Download

I forgot a crucial detail: I have the #autoplay-policy set to "Document user activation" in my chrome://flags.

Going back to any other settings makes it work again, but I lose the benefit of blocking autoplay. (In my particular case, I don't want videos to autoplay.)

When "document user activation" is set, Web Audio will be blocked until the page receives a user gesture. However, the error message is indeed incorrect and should be updated.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b89cc57c5b6cfbd8881ea27b09bb7c444706a350

commit b89cc57c5b6cfbd8881ea27b09bb7c444706a350
Author: Mounir Lamouri <mlamouri@chromium.org>
Date: Thu Dec 21 17:22:06 2017

Web Audio: show autoplay error message based on the current policy.

Bug:  794508 
Change-Id: If7c5fe5668ef676a0b0ed4d62b0166e8d62dff7c
Reviewed-on: https://chromium-review.googlesource.com/840001
Commit-Queue: Mounir Lamouri <mlamouri@chromium.org>
Reviewed-by: Tommy Steimel <steimel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#525725}
[modify] https://crrev.com/b89cc57c5b6cfbd8881ea27b09bb7c444706a350/third_party/WebKit/Source/modules/webaudio/BaseAudioContext.cpp

I'm surprised that a simple error message change is the fix for this bug. If "document user activation" is ever set as the default policy, this will break a very large number of (non-updated) Web Audio applications (including some showcases for the technology from Google itself) who never expect the Audio Context to start in a suspended state.

At the moment, we are planning to apply the autoplay restrictions to Web Audio. Allowing Web Audio to autoplay without allowing <audio> wouldn't make much sense.

mlamouri@ - could you please comment on the observation from #c2 that this issue repros only in presence of --site-per-process?  Was the observation correct?  Is it possible that there is also a separate bug here around user gesture propagation into OOPIFs (in general, or maybe specific to web audio)?

lukasza@, I did not find this issue to be specific to --site-per-process.

#13: I think the user gesture support for autoplay talked about here was added for OOPIFs recently as part of  issue 767389 , so there shouldn't be a problem there.  

I think that work only covers knowledge of whether a frame has received a user gesture (ever, or in a previous navigation within the same site).  We still have other known problems with OOPIF user gesture support, namely the plumbing for cross-process postMessage and for window.open.  That is a separate problem and covered by issue 589894.

Regarding #2 - like #14, I actually can repro this with and without --site-per-process.  Maybe Nasko can double-check whether his repro was site-per-process-specific once he's back.