New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify interaction between user-invoked suspend and autoplay policy #1802
Comments
Answering in reverse order:
|
Agreed on both points. But also it means the current PR might have to be re-written with new flags. I am doing some thought experiments about introducing a new context state |
The only case that my change doesn't take into account is when |
Okay, let's clarify a bit more.
Calling suspend() on a suspended context technically will do nothing. This is specced.
I am confused with this sentence. Calling suspend() on a blocked audio context will do nothing. What side effect are you referring here?
What if you call suspend() when it is already blocked by autoplay policy? Then the context did not run at all since its construction, so start() call will resume the context. Not elegant, but a simple solution would be having a flag in AudioContext, something like |
The side effect I'm referring to is that, if I understand correctly, the issue is that the following will resume the audio context and you believe it shouldn't: let ac = new AudioContext();
ac.state; // 'suspended'
ac.suspend();
let n= new OscillatorNode(ac);
n.connect(ac.destination);
b.onclick = () => { n.start(); } My concern here is that suspend() happens when |
These are two different types of suspension, and I think it needs to be handled differently.
Yes. If user wants a context to be suspended explicitly, the intent should be honored. The question is how this behavior should be documented in the spec. |
@mounirlamouri I still think we have some confusions. Consider this case on an AudioContext C:
The step 3 is the current behavior of Chrome. The current PR does not cause any action (i.e. start rendering) other than setting two flags. I am not sure if that's right. The initial start() call upon an UA suspended context will automatically resume it, so the prose should contain something more than flipping flags. @mounirlamouri WDTY about this point? The solution that I am thinking is:
In short, we need an additional flag of |
Two directions:
|
#1802 (comment) is the correct way to implement this. It needs to be explicit. In fact, this is more or less what we will be doing soon in Gecko for JavaScript breakpoints, for example: the audio stops when execution is paused, but the state is different than suspend/resume/close from the user. |
At the end of the day, I don't feel very strongly either way but our implementation was trying to stay close to WebKit's and the spec was obviously following it. I'm not sure how safe it is to spec something that doesn't match current implementations but maybe @jernoble would be willing to change WebKit's? |
I have not tried yet, but how does WebKit handle the example I posted above? If WebKit somehow does it "correctly" by not resuming a context that is explicitly suspended, we might have missed some internal details in the PR. |
My understanding is that WebKit does the same as Chrome which should be the same as the PR I sent. |
Yes, I just tried the example with Safari (desktop) and it has the same issue. It does not honor the user-invoked suspension. I think it is a wrong behavior and not what developers want. (crbug entry) |
I agree @hoch . If a developer explicitly suspended a context, I think he'd be very surprised to have |
Gecko has implemented respecting the author's intent, and is not resuming automatically. |
@jernoble @mounirlamouri We would like to proceed with the PR #1823. PTAL. |
I've been informed by jer that this is a Safari bug, and is not intentional, so we'll proceed with the spec as proposed here: respecting the author's intent, and not resuming the context if it's been suspended. |
I've approved the CL. Thanks @hoch |
Reopening; the Director want to know whether there are privacy implications for this issue which would merit review. |
I do not think so. This is simple a spec bug which UA could bypass a suspend() call with a user gesture. We agreed to fix the oversight. There's no issue in the regard of fingerprinting or general privacy. |
I tend to agree. The problem is not that the user can't suspend or that there is no auto-suspend; it is that when auto-suspend is cancelled (by user interaction), that also accidentally resumes user-invoked suspension. |
What needs to be done here? |
Probably just re-closing it. |
Closing. Re-open if needed. |
We still have the PR under the review, but I think this deserve another look by WG.
In Chrome, the autoplay policy automatically suspends the context when UA is not allowed to start it. This "automatic" suspension by autoplay policy will be lifted off when 1)
context.resume()
call or 2)source.start()
call upon user activation.However, the problem here is that there is no way to distinguish between automatic suspension and user-invoked suspension. Therefore, even if user explicitly suspended the context, the current design will unblock the context and resume the rendering.
Consider the following example:
Apparently violating user's explicit request for suspension is not acceptable. So A and B should both be
suspended
. But this still brings a couple of questions:source.start()
? Do we still have to stash it somewhere and play it when the suspension is lifted off? Or should it be disregarded completely?was allowed to start
,is allowed to start
, anduser suspension
. I think this needs a careful review to figure out all the corner cases.cc: @mounirlamouri
The text was updated successfully, but these errors were encountered: