For the last week or more, webkitAudioContext is not set. Inspector autocompletes the name, but still returns undefined: > webkitAudioContext < undefined > new webkitAudioContext < TypeError: 'undefined' is not a constructor (evaluating 'new webkitAudioContext') offlineAudioContext seems to work: > webkitOfflineAudioContext < webkitOfflineAudioContextConstructor I always end up reverting to r150366, in which Web Audio is working. There were quite a few builds after this that created horrible popping/scratching noises when initializing the audio context, and now it is simply not defined. I can reproduce it on any page. Just open the console on the welcome-screen when opening the fresh install (r151760) and try to create a context. I have tried restarting the browser. Not sure if I have restarted the mac after installing, so I could try that as well.
Regressed in <http://trac.webkit.org/changeset/150663>. What I'm observing is that webkitAudioContext works in a document until I try to access it from Web Inspector, at which time it disappears from the document too. Unsure if this is limited to webkitAudioContext, or a more widespread problem.
<rdar://problem/14217549>
new webkitAudioContext(); works in WebInspector for WebKit2 EFL. window.webkitAudioContext is not undefined either. I'm looking into the issue but it is likely to be a setting problem if it works on EFL but not mac port. The constructor is enabled at runtime via RuntimeEnabledSettings.
RuntimeEnabledFeatures::webkitAudioContextEnabled() is called to check if the constructor should be enabled at runtime. It returns true if the WebAudio setting is enabled.
One difference in behavior after the patch is that WebAudio used to be a per-PageGroup preference. Now, it is a global preference because it is part of RuntimeEnabledFeatures. It is possible that the WebAudio setting get disabled somehow when the Safari Web Inspector is showed? This would explain why the constructor would disappear from the document when the inspector is used.
Yes, Web Inspector does not enable WebAudio (why would it?). Clients should be free to apply different settings to multiple PageGroups. The idea of PageGroups is that there are entirely separate, with code creating each not necessarily aware that there are others.
(In reply to comment #6) > Yes, Web Inspector does not enable WebAudio (why would it?). So the webkitAudioContext constructor should not be exposed in the Web inspector, right? > > Clients should be free to apply different settings to multiple PageGroups. The idea of PageGroups is that there are entirely separate, with code creating each not necessarily aware that there are others. I understand, I wasn't sure of the value of having WebAudio support at pagegroup level. But I understand this is confusing in the current state. For the record, I this is not the only setting behaving like this. I followed the model of CSSRegions and CSSCompositing. I guess I will roll out. We would need support in the JSC bindings generator for something similar to [EnabledAtRuntime] but using Settings instead of RuntimeEnabledFeatures.
> So the webkitAudioContext constructor should not be exposed in the Web inspector, right? Probably not to Web Inspector code (unless there is a specific reason to need it, in which Web Inspector will opt into it). Should obviously be exposed in Web Inspector console, as that runs in the context of the inspected page. > I followed the model of CSSRegions and CSSCompositing So, the same issue exists for these? That's quite unfortunate :(
Created attachment 205120 [details] roll out
Comment on attachment 205120 [details] roll out Attachment 205120 [details] did not pass efl-ews (efl): Output: http://webkit-queues.appspot.com/results/858693
(In reply to comment #8) > > So the webkitAudioContext constructor should not be exposed in the Web inspector, right? > > Probably not to Web Inspector code (unless there is a specific reason to need it, in which Web Inspector will opt into it). > > Should obviously be exposed in Web Inspector console, as that runs in the context of the inspected page. > > > I followed the model of CSSRegions and CSSCompositing > > So, the same issue exists for these? That's quite unfortunate :( They may not have exactly the same issue, it depends if their constructor is actually enabled at runtime. However, their WebKit2 setting is linked to a global boolean in RuntimeEnabledFeatures: http://trac.webkit.org/browser/trunk/Source/WebKit2/WebProcess/WebPage/WebPage.cpp#L2490 http://trac.webkit.org/browser/trunk/Source/WebKit2/WebProcess/WebPage/WebPage.cpp#L2491 So changing these settings would affect all page groups.
Comment on attachment 205120 [details] roll out Attachment 205120 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/956138
Comment on attachment 205120 [details] roll out Attachment 205120 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/937394
Ok, rolling it out is not easy but I am working on it :)
Comment on attachment 205120 [details] roll out Attachment 205120 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/857654
Created attachment 205126 [details] Patch
Created attachment 205127 [details] JSDOMWindow.cpp diff
Comment on attachment 205126 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=205126&action=review > Source/WebCore/ChangeLog:9 > + RuntimeEnabledFeatures. Would it be hard to change WebAudio so that it uses RuntimeEnabledFeatures?
Comment on attachment 205126 [details] Patch For the time being, I'll r+ it as this CL is a reasonable revert for r150663, which caused the regression. However, we might want to invent a cleaner solution (e.g. WebAudio should use RuntimeEnabledFeatures).
Comment on attachment 205126 [details] Patch Attachment 205126 [details] did not pass gtk-ews (gtk): Output: http://webkit-queues.appspot.com/results/918432
By the way, the reason I discovered this was not because it was not found through the inspector, but because my project (which uses webAudio) failed to create the webkitAudioContext. It might be because the inspector was open at the same time, in another tab? Now (still on the same build) it seems to work occasionally (not consistently). Sometimes I need to refresh the page and close other tabs to get it working again.
Created attachment 205155 [details] Patch for landing
Comment on attachment 205155 [details] Patch for landing Looks OK as an immediate fix for the regression, though we might want to invent a cleaner solution.
(In reply to comment #19) > (From update of attachment 205126 [details]) > For the time being, I'll r+ it as this CL is a reasonable revert for r150663, which caused the regression. However, we might want to invent a cleaner solution (e.g. WebAudio should use RuntimeEnabledFeatures). Do we really want to use RuntimeEnabledFeatures to enable features at runtime? What is the issue with using Settings? I was thinking that we might want to get rid of RuntimeEnabledFeatures class (Which is barely used at the moment) and use Settings instead?
(In reply to comment #24) > Do we really want to use RuntimeEnabledFeatures to enable features at runtime? What is the issue with using Settings? > > I was thinking that we might want to get rid of RuntimeEnabledFeatures class (Which is barely used at the moment) and use Settings instead? Sorry for not being clear (I was confused a bit). My point is that it is nasty that (1) we have both [EnabledAtRuntime] and [EnabledBySettings] and that (2) RuntimeEnabledFeatures.h is hand-written. So replacing RuntimeEnabledFeatures with Settings sounds like a reasonable approach.
Comment on attachment 205155 [details] Patch for landing Clearing flags on attachment: 205155 Committed r151832: <http://trac.webkit.org/changeset/151832>
All reviewed patches have been landed. Closing bug.
> I was thinking that we might want to get rid of RuntimeEnabledFeatures class (Which is barely used at the moment) and use Settings instead? +1