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

Jer Noble
Reported 2013-06-27 18:34:33 PDT
Audio in apps which embed WebViews is corrupted.
Attachments
Patch (11.79 KB, patch)
2013-06-27 21:55 PDT, Jer Noble
mjs: review+
buildbot: commit-queue-
Archive of layout-test-results from APPLE-EWS-5 for win-future (1.05 MB, application/zip)
2013-06-28 09:45 PDT, Build Bot
no flags
Jer Noble
Comment 1 2013-06-27 21:55:56 PDT
Jer Noble
Comment 2 2013-06-27 22:08:55 PDT
Eric Carlson
Comment 3 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+.
Anders Carlsson
Comment 4 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?
Jer Noble
Comment 5 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.
Jer Noble
Comment 6 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.
Build Bot
Comment 7 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
Build Bot
Comment 8 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
Jer Noble
Comment 9 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. :)
Maciej Stachowiak
Comment 10 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.
Sam Weinig
Comment 11 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?
Radar WebKit Bug Importer
Comment 12 2013-06-30 23:36:26 PDT
Jer Noble
Comment 13 2013-07-01 11:41:20 PDT
Note You need to log in before you can comment on or make changes to this bug.