Bug 118163

Summary: Audio in apps which embed WebViews is corrupted.
Product: WebKit Reporter: Jer Noble <jer.noble>
Component: New BugsAssignee: Jer Noble <jer.noble>
Status: RESOLVED FIXED    
Severity: Normal CC: andersca, commit-queue, eric.carlson, glenn, jonlee, sam, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
mjs: review+, buildbot: commit-queue-
Archive of layout-test-results from APPLE-EWS-5 for win-future none

Description Jer Noble 2013-06-27 18:34:33 PDT
Audio in apps which embed WebViews is corrupted.
Comment 1 Jer Noble 2013-06-27 21:55:56 PDT
Created attachment 205663 [details]
Patch
Comment 2 Jer Noble 2013-06-27 22:08:55 PDT
<rdar://problem/14083280>
Comment 3 Eric Carlson 2013-06-28 09:07:41 PDT
Comment on attachment 205663 [details]
Patch

Looks good to me, but I am not a WK2 owner so someone else will have to r+.
Comment 4 Anders Carlsson 2013-06-28 09:28:57 PDT
Why does this need to be a setting? Isn't it something we'd want to work for all apps?
Comment 5 Jer Noble 2013-06-28 09:35:27 PDT
(In reply to comment #4)
> Why does this need to be a setting? Isn't it something we'd want to work for all apps?

Originally it did.  However, some audio intensive apps which embedded a WebView were unhappy to find that the global audio buffer setting had been changed to a very high value.  The easiest way for an embedding app to signal that it's fine with this behavior is through a setting.
Comment 6 Jer Noble 2013-06-28 09:36:39 PDT
Though perhaps this should default to TRUE for WebKit2 and FALSE for WebKit1, since in the WebKit2 case, we can be reasonably confident that there are no other sources of audio apart from <audio>, <video>, and Web Audio.
Comment 7 Build Bot 2013-06-28 09:45:46 PDT
Comment on attachment 205663 [details]
Patch

Attachment 205663 [details] did not pass win-ews (win):
Output: http://webkit-queues.appspot.com/results/995441

New failing tests:
fast/forms/select/popup-closes-on-blur.html
Comment 8 Build Bot 2013-06-28 09:45:48 PDT
Created attachment 205720 [details]
Archive of layout-test-results from APPLE-EWS-5 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: APPLE-EWS-5  Port: win-future  Platform: CYGWIN_NT-6.1-WOW64-1.7.20-0.266-5-3-i686-32bit
Comment 9 Jer Noble 2013-06-28 10:04:19 PDT
(In reply to comment #7)
> (From update of attachment 205663 [details])
> Attachment 205663 [details] did not pass win-ews (win):
> Output: http://webkit-queues.appspot.com/results/995441
> 
> New failing tests:
> fast/forms/select/popup-closes-on-blur.html

Seems unrelated. :)
Comment 10 Maciej Stachowiak 2013-06-29 20:20:46 PDT
Comment on attachment 205663 [details]
Patch

This way of doing it seems ok to me, but if you want to make it have opposite defaults for WK1 and WK2, that would be fine as well.
Comment 11 Sam Weinig 2013-06-30 14:46:44 PDT
Does this really have to be a global?  Is there a reason the places where we read this setting can't access settings or some proxy for it?
Comment 12 Radar WebKit Bug Importer 2013-06-30 23:36:26 PDT
<rdar://problem/14317560>
Comment 13 Jer Noble 2013-07-01 11:41:20 PDT
Committed r152234: <http://trac.webkit.org/changeset/152234>